The future of the Cloud is Abstraction

The source code for the Apollo 11, the mission that brought the first human beings to the moon and back, has 40.202 lines of code and can be found on GitHub (1). The Web browser Firefox you might currently use to read this article in comparison has around 9.7 million lines of code (2). Sure, comparing the number of lines of code does not say much, especially of two software products for such different purpose and technologies. But one thing we can sure agree on: Software is becoming more and more complex.

And the more complex the challenges we solve become the more sophisticated our tools become to solve them. Looking at the above comparison we can already see that evolution. Apollo 11 was written in assembler, a programming language very close to the machine, where you must handle registers and hex codes, while Firefox is written in C++, a language that is already a big abstraction from assembler, orienting on structuring the code for the developer, not for the machine. With that focus on developers instead of machines C++ has made it easier to solve complex problems than assembler did.

The All-Purpose Developer

This trend of programming languages to focus more on the developer does not stop there. Frameworks like Spring Boot in Java or single page application frameworks like Vue.js are hiding away boilerplate code, so that developers can write less while achieving more. And this was really needed. Modern developers need to master a variety of tools, languages, and frameworks to solve their daily challenges implementing the requirements of their work or private projects: from relational and NoSQL Databases, over backends with Spring Boot, Go or Python, messaging services like RabbitMQ or Kafka, frontends with Angular, Svelte or Flutter, to Monitoring with Prometheus, Grafana and Jaeger; and don’t forget about the cloud hosting solutions with Kubernetes, serverless Runtimes, or just operating plain, unmanaged Virtual Machines.

Becoming someone with good skills in all areas is hard. Finding someone with good skills in all areas is nearly impossible.

Developers must focus on some parts of the technology stack, ideally those which have the highest impact on what matters the most: the product itself. Having the perfect monitoring solution or the most scalable infrastructure for your product sure helps with the stability of your product but investing weeks in the last 0.1% improvement in this area might not bring the return on invest as the new express-checkout-button the Product Owner has planned.

The Requirement-Skill Paradox

But this does not mean, that we can ignore the infrastructure. Having your product always available so that customers can rely on it is the base for your success. You can have the best software in the world; but if it is not reachable most of the time, your customers won’t be able to use it most of the time. So, we are facing a paradox:

Developers should focus on becoming experts on the Application layer, but we cannot ignore the service and infrastructure layer. And both are becoming more complex.

Does this mean, that a DevOps Mindset, where one team can handle the full lifecycle of a product, from development to operation, is an unrealistic goal? Should we go back to create two teams, one with experts in development tools and one with experts in infrastructure tools for operation?

The impact of having a DevOps Mindset is proven in many other publications, like the book Accelerate: The Science of Lean Software and DevOps from Nicole Forsgren, Jez Humble and Gene Kim. It is a valid goal to aim for to improve the delivery cycles of your product. Therefore, we must improve the situation in another way.

GitOps to the Rescue

One way to enable developers to become experts in infrastructure and operations without losing their focus on the further improvement of their product can be seen in GitOps. At the core of GitOps is the idea of reusing tools and patterns developers already known from their application development processes for setting up the infrastructure as well. Their infrastructure is managed in declarative code like Terraform or Pulumi and stored and maintained in Git, a popular version control system.

Making sure, that infrastructure can be created and maintained in the same way as the applications code, lowers the initial hurdles to get started.

Tools like Helm improve the situation even more since they deliver an open-source marketplace of already existing infrastructure-as-code (IaC) scripts for various tools you can pull and reuse for your own setup. It is so to say the equivalent to the Spring Boot framework for infrastructure, abstracting away often used code-snippets into packages a developer can just add and use in his project.

Having opinions helps abstract

To deliver packages with code snippets for your IaC setup, Helm must do one thing: Have an opinion. The IaC snippet that sets up a specific infrastructure is called a Helm Chart. You can find a lot of Helm Charts for various purposes like setting up a MongoDB instance, a Kubernetes cluster or even a complete Knative platform. You can download the Helm Chart, define some simple parameters, run it, and there you have your infrastructure setup.

