Cloud-native or cloud-agnostic?

From my discussions with many IT players, the fear of being locked into their supplier emerges. Is this fear justified? What do we gain from being “cloud-agnostic”? to be “cloud-native”?

The importance of a good definition

A common definition of the term “cloud-native” is shown above. These are applications which, because they rely on a micro-services architecture and containerization, will be able to take advantage of the elasticity capabilities (horizontal scalability, in particular) of cloud services.

It is this definition that is promoted by the Cloud Native Computing Foundation, which brings together an ecosystem of Software Vendors that are definitely interested in this definition (which allows them to position their product).

In fact, this definition is not directly opposed to that of cloud-agnostic: the orchestration of containers, often with Kubernetes, will allow the application to run on any cloud or even on-premises.

The main advantage of these cloud-agnostic solutions (apart from the possibility of changing cloud providers) is the simplification of the development workstation setup (just launch Docker and pull some images).

Operating these solutions is often much less easy: apart from the fact that Kubernetes is known to be extremely difficult to configure to meet demanding requirements, t*he components (reverse proxy, broker, database engines, etc.) hosted in the containers will still need some management*, and their interactions to be secured, etc. which can represent a considerable burden.

Of course, it is always possible with Ingress to deploy a managed Load Balancer rather than an Nginx controller, but then, we now have to understand the Ingress API on top of the managed Load Balancing service, and we lose the benefit of having an iso-prod development environment.

Another definition of Cloud Native

Public clouds like AWS not only allow the deployment of virtual machines or containers on demand, it is up to the user to manage their content.

A certain number of services also make it possible to delegate the management of the operating system, or even open source components, to the cloud provider (such as a PostgreSQL cluster, a RabbitMQ broker, or a streaming service such as Apache Kafka).

• Thus, it becomes possible to use services without necessarily having all the skills necessary for their operation.

Cloud providers also offer higher level (generally “homemade”), components, such as the EventBridge event bus, the Amazon Contact telephony service, AI services like Rekognition which allows image recognition. , specific databases (key-value like DynamoDB, or time series like Timestream).

These services have many advantages:

• They do not require any maintenance.

• Scalability management is built-in, completely removing the need to predict the load on the application.

• A certain number of them are billed by actual usage (e.g. by the number of millions of requests for API Gateway) and more by the hour of use.

• Permission management is integrated into the cloud provider’s Identity and Access Management (IAM).

It is the use of these services that will fully realize the value proposition of the cloud.

For instance, I have deployed customer-facing applications for a mid-size electricity supplier, relying on such a server-less, “truly” cloud-native, stack, and they cost less than $30 per month in hosting! And neither the supplier nor its customers were impacted (nor did they realize) when the application was recently facing an attempted DDOS attack.

But then, shouldn’t we fear “vendor lock-in”?

The “vendor lock-in” term suggests that the cloud provider is making a deliberate effort to prevent us from either using third-party tools or from recovering our data to change providers. This is not the case for any of the public cloud providers.

Rather than talking about “vendor lock-in”, it would therefore be better to talk about *reversibility cost*. Any choice of technology entails appropriation time, which will be lost, and the writing of a certain code base, which may require modifications, sometimes structural, in the event of a radical decision to release this technology.

But most of the cost of leaving the cloud provider will reside in having to make all the heavy lifting that the cloud has spared us so far! Did we save ourselves a DBA by relying on RDS? Not sure that our self-managed database will behave as well, or that we will be able to easily extract longest-running queries.

When — and how — to move to “real” cloud-native?

The start of a project is the right time to make structuring decision; making them later means having to bear the costs of reversibility — which are not one-way — mentioned above!

However, for many people it can be difficult or feel unsafe to make radical moves, such as switching to a server-less stack, especially when no developer in the team has this kind of experience and Ops measure their value in the ability to administer a Linux OS. When faced with tight deadlines or demanding requirements, it is often reassuring to rely on your well-known legacy stack.

Get yourself some help! With TerraCloud, I support the tech teams of software editors and corporate IT departments in designing and deploying their solutions in the cloud. I will be happy to help you take the step to benefit from the advantages of a “real” “cloud-native” stack.