Before Kubernetes came to the market the main way of deploying new services was using monolithic architecture. It simplified how applications could be built and deployed to bare metal or virtual machines by bundling everything in a single entity. Monolith integrates well with scalability options of infrastructure by adding new physical or virtual servers when more performance is needed.

ubernetes allows for new ways how applications could be efficiently deployed with microservices architecture where any needed component could be isolated as a single entity and separately deployed from other services. It wasn’t easy to properly architect microservices architecture and divide all services to separate components even Kubernetes do all the heavy lifting in deployment and maintenance. Main advantage of monolith architecture is flexibility to adapt changing business models with needed hardware resources when a company grows over time. With microservices architecture it is not easy to properly predict which components should be separated for future growth and which should be collocated to avoid expensive deployment and maintenance processes. Multiple examples over time showed that uncontrolled numbers of separate microservices were much more expensive to develop and maintain than monolithic ones.

The best way to predict how applications behave is to give them enough time to mature and achieve a proper composition model over many life cycles. Monolithic approach fulfils this requirement by retaining applications as a single entity from the beginning of development and only after some time when the business model matures application can it be splitted with the most efficient way. During this time frame Kubernetes supports scalability needs by allowing adding new replicas of applications represented by deployments or statefulset on the fly for high availability and performance reasons. Kubernetes ecosystem also offers package managers like Helm that bundle all needed configurations that allow to smoothly run even complex software on a cluster. Unfortunately refactoring of monolithic architecture to separate new services from existing applications is expensive and time consuming and error prone.

Microservices architecture lifecycle of applications is much more demanding and challenging because each component needs to be developed and deployed and maintained separately. Even with Kubernetes automation is needed to spend much more time to adjust, maintain and update each of the components separately. Even with all these costs of microservices architecture, the main benefit is that all separated components could be easily scaled up and down dynamically to adjust to the changing environment. When microservices are properly architectured they could lower overall costs for infrastructure because only resource hungry services need to be scaled up and smaller parts of applications need to be rewritten to achieve required performance. The main risk of microservice approach is if application will be splitted to too many separate components overall costs of deployed microservices will be quite expensive and they even require refactorization to adapt to company needs..

In an ideal scenario the most efficient approach would be to cover all phases of application lifecycle over time would be to start application in monolithic architecture and later on when some components need to be scaled up or changed they should be easily migrated to microservices architecture. Unfortunately this kind of transition is not easy and error prone and time consuming. Most businesses won't be happy to pay twice for the same feature only with different architecture. Solving this problem requires migrating from one architecture to another in the most efficient way without expensive architectural changes and support not only move forward but also go back if there is a problem with new code. Even with Kubernetes supporting this transition it still was a challenging and expensive process to do until Kubernetes serverless matured and or even some of them incorporated service mesh.

Serverless solution was known for a long time and first became introduced in cloud providers offering for infrequent jobs and batch processing like AWS lambda. When cloud serverless is used much more often it becomes quite expensive for intensive workloads and batch processing due the pricing model based on requests number.

Kubernetes serverless is based on Kubernetes extensible architecture and provides a way to define serverless objects on the top of Kubernetes distributed cluster. Main advantage of Kubernetes serverless is that costs are the same as for vanilla Kubernetes cluster because we paid only for resources like Kubernetes nodes (run on the top of virtual machines or physical server) and not for requests which is in most cases much cheaper than paying for requests for higher traffic. One of the most important issues to solve when the application is migrated from monolithic to microservices architecture is to provide flexible network management like redirecting only needed traffic from monolith service to microservice one or monitor and detect any issues with redirected traffic. When code is migrated from monolithic to microservice and becomes a separate service the main issue is network traffic could be delivered to the both places at the same time that could lead to inconsistent state and should be avoided to not break application logic. To avoid these kinds or similar situations is possible with Kubernetes service mesh solutions in place to manage all network traffic to and from applications. Knative Kubernetes serverless combines serverless and service mesh which offer a serverless framework for code and network management of traffic inside and outside applications with service mesh. Istio service mesh is a powerful and fully customisable network manager that allows for full control over network traffic from and to applications and inside and outside Kubernetes cluster. Knative supports transit from monolith to microservices architecture by offering a serverless framework that is integrated with service mesh that allow for redirecting and enforcing network traffic only to places that should be. Also it gives developers options to monitor and debug when new code is developed and deployed and revert it to the old service when is needed.

Another Kubernetes serverless advantage over typical microservices architecture is that pieces of rewriting code could be much smaller and much faster to extract and deploy to the cluster. Knative supports some predefined architecture and simplifies existing Kubernetes objects for most common patterns to speed up development and maintenance process.

Knative delivers the missing link between migration from monolithic to microservice architecture by providing serverless framework and service mesh to manage network traffic.

What is important to note is that Knative is rather new technology and needs to be well checked and tested before any migration process is started.

Kubernetes serverless is still changing and currently the main goal is to make it more lightweight to be able to run function as the service for pretty lightweight approaches which current containers based option is still too heavy in term of resources and how much code to be written.