Polyglot: No One Language Will Rule the Cloud

No One Language Will Rule the CloudTake a deep look inside your development organization, at the skills your people require to do their job every day, and ask yourself this: What’s the fewest number of programming languages they require to complete any one project?

When development platforms were first deployed as cloud services, they were intended to gather developers together around one language. A few years later, some platforms are still trying to this number down to a respectable three, but they’re failing. Modern Web apps simply refuse to be homogenized. There’s a new fact of life in the development field: It’s called polyglot, and no, it doesn’t mean “multi-lingual.” It’s an environment that uses multiple languages simultaneously. This time, the change is not coming to the workplace, but rather to the vendors who service it.

It was the beginning of what we now call “the cloud.” The idea was to enable individuals to run programs from a collective server whose operations and whose specifications they wouldn’t have to care about. The system could get bigger as folks were using it; meanwhile, their service wouldn’t even be interrupted. But this was 1966, and Dartmouth College called both its system and its language BASIC because, it believed, it should be one and the same.

Four decades later, new groups of visionaries had essentially the same dream as Profs. Kemeny and Kurtz, a collection of servers of indeterminate size and location, interacted with remotely through mobile client terminals. This time, folks understood what these visionaries were proposing. And this time, folks were smart enough to demand something that visionaries didn’t visionize, at least at first: multi-lingual interpreter support. The apps development world has grown up, and no one speaks one language any more.

Bigger Scales in Smaller Steps

“Complexity is hard and scale is hard. If you’re going to have a well-architected app that scales properly, you’re going to have lots of components for all sorts of reasons, so you’ll be building your apps with different workers, different process types, and message queues,” explains Oren Teich, COO of Heroku, a platform-as-a-service (PaaS) provider that has become a cornerstone of Web apps development in just its first five years. “Yeah, it’s hard, which is why for years it was always the purview of financial systems. No one else would ever do it.”

We’ll get to what Teich means by “workers” in a moment. As he goes on to explain, the Web delivery model for applications no longer lends itself to a single language, and the reason has nothing to do with the efficacy or flexibility or architecture of the languages involved. Heroku was founded in 2007 as a PaaS provider for Ruby, which is a perfectly capable, object-oriented language that many feel is better suited for Web development than Perl, a general scripting language. When CRM and cloud service giant Salesforce acquired Heroku in 2010, it was the explicit intent of cementing Heroku’s place as “Ruby in the Cloud” (insert John Lennon’s music here). The following year, when Heroku hired Ruby’s well-known creator Yukihiro Matsumoto outright, the hire was touted as a crusade for Ruby’s eventual domination of the Web apps space.

Almost immediately — literally within weeks — the opposite happened. Heroku’s creators, including Teich, who had always been Ruby’s greatest evangelists, found themselves running a platform that supported Python, the server-side JavaScript language Node.js, a derivative of Lisp that compiles to Java bytecode called Clojure, and a Swiss-born experiment in an ultra-scalable Java language called Scala. Heroku found itself not only on the edge, but on the opposite edge of where it expected to be.

“I think what’s happening here doesn’t have anything to do with language,” remarks Teich. “Whether it’s one language or five, if you’ve architected [your app] to a series of components and to handle the complexity [therein], the reason you choose to go polyglot… is because you’re [always] choosing the best tool for the job. You’ll have a hardcore processing engine written in Java, and parallel processing pieces written in Clojure or Scala, and the front end written in Ruby.”

Digging for Dynos

The principal difference between a cloud-based Web application and one served from a conventional applications server — what makes Heroku different from, say, an automated turnstile for Web transactions — is multiplicity. The way conventional Web apps are served assumes that the server (the hardware that runs the program) is the resource that users wish to contact. They dial a URL into their browsers. When too many of those users try to access the same resource, then load balancers redirect calls within internal networks to less burdened servers.

With cloud architecture, the way a Web app manages increasing demand is to scale up. Quite literally, the app grows, generating new processes acting in parallel to the existing ones, and distributing them to available processors. These are the “workers” to which Teich referred, although in the latest iteration of Heroku architecture, they’re referred to with the cooler-sounding term dynos. Workers are not just routines or procedures or discrete functions, but units of work that Heroku’s process model can multiply almost at will.

