Artificial Intelligence #35: How do Cloud native technologies fit together: serverless, containers, virtual machines etc

Welcome to Artificial Intelligence #35

We are nearing 37,000 subscribers in just under nine months

Thanks for your support as ever

In this edition, we will try to understand how Cloud native technologies have evolved and how they fit together. I read an interesting article from IBM (source below) which I used in my teaching at #universityofoxford that explains this adoption well.

Firstly, the term Cloud native computing is an approach in software development that utilizes cloud computing to build and run scalable applications in the cloud through technologies such as containers, microservices, serverless functions etc. These techniques enable loosely coupled systems. ?Frequently, cloud-native applications are built as a set of microservices that run in Docker containers and may be orchestrated in Kubernetes and managed and deployed using DevOps frameworks like CI/CD. Docker containers provide the ability to package all software needed to execute into one executable package. (Adapted from the Wikipedia definition of Cloud Native computing).

This description is accurate but does not help much in understanding if you see all these techniques lumped together. Instead, its helpful to think of these technologies in terms of their chronological / functional evolution

As per the image, we can see this in terms of an evolution in two axes

On the Y axis is increasing business logic focus – this means, as you go higher in the Y axis – the less code you write to manage the deployment.

On the X axis, you see decreasing deployment environment control. This means, increasing X axis denotes that you are less in control of your deployment environment.?

So, lets start with x = 0 y = 0 i.e. bare metal. In this case, you are completely responsible for the deployment environment because you are managing and configuring the servers, installing patches etc. This provides control but also leads to upfront cost and complexity. In this case, you also write the code to manage the deployment environment

Next came the Virtual machines where you virtualized the functionality of a physical machine but were still responsible for setting up your environment ex the OS for that virtual machine. Note that for vor virtual machines, you were responsible for less of the code for the deployment environment

Next higher in the abstraction came the containers, popularised by Docker. Now you package your deployment code, application code and all the dependencies into a single container and using the docker environment, the container itself can run on any target platform. Containers solve many of the problems of managing your environment but still two question remains

a)????Once a container is deployed, you still run a resource even when its not needed i.e. the container itself. That matters because you are paying for it (in the Cloud)

b)????Managing of containers becomes a problem also

So, you have two solutions: serverless and kubernetes

In serverless, you move to the next higher level of abstraction i.e. your level of operation becomes a function (function as a service). This approach has some implications that become apparent from the diagram

a)????Serverless does not mean that there are no servers involved – but that more to the X axis – the job of managing and provisioning these servers is delegated to the cloud provider.

b)????Also, because the level of abstraction is at the function level, that means?the amount of code you write to manage the solution is even lower. In other words, you are writing application level code at the level of a function

c)????Serverless (function as a service) is event driven.

d)????You pay for execution only for the function.

e)????You could have a polyglot environment through function as a service ie the functions could be developed in multiple programming languages. ?

Let us now look at the second problem: that of container orchestration.?

Since about 2013, containers have increasingly become the dominant architecture. Containers can be assembled to create distributed applications. But that created a new problem – how to manage and orchestrate these containers to form a distributed architecture. How do containers talk to each other? How is the lifecycle of a container managed? How many containers do you need and how many are currently running etc etc

In addition, microservices can be implemented as a set of containers. You need some mechanism to manage containers. So, enter Kubernetes. That’s where we are now.

In many ways, I think if we had a third axis (cost/execution time) we could explain this evolution better since the whole evolution from bare metal to serverless can be seen as managing cost (or granulising cost)

Some more thoughts

My 2022 prediction - Large language models could lead to thin and low-code AI applications in the Cloud – possibly changing the balance of power for AI

An amazing video on the significance of imaginary numbers

A tribute to my mentor – the late Jeremy Geelan

Duality Why The Most Powerful Idea You’ve Never Heard of May Require a Radical Reformulation of the Laws of Physics by ?Marco Tavora Ph.D. in Cantor’s paradise (I support Marco’s work through his Patreon for such excellent quality of science writing)

And of course, wish you a Merry Christmas and Happy holidays ?? ?

Stay safe !

?This article and the image was partly based on this link from IBM Ashher Syed

?Christmas image source pixabay