Why there are Cloud Functions and Service Mesh & whats next.

Journey into the history of Backend development and DevOps to understand why we have Cloud Function and Service Mesh

DevOps discography

Let’s just quickly go through what happened in the DevOps/Backend development industry for the last 20 years.

Disclaimer: I don’t try to describe all events that happened in IT industry I just wanna show how tools were made for the tasks that need to solve at that particular moment.

🏢 Vertical scale era

Starting from the moment when server-side applications were so small. One single server with Apache handles different web applications from a separate FTP folder. Those servers were bare-metal machines and at that moment there was no DevOps, it were “bearded” system administrators who had to manage those servers. The main problems for them were:

1. Apply new updates to the bare-metal server.
2. Inventory. Understand which packages do you have and where. Server capacity, etc.
3. Setup a new server.
4. Clean up resources on those servers.

The tools that come up to solve this problem such as Puppet and Chef.

Note: of course there were many different approaches to solve those problems as an example I choose those 2.

The idea was that you setup a special agent that helps you to manage your servers. Gather information about machines, automate the deployment of the packages, and routine operations on the servers.

🏢🏢🏢 Horizontal scale era

Then applications become more complicated and vertical scale could not handle the load as before. At that moment clouds come in place. In the era of clouds and the idea of DevOps and CI/CD new problems come in place.

1. How to deploy and configure different applications with minimum effort
2. How to deliver your service
3. How to migrate applications between different cloud providers
4. How easily prepare the infrastructure for your project it’s something similar that was solved before as ‘Setup new server’ but now you need to setup different configurations of infra with autoscaling, etc.
5. How to reuse deployment automation that was made before on any Linux distributive.

Note: of course amount of problems was more than in that list

Chef and Puppet still were in place and many deployments were made on them. The idea about some platform that solves those problems come up at that moment. Such platforms are called PaaS. So you can make for example ruby application and PaaS will manage configuration for your app. Making PaaS systems developers had to solve the problem with the unification of service configuration, management, etc. As one of such unification solutions for the PaaS system was Docker. If somebody thinks that Docker is about containerization it’s a big mistake, containers were long before Docker and the first version of docker used LXC containers as backend. Docker is about a common contract of how to configure, run, and distribute your applications.

👥 Unified application management

With Docker new era has begun.

Now you can make common deployment solutions because you don’t care about the app itself your work with an abstraction that is called Docker.

• So there is an abstraction above of your service, but you still need one more because migration between clouds was still so painful.
• Developers started to divide applications to microservices which somehow should be deployed and managed.

I think now everybody knows which tool solves such problems. It is the Kubernetes. It helps you not only orchestrate your cluster, solve the problem with service discovery, etc but also gives your ability to run your cluster on the cloud provides who support Kubernetes out of the box or just ask the DevOps team to deploy it there and run your cluster on top of it.

Ok, it seems everything is perfect now you can make your microservices on any language that you know and it will be deployed and scale on any cloud provider or bare metal with Kubernetes.

🧑‍💻Just write business logic and forget about app management

What are the new problems that need to be solved?

1. You still need to develop a service which is 70% boilerplate configuration code (describe it more broadly what boilerplate means here, monitoring, tracing, logging, etc)
2. You need somebody in the team who knows how to deal with Kubernetes

The solution to these problems is the natural evolution of Docker, Kubernetes, Monitoring practice, and Microservices approach. It’s Cloud Functions. To combine backend you just need to make a set of Cloud Functions.

Most of the strong Cloud Function implementation has Amazon — Amazon Lambda. On top of the Lambda, they have Amazon Step Functions which is the next obvious step in the area of building abstractions above functions. (Read my article about workflows here) The Cloud Function itself is just a tiny building block to make an application one single function is not enough need something that “glue” Cloud Functions together.

Many open source solutions organize functions into groups with some context and relationships.

I think the evolution of backend development and DevOps will go in this direction and in 2–3 years, we will see backend that is made full of functions.

🔌 Connect with the others and reuse services

There is another direction of improvements

• Boilerplate we have killed with functions fine, but service/functions still need to write.

So in the world of services, you need something responsible for service communication. It is a service mesh. The idea is simple to move out of the communication between service to separate service. If somebody familiar with Hystrix or Twitter Finagle it’s java libraries so service mesh is parts of those libraries wrapped into separate service. It’s a generic layer that handles communication between services.

The brief future architecture where you run some functions by your self some other functions you use from the other service.

🤓 Recap

It’s similar to modern development right now something you take from libraries something you make by yourself. For the end-user, it’s just your application that dealing with everything. I think backend development and DevOps will keep going in that direction and we will see more and more interesting tools and solutions.