Here’s the clincher: There truly is no language designed for this. The recent crop of dynamic languages, such as Ruby and Python, were actually created to fill a new and quickly growing gap: the need for lightweight, power-packed interpreters to develop front ends for Web apps. When the dynamic languages filled that gap, the traditional procedural languages, such as Java, became the preferred locutions for the “engines” of Web apps — the components that were not customer-facing, the parts behind the scenes.

But that’s not how things stayed. Once Heroku’s engineers worked out a way to scale units of work efficiently at a very granular level, Ruby suddenly seemed to want to escape from its own shell, to extend itself beyond the limits of a “Web language.” Then when Heroku’s engineers realized that interpreters for a variety of quite unique languages could divide work very granularly into essentially the same dynos, the value proposition for a single language, lending itself to all the conceivable use cases for PaaS applications either now or in the future, disappeared.

“Heroku… basically created the platform space, so we understand what it means to be single-language,” says COO Oren Teich. “And we’ve learned a lot: There are common characteristics among languages for what it takes to run, but it’s very important that you treat the unique characteristics especially.” He refers to a layer of Heroku’s latest architecture (code-named Cedar) called the buildpacks. These are the compiler scripts that break down processes from their native language, digesting them into dynos that Heroku’s servers can schedule and execute in a uniform manner. These are also the parts that can conceivably treat each supported language uniquely. As of the time of this writing, Heroku supports nine buildpacks.

Here’s where things get extremely interesting. Since Heroku opened its Cedar architecture, it enables anyone in the open source community to build their own buildpacks, so long as they produce compatible dynos. The growing list of third-party buildpacks includes support for Perl, Lua, Erlang, Nano, Sphinx, R, Lisp, and a few items I must admit I’d never seen before.

Patchwork is the Only Way

Polyglot is not about annexing languages and adding them to some kind of superheroes legion, the bigger the better. It is about the notion that unique classes of operation can and must be explained in unique ways, and that this fact should not impair the ability of processors to execute these operations at a granular level.

It’s a principle that’s leading to a frank and humble acknowledgment among the makers of both development tools and platforms: Modern applications simply cannot be constructed from one grade of cloth. Faced with the prospect of its own cloud becoming an island, Microsoft opened up its Windows Azure PaaS service to new languages and constructs, first in 2011 by adding both PHP and the one-time arch rival of its .NET Framework, Java, and following up in 2012 with the server-side JavaScript system called Node.js. Then the pioneer in Web services, Amazon, opened up its once Java-centric Elastic Beanstalk, adding PHP support in March 2012, and then adding .NET language support the following May. The two biggest dams in cloud computing platforms have effectively burst.

As a result, it’s becoming more cost-effective for organizations to use cloud platforms. When they do, their development teams can use whatever skills they already know, rather than make them learn new ones to suit some homogenous PaaS framework. And because of this, businesses that already have the computing power (though perhaps weren’t using it efficiently enough) are starting to consider scrapping their current application server architectures altogether, and to host their own Heroku-like platforms internally.

It’s this new demand that has led ActiveState, an established app server provider of some 15+ years, to begin marketing private cloud platforms that they unashamedly describe as “your own private Heroku.” This just so development teams can efficiently use the skills they presently have, and so their applications make more efficient use of the data center hardware their employers already own.

Toph Whitmore is vice president of marketing for ActiveState, and describes for us his company’s private polyglot cloud platform, Stackato: “About two years ago, we saw a need, mostly through what our customers were telling us, for a private PaaS solution. They were developing in multiple languages; they had development teams that, for lots of different reasons, both internal skill sets but also business needs, were developing in more than one language and needed a cloud solution that could support more than one language.”

ActiveState is already well-known as the manufacturer of a commercial IDE for the Python language, called Komodo. While the company began thinking about the prospects of Python in the cloud, Whitmore tells us, his customers were actually asking for both Python and Perl in the cloud, primarily at the time because Heroku was not yet providing them. As a result, he says, “We started from a polyglot perspective. The internal name for the product, initially, was ‘MultiPaaS.’”

Stackato is a private PaaS platform based on a highly reworked version of VMware’s CloudFoundry, the first PaaS platform ever to be open sourced. One advantage of Stackato over what we can now call the “conventional cloud,” a legacy whose lifespan can still be measured in weeks, is that it becomes possible for organizations to host their existing applications, including the ones they have had for decades, alongside new, Heroku-style polyglot apps on the same platform, along with messaging queues that make them interoperable with one another. “The DevOps teams can have these wonderful management tools, and your whole company can benefit from the efficiency, scalability, and convenience of the cloud, while maintaining all of the security you get from a private PaaS.”

