This article was originally published on The New Stack.

Kubernetes in 2020 has become synonymous with the term cloud native and is also often used as a vehicle for vendors and IT organizations alike to claim they are transforming or modernizing their workloads. But what are they actually transforming? What is Kubernetes itself actually providing?

A top driver for those moving to Kubernetes and modernizing applications is the promise of increased time to value and the ability to innovate faster. But the inconvenient truth of the matter is that many organizations are moving applications from existing infrastructure that is already complicated and moving it to yet another complex platform. Moving to Kubernetes and containers is about de-coupling applications and making them more agile. But if you first have to rewrite application logic in a modern cloud native way, and have to figure out a whole new set of infrastructure, you’re doubling the challenge.

Hiring more people to manage and understand unnecessary plumbing doesn’t make sense. The most successful organizations focus on delivering differentiation.

While Kubernetes is a powerful platform, that power comes with significant complexity and even greater responsibility. It puts more power and control into the hands of developers than ever before, and requires not only a complete shift in your technology stack, but also in the culture of the organization and development process. All this complexity doesn’t necessarily add business value. After all, it’s hard to innovate when your IT staff is spending more of its time than ever figuring out how to enable the underlying infrastructure in the first place.

When all you have is a hammer, everything looks like a nail. Kubernetes is certainly a big hammer, but there are other tools available in the cloud native toolbox for application modernization. If the business goal is time-to-market and delivering applications fast and in a way that is manageable, secure, and scalable, then most of the time Kubernetes is the wrong choice for your organization.

Serverless Pragmatism

If the goal is time to value and rapid innovation, then Kubernetes is not the answer.

Rather than buying into the Kubernetes dogma, consider what you’re trying to do.

If your goal is to grow your business by delivering an application or service, dealing with the plumbing of an application is not what your users want to pay for. Going a step further, hiring more people to manage and understand unnecessary plumbing doesn’t make sense. The most successful organizations focus on delivering differentiation.

If you do the math, the complexity becomes obviously apparent. For example in the traditional world, an organization might have had 100 servers that lasted for about three years. Then Virtual Machines (VMs) came about and for every server there were 10 VMs, each lasting about six months. Now for every VM, that same organization has at least 10 containers and potentially hundreds if not thousands of microservices communicating with one another, each of which is short-lived — that’s 1010 things to manage. There is no way that is any less complex than what we did in the past.

The business has gone from managing 100 things for a few years to managing literally billions of things over the course of the same timeframe. Though there’s a lot of power in the Kubernetes approach, it’s ultimately a mechanism to just do basic computing and it comes with a ridiculous amount of complexity.

It’s OK to Look Beyond the Kubernetes Hype

Kubernetes and containers are not going away. However, I think that the dogma of embracing Kubernetes complexity, no matter who you are, is not right. The reality of the cost and complexity will tarnish the golden halo over Kubernetes.

So how can you build and run modern applications without Kubernetes?. With serverless, there are no long-running servers, virtual machines or containers. Functions execute when needed as a service and the backend infrastructure is all managed in the cloud by a service provider. Serverless basically allows you to just focus on the business and application logic, so you can gracefully refactor an application and not worry about reconstituting the underlying plumbing to run a new set of services.

The most well-known example of serverless today is the AWS Lambda service., though it’s important to note that serverless is much more than just Lambda — it includes resources like API Gateway, AppSync, Cognito, DynamoDB, GraphQL, S3, Secrets Manager, and many more. There are more than twenty serverless services at AWS (and elsewhere) and with the right management tool it’s possible to disaggregate a monolithic application into building blocks, and prioritizes a smarter, incremental modernization strategy that focuses on parsing out the most critical workloads and components first. We’ve seen it work with organizations of all sizes, including MasterStream and Branch Insurance, where complex business logic has been modernized with serverless.

At MasterStream for example, the company was able to focus on business logic by taking a serverless approach and is no longer spending time and resources on database management, infrastructure provisioning and other plumbing tasks. Branch Insurance was able to utilize serverless to achieve regulatory compliance with a consistent control environment, without the complexity of additional infrastructure.

Embracing a serverless approach enables your organization to spend time on the things that differentiate you from competitors, which will ultimately deliver a better experience for your customers. It is a fantastic way for organizations to modernize applications and truly benefit from cloud economics: scale and elasticity, speed, security, and a focus on the application — not unnecessary infrastructure complexity.

Serverless allows enterprises to focus on delivering real impact to their users, to their customers and to their business, without needing to worry about the complexity of Kubernetes container infrastructure or finding the right talent to manage and maintain it.