Time to create a Cloud Programming Language

There is a market for about 5 computers

I heard this quote multiple times in different contexts. But just in case you missed it: IBM CEO was quoted saying “I think there is a world market for maybe five computers,”. Although this ever being said is officially disputed, it’s an interesting thought to consider. If computers are powerful enough, or in other words have enough processing power, we may need a very limited number of units in total. So if either you perceive your computer to have a very large capacity of processing power, or you perceive the existing sum of computable problems to be small relatively to your computer’s capacity, then you may need only a handful of computers.

The datacenter is the computer

These days each one of the main cloud providers would like every developer to see it’s cloud as the target computer for their applications. Or in other words “the Datacenter is the Computer”. As a developer you get a set of components you could mix and match to create a wide range of applications. You have different ways to implement user interfaces, from web to mobile. Then you can funnel information through different processing components, and eventually store data in some kind of database. This is all very similar to what would have been developed to be deployed on a few servers inside the corporate datacenter just a few years ago.

The process happening nowadays is of breaking the cloud services to smaller and smaller pieces (microservices if you will) making each piece faster to invoke and requiring less maintenance and configuration. The developer just has to select the components needed, configure/program each one as needed and set the connections between them.

Limitations of current setup

This process can currently be done in one of two ways. The first is choosing the components from the cloud provider’s web interface and set the knobs and levers for each one, providing some code where needed. This way makes it simple for a first time user, as you can see the available configurations options for each component, or sometimes even follow a wizard. But there is no simple way to automate this process. This is where the cloud service API is coming to your help. For each cloud component there is a set of APIs which could be invoked from different scripting or programming environments. These would follow the same task as the UI setup, but in a consistent repeatable (sometimes testable) way. These scripts could in turn be stored in source control and be maintained and versioned as needed.

Language for creating a cloud setup

Now, we have another possible evolutionary step. To understand it, let’s think of an example from the Operating Systems world. At some point in the Operating System’s evolution there was a new entity called a Thread (a secondary sequence of execution inside a process). To manage and use it, there were different Operating System calls which told the OS a how to configure and execute the Thread. Then (mostly in Object Oriented languages) those system calls were abstracted by a language Thread entity (usually a class) which was instantiated and configured during the normal flow of the rest of the application code. In the OS world, most other entities (processes, devices etc.) were abstracted the same way by a dedicated language entity.

Now back to today’s cloud. A typical cloud application spawns multiple servers and multiple processes, hence, typically would be programmed as different sets of code (or programs) to run as each of these processes. For a developer or a team, this breaks the logic and flow of the cloud “application” between multiple sets of code in a way that could feel a little arbitrary. It also makes it harder to jump in and follow the flow of data and execution through the cloud, by reading the code.

What could overcome these issues is the ability to create one “program” which represents the full set of cloud components, their setup, connections, and the logic running in each one. Then you could have one code repository, in one language defining everything happening in a single cloud application. This “program” could then be run on a single developer machine on some kind of framework emulating the different cloud components. A developer could put a breakpoint in the logic of any given component and trace the flow through the whole system to identify problems or solve bugs.

Separating configuration from runtime

One things that is important to understand is the separation between configuration and runtime. The suggested cloud language (CloudLang?) would have constructs to do both, and the compiler would separate between them. Some parts of the code would only run the first time the application is being run, or on a special step, when the code is being run in “setup” mode. The different sections of actual runtime logic would be deployed to the corresponding cloud components, to be invoked as needed.

Behind the scenes, running the code in setup mode, would just need to call the existing cloud configuration APIs. So there shouldn’t be anything required from existing cloud providers to support CloudLang. At least not in its first iteration.

Streamlining the IT/Devops work and letting engineers control what’s important

Using CloudLang would return the control and responsibility of setting up the deployment environment, into the hands of developers. Design decisions affecting deployment configuration would be directly expressed in code. This would reduce the complexity and space for errors for those in charge of keeping the production environment running.