That security includes both the digital kind and the bureaucratic kind. Many government agencies cannot yet take advantage of polyglot systems simply because they are public services, and because Congress has refused to pass laws enabling security policies to be established for public platforms. Until that matter is resolved (which, at this rate, may be left to our grandchildren), many public sector cloud services must remain out of the public realm.

A Cloud Full of Worlds

In the meantime, it’s private cloud technology that’s enabling governments to realize cost savings through the pooling and repurposing of existing resources. And as Stackato and systems similar to it march into the public sector and the financial sector, along with them come languages, programming techniques, and messaging queues that these sectors have never dealt with before… and might not have requisitioned intentionally for their own sake alone.

Troy Topnik represents ActiveState’s engineering team. As Topnik explains, when a customer pushes an application to a Stackato cloud, it goes through a staging phase and then a deployment phase, both within a virtual Linux container based conceptually on Solaris Zones and Jails in FreeBSD — completely isolated environments for individual applications, each with its own independent security context. 

“We have an application security model that operates at a pseudo-system level,” he continues. “So it’s independent of whatever language vulnerabilities there are. A user of the system has access to the credentials for their data services, to their application containers, and not to others, with the exception of groups that can share these things – another feature of Stackato. But the decision to make it that way really has nothing to do with a single-language platform or a multi-language platform, it’s just something that was safe to do.”

Topnik’s argument stands in direct contrast to competitors who contend that a single-language or single-framework cloud model is, by design, easier to keep secure. The emerging argument from the polyglot side is that, since cloud apps are run within security zones anyway, and since components use one or more independent message queues creating a layer of abstraction between them, PaaS platform security will evolve toward the same model anyway.

As these abstraction layers proliferate, he continues, architectural choices can become more focused upon individual functions rather than the constraints of any single methodology on the app as a whole. One example is data services, which is an automatically provisioned database for one or more applications pushed to Stackato. A credentials model is created for each data service, so it acts like a separate system with its own security. Another is the message queue. While Stackato has preferred to present VMware’s RabbitMQ as a service, its system does enable access to external queues. This is important, because message queues are critical to multiple-language apps — it’s the glue that holds them together.

As Topnik explains, once the need for polyglot became evident, it soon became clear that this was not going to be an “ActiveState cloud.” DevOps departments wanted the type of versatility the company was considering for its own cloud, for themselves.

“What became evident was, nobody was going to trust mission-critical corporate enterprise applications to a third-party provider, who in turn was hosting on a third-party IaaS provider. It became clear to us that we should not do the service ourselves, but license the software so that these enterprises could provide for their developers the services that they’ve been asking for.”

This is how cloud architecture is upsetting the balance of power among applications servers, first by drawing customers up into the public clouds like Heroku, but then, after the bug has bitten them, by extending their reach into the traditional data centers down on the ground. The efficiencies to be gained are very nice, and keeping developers happy is a bonus. But it’s the long-term cost savings that is sealing the deal, eliminating any remaining causes for doubt and delay. The evolutionary path may not have been what BASIC’s developers envisioned, but the end goal ended up being the same.

See also:

 



8-tips-cloud-wp-cta




subscribe-to-our-blog


Comments

  1. QA Thought leaders says:

    Very interesting and informative post. Cloud is the next big thing for sure. Can you please something on cloud based testing techniques. I will look forward to your next post. Thanks for sharing it. 
     
     
    http://www.qainfotech.com/cloudtesting.html 

  2. Ron Peacetree says:

    If developers and SW architects are honest, the world has always been polyglot. 
     
    The Godel Incompleteness Theorem is why: 
    Either you can have a consistent but incomplete system or you can have a complete but inconsistent system. 
     
    Which means any SW language that tries to be all things to all people both rapidly becomes unmanageably large and develops internal contradictions- not what you want in a tool that is supposed to help manage and reduce complexity. 
     
    Many decades ago, we wrote prototypes in interpreted languages like LISP while using targeted languages like COBOL, SNOBOL, C, APL, etc each for what they were good for and then used linkers and loaders on object code from each to create compiled production systems. 
     
    The power we have available has grown greatly in the last century, but the best ways for humans to understand and manage complexity are tied to human evolution, which takes MUCH longer.

Speak Your Mind

*