The upside of configuring every detail of the infrastructure on your own is, that you can configure everything exactly the way you want it. If you reuse any IaC snippet for a specific infrastructure configuration, then this is abstracting away that configuration work. It is easier to setup your infrastructure, but you also hand over the responsibility of configuring your setup to the scripts with way less options to influence them.

Every abstraction in the infrastructure needs to define how exactly the thing it wants to set up should be set up.

A Helm Chart has a clear opinion about what is the right way to build up the expected infrastructure and is doing it in this exact way. And why not? A script pulled from the marketplace has already set up multiple if not hundreds or thousands of components in this way, while you might do it for the first time. It is a good thing to use the experience of all those runs and in this small scope good practice on how to do it. And if you prefer another way on how to do it, you will sure find another script for it – or you can implement one on your own for others to use.

Now we have moved the way on how to setup infrastructure closer to the coding experiences of developers and abstracted away most of the code needed to make things simpler. With some scripts, a couple of parameters and a command line you can create all the infrastructure you need in an opinionated, already proven way. All you need is the scripts and an API endpoint to the infrastructure of your choice that supports those scripts.

Case Study: STACKIT Cloud Foundry

So, at this point we trust the dogmatic opinionated approaches to set up the infrastructure. We focus on the developer experience and keep the infrastructure through abstraction as simple as possible, but as configurable as needed. If we continue this thought of abstraction making our life easier, what is the next step?

At the end we are interested in the already configured infrastructure. An already set up platform on which we can just deploy our application, without worrying too much on what is underneath. If we already trust scripts to create this for us, we can also trust our infrastructure provider to do it. So instead of selling infrastructure, cloud providers can just deliver that platform as a service.

In STACKIT, we offer Cloud Foundry as our platform-as-a-service product.

The goal of the STACKIT Cloud Foundry is to make sure that everyone, without prior knowledge of the platform, can deploy and access their application in just a few minutes.

Just like Helm Charts, Cloud Foundry is using an opinionated approach to prepare the infrastructure for the user and deliver a container runtime everyone can simply push their application to with just one command in the command line – or through the user interface – into the platform. After the push your application gets a url-endpoint assigned where you can access and directly interact with it.

For this the platform uses various components to orchestrate the underlying infrastructure, enable routing, secure with some user management, manage service bindings like databases and much more. It is based on the open-source project with the same name, and can already look back at many years of experience making the infrastructure experience of developers easy.

The magic of buildpacks

One good example on how Cloud Foundry exactly works is the concept of Buildpacks. Buildpacks are basically scripts that help containerize your application. Since Cloud Foundry delivers a container runtime at its heart, every application running on the system should be a containerized process. But containerizing applications again requires developers to focus on infrastructure – in this case the packaging of their application – instead of business logic.

Therefore, Cloud Foundry leverages opinionated scripts to create containers for various build artefacts, from static source code, over jar files, to Python and more. Developers can create, publish, import, and use many different Buildpacks representing specific opinionated ways on how to containerize a given build artefact. So, you don’t have to worry about how to containerize your application, instead you can just trust the platform to do it for you and use the time to further improve your application itself.

Conclusion

Development of modern applications is becoming more and more complex. It is hard for developers to keep up with all the skill requirements in so diverse topics. We should make sure to simplify things where we can. One important area is the infrastructure that can be abstracted away into dogmatic opinionated approaches on delivering a ready-to-use platform instead of just infrastructure you have to configure.

STACKIT for example delivers the Cloud Foundry as one platform-as-a-service option. And STACKIT is not alone with this trend. Digital Ocean just released with the App Platform their own platform-as-a-service offer with the same idea behind it. With GCPs CloudRun and Microsoft Azures App Service also the hyperscalers have their platform abstractions for customers available.

The trend is clear: Getting your application deployed should be nothing to worry about. And there is a good trend of abstracting away the infrastructure, making sure you won’t have to worry.

1. Apollo 11 Code on GitHub: https://github.com/chrislgarry/Apollo-11/tree/master/Luminary099
2. Lines of Code infographic: https://www.informationisbeautiful.net/visualizations/million-lines-of-code/
3. Source of meme: https://kubesandclouds.com/index.php/2020/02/27/kubernetes-why-when-and-how/?lang=es_es