Serverless or Kubernetes: why not both?

If you are a software developer and have had access to the Internet for the last 5 years, you are most likely already aware of the existence of a commercial offering called the "cloud" to put your applications on the Internet. Names such as Amazon Web Service, Microsoft Azure, or Google Cloud are some of the best-known "cloud providers'. But there are, literally, dozens of other offerings. Let's look at reasons to consider publishing your software in the cloud. Which requires purpose-coding it or adapting it to the cloud. In other words, go "cloud-native "

Opportunities and challenges of the cloud.

The cloud is an opportunity but also a challenge and a problem to solve.

How do you develop your software for the cloud? The cloud is, to begin with, a marketplace of servers. With a few clicks, you can create a server with as much disk space, memory, and CPU specifications as you want.

Managing one server, however, is time-consuming. Managing many servers is even more so. Using the cloud in turn then leads to having many small servers rather than a few large servers. The main reason is that the cloud enables you to create new servers at will, when you need them, keeping them active only as long as you need them, and then destroying the servers when they are no longer needed.

In short, the cloud has an "elastic" nature that must be exploited, otherwise, there is no point in using it. The problem is that leveraging the cloud potential it is not exactly a piece of cake.

Servlerless: to avoid managing servers.

The fundamental problem lies in managing the complexity of creating new servers when they are needed and deleting them when they are no longer needed. The traditional approach of a systems engineer who creates a server and configures it by hand is totally unworkable in the "elastic" cloud.

Server creation needs to be automated. Complex, structured architectures need to be built. Specialized skills are required, which are quite rare and expensive.

For this reason, leading cloud providers offer "ready-to-use" architectures, which the user does not have to create and configure but only uses. One only has to submit the code he or she wants to run, and the cloud provider takes care of the rest. The cloud provider generates the servers needed to execute the code, keeps them active as long as they exist, and disposes of them when they are no longer used.

Since you no longer have to manage the servers, but only the code you want to execute, these architectures are called Serverless. The term is quite generic and actually indicates many different solutions. UsuallyServerless refers to the ability of cloud providers to run "blocks of code," usually called functions, in architectures that are already assembled and ready to use. This is why serverless is usually said to provide a FaaS, or Function As A Service.

The cloud provider offers you the service of running your functions without you having to manage or know anything about the actual servers that run them and the software architectures that run that code. These architectures are usually "elastic," meaning they create and destroy the servers you need depending on the load.

The proprietary serverless of cloud providers.

Serverless offered by cloud providers is extremely attractive because of its ease of use. Indeed, this also results in dramatically lower costs. However, it comes with a huge drawback. The serverless services offered by the various cloud providers are all proprietary.

Indeed, each cloud provider offers its own serverless solution, which, in terms of coding standards, user interface, and constraints to which the code must adhere, is unique to the cloud provider.

Not only that, generally the FaaS of the various cloud providers offer only code execution services but require hooking into other cloud provider services in terms of database, message queues, storage, front-end, and so on.

In short, FaaS becomes a "gateway drug" for vendor lock-in to numerous cloud provider services that many companies find unacceptable. For this reason, companies today often try to go to the cloud using solutions that work in multiple clouds.

Docker and Kubernetes.

Most companies know how to configure their servers. The concept of setting up servers is part of the competence of many companies.

This is why the practice of using so-called Docker containers has become widespread in industry. It is a standard for "packaging" applications with the operating system that has to run them.

Basically, a container alone provides the same functionality of an entire server. But it is much easier to create, smaller, and can be easily move to the cloud. That is why people prefer to package applications in containers rather than creating entire servers.

Once applications have been packaged in containers, they need to be assembled into a collection of cooperating services. This operation is called "orchestration," and it is done by a piece of software called an orchestrator. Today, the market leader in this market segment is undoubtedly Kubernetes.

The advantage of Kubernetes is that it is available in virtually all clouds, and thus is often considered the preferred approach to "going cloud" and taking advantage of cloud features without tying yourself to a single cloud provider.

The disadvantage of Kubernetes, however, is that it does not provide anything "off-the-shelf." It is, simply, a tool for coordinating and connecting the various containers. Companies are left with both the burden of creating the docker containers and, more importantly, the responsibility of orchestrating them.

The complexity of Kubernetes is a well-known pain point in its use. Companies have to incur considerable expenses to be able to assemble systems in the cloud. And in doing so, they reinvent the wheel every time nowadays. They need the ease of use of serverless, which provides ready-to-use architectures.

Serverless and Kubernetes together, is it possible?

Serverless offered by cloud providers is simple and inexpensive, but proprietary and binding to vendor-lockin. Kubernetes frees you from vendor lock-in but also exposes you to considerable costs to manage its complexity. One wonders: but is it not possible to have the benefits of servlerless and the portability of Kubernetes?

In other words, isn't it possible to implement a Serverless cloud provider-like environment using Kubernetes as the execution environment, so you get the best of both worlds: a ready-to-use architecture in a portable environment?

The answer is yes. There are serverless solutions for Kubernetes. And Nuvolaris is one of them.

Nuvolaris: open source Serverless for Kubernetes.

Nuvolaris is a distribution of Apache OpenWhisk.

A distribution is a software product ready to use and support the end user of open-source projects. Those projects are usually provided only in source code and come without support.

Apache OpenWhisk is an open-source project started by IBM and developed with contributions from other vendors such as Adobe, Naver, Digital Ocean, and Nuvolaris.

It is a Serverless environment that runs on Kubernetes. As a result, it has the advantage of being portable to all clouds. It runs on Amazon, Google, and Microsoft clouds, but also on other lesser-known clouds, and on private clouds and servers.

It is a complex architecture that enables cloud-native applications to be developed very easily. It implements a FaaS, thus allowing applications to be developed using simple code, written in various programming languages.

This code only needs to implement the business logic. It can be written by developers of no knowledge of cloud and distributed applications.

Everything else, such as dynamic server and container creation and all the features you need for cloud-native development are available in the architecture itself.

In a nutshell using Nuvolaris you can achieve cloud-native development by leveraging the power of the cloud at a low cost while maintaining independence from the cloud provider. And the product itself is open source and therefore freely usable by everyone.

Nuvolaris aims to democratize the development of cloud-native applications, making their development easy and widespread, in the same way, Wordpress made building websites a breeze and available to everyone.