All the pros and cons of Kubernetes are coming from its nature of a multifunctional platform with tons of possibilities you cannot cover alone, or even with your team over a short period of time.
You need an additional pair of brains—like Dysnix.
Serverless architecture benefits are irreplaceable for some types of projects, but you have to think really carefully if your app fits this category.
What do they heavily differ in?
What do they have in common?
Both tools can be applied for a microservices approach.
They can be launched in the cloud.
Apps start in one go (takes a few seconds).
Both systems work through third-party tools via APIs.
These two structures are isolated environments.
Use cases overview
Okay, that was huge, but we've only got closer to the most interesting part of the use cases overview, where you'll be able to find your app's case and see our recommendations.
When to use kubernetes
The general cause to use k8s is a need for flexibility and the absence of problems when it comes to the migration of legacy projects with a myriad of third-party connections and data flows to running all sorts of applications, whether that is a modern cloud-native distributed application or a bunch of simple websites with MySQL database.
Your other possible demands:
If you want to scale your app in the future constantly and always be ready for the latest innovations.
If your project needs to deal with different versions — both old and new — of the software on different platforms. With containers, you'll get the most adaptive and responding soil for creation of all requirements for your app.
If you have long ago developed legacy software that you want to modernize with a containerized environment expecting to get better productivity—or you have a monolithic app that you want to rebuild in microservices.
You want to implement CI/CD for your project.
You have additional requirements to security, resource allocation, or admin policy.
You have complex application requirements: certain programming languages that might not be supported by a cloud provider; low level APIs such as thread control; stateful components or long-running tasks; heavy usage of the JVM, especially concurrency; real-time distributed systems.
If you have an enormous e-commerce project, all processes and functions can be repacked into containers with zero changes to business logic.
Your team has a DevOps part and/or k8s engineers, so you don't need to hire additional staff for launching k8s.
You currently run your app on-prem, in a cloud, or hybrid on dedicated servers or VMs and look to modernize and optimize your environment.
There's no option of vendor lock-in for your project.
You're ready to invest resources in k8s to decrease costs in the future.
When not to use Kubernetes or consider that the process can require extra efforts because of the following possible risks:
Even if you set up automation control of scaling for traffic changes at two levels (pods and nodes), the process of reaction to sharp spikes might take a noticeable time to activate the sufficient reserve of instances. For some projects, each second matters, so we should mention this point. By the way, Serverless scaling, e.g. Lambda & Google Function, can also take time.
The runtime costs are unavoidable.
Complete shutdown when there's no traffic is impossible.
Kubernetes is one of the best solutions for a wide range of apps and services: from websites with small databases to big legacy apps. And even if k8s infrastructure demands a bigger team to handle, and it takes longer to set up and maintain, the variety of open-source solutions will simplify your daily tasks greatly. So with Kubernetes, you pay for more control and options to decrease costs in a flexible but stable environment.
When to use serverless
Long story short, use Serverless if you need to "go fast, not far": quick development and deployment, auto-scaling, and a decrease in minimal possible runtime costs.
More details of use cases for when to use Serverless architecture:
If your team are mainly developers with no operational experience (network, storage, monitoring, etc.), but you want to test your app idea quickly. And if it's working for the customer, you want to scale in the blink of an eye.
You don't plan to migrate or use the same code between cloud providers or do not have a need for this.
Your team reacts completely okay to the programming languages and tool restrictions of your vendor.
You have the traffic spikes and drops pattern, and you want to get the most benefit from it by saving on runtime costs at the zero or low traffic points.
Your team doesn't want to or can't administrate any infrastructure for your app, but concentrates on delivering the value to the end customer.
You can handle sudden spikes in the monthly bills. This may be a problem for startups, where a big cloud bill could get them into trouble.
Your budget does not possess any expenses on backend infrastructure.
If your app (or parts of it) is of event-driven nature that won't be executed for the whole time.
When not to use Serverless and consider the specificity and possible risks:
The vendor's lock-in. This is a great question of credibility. And while comparing Kubernetes vs. AWS lambda, you might get a different level of trust in them, and it'll influence your decision… But still, each cloud provider will limit your event sources, programming languages, and runtime appetites. You should be ready for it. And if you're determined to use one vendor, it would be very painful to migrate to another, or get back to on-prem.
By the way, let us know if lambda vs. kubernetes is an interesting theme for you.
Can't be applied to real-time distributed apps, long-running tasks or processes, stateful streaming processing, and so on. Events trigger the functions and everything must be as simple as possible for a quick response. With a Serverless app, you can't have explicit control over your infrastructure to optimize your performance in any other way.
Sometimes, even Serverless can be expensive. What if the number of events or runtime processes will exceed your expectations? And even if everything is quite controllable, and you'll set the limits of runtime costs, a part of the profit can fade away. Or if you take into consideration the prices of integrations and their payment policies, the final check might be horrifying.
Requirement to store persistent information on disk.
Support for specific protocols (mqtt for IoT, for example) that are not supported by the Serverless platform.
Can serverless and containers coexist and build a reliable hybrid architecture?
We won't live in the 21st century if someone hasn't tried it yet or gone beyond the typical Kubernetes vs. Lambda comparison. The common practice will split your app into microservices-based containers part and cloud-based functions. In these combinations, it's possible to complement weak points of each part.
AWS Fargate gives the freedom to experiment with hybrid solutions by allowing you to work with containers without any concern about servers and clusters. Knative is another example used for k8s, applying the Serverless approach and disabling idle containers.
Let us know in the comments if you'd like to learn more about hybrid tools and the approach behind them.
In summary
We've got through the dark forest of the flaws and benefits of the Serverless architecture, viewed the pros and cons of k8s, and come to a number of summaries. Even if the subjects of our research were totally new for you, we hope that we've clarified some things for you, especially in terms of the advantages of Serverless architecture and Kubernetes in comparison. Also, it would be another comparison if we were to look at AWS Lambda vs. Kubernetes. But anyway, everything depends on your company's structure, development preferences, and resources. And to make the right choice, you have to get information from true specialists in both k8s and Serverless—and maybe even from a third party who says that you don't need any, and see how it'll work for you.
If you have a manual transmission car that is well-tuned to your driving style, then you get used to changing gears and are not afraid of the clutch. as a result, it'll take you anywhere you want until the car runs out of fuel.
But if you need a car that you can just jump into and drive, then maybe an automatic transmission is what suits you now.
Thanks for your attention. Let's keep in touch for our future articles. If we still have something to clarify, you are welcome to give us feedback.
