Intro
- k(8)s – k(ubernete)s – 8 letters – A cluster management software that handles deployment of softwares with a lot of built in features
- Started as a project called Borg by Google 2003-2004, then open sourced it and called k8s.
- k8s – basically can create anything when choosing the right technologies and design. k8s is meant to be flexible for architecting towards a set of problems related to:
- scalability
- fault tolerance
- high availability/self healing/rollbacks
- microservice oriented architectures
- disaster recoveries (GKE version 1.24+ container backups/cloning)
- deployments of jobs/cron/daemon/applications/databases
- Some example use cases include
- Creating globally distributed cache/database
- A cross region Multi-tenancy Architecture (most cloud provider services are separated by regions)
- Large scale thousands of different microservice deployments (service discovery becomes difficult using standard cloud providers)
- To summarise, most of the time you don’t need k8s.
Costs
Management Costs and Learning Curve
- k8s cluster management is non-trivial. There’s a lot of things to worry about on how to do certain things. This takes away attention from solving actual business problems. In larger organisations, the administrative work is handled by a dedicated platform team.
- PAAS today are a lot more robust than it was a decade ago. Achieving similar results such as HA, scalability is most of the time done better by cloud providers themselves. The software is is installed along together as a service provider.
- Take for example to achieve application self healing, rollbacks, and “good enough availability”, we could use
- AWS ECS Fargate
- GCP Cloud Runs
- Proxies and Load Balancers
- AWS – API Gateway + AWS ALB, ELB, NLB
- GCP – API Gateway + HTTP, TCP load balancers.
- Suppose we do this ourselves, the first step is to decide on the correct technology, then figure out the ways to deploy it.
- Take for example to achieve application self healing, rollbacks, and “good enough availability”, we could use
Migration Costs
- In tandem to the above points, teams that are not already using k8s would also have a huge migration and learning curve cost to begin using it. A majority of AWS Service SLA is 99.95% or above. For unspecialised developers to create k8s from scratch, it would be difficult to meet the same SLA initially.
Monetary Costs/Opportunities
- Despite Kubernetes having the ability to easily scale, when evaluated against solutions like AWS Lambda or Google Cloud Functions, it may be economically more expensive to use Kubernetes until application usages goes beyond a certain threshold. Before reaching that threshold, spinning up Kubernetes incurs fixed costs such as deployments of the “API Server” components like:
- Controller Manager
- ETCD
- Scheduler, etc.
- Serverless services are great for short lived applications. This is the main selling point for pricing where cpu can be scaled down during times of low traffic. Serverless architecture is the defacto approach for small teams to create business products. Most products don’t live through the test of time. However, sometimes these applications do evolve into long running processes/jobs. The pricing model differences comes into the picture as Serverless services are typically charged at higher rate than dedicated long running cloud servers like EC2/Cloud Compute instances.
- Furthermore, cloud servers can be reserved/spot instances ahead of time to increase even more cost savings.
- Serverless Pricing models are generally (# of times of calls (requests) + duration of the call)
- Cloud Server pricing models are generally (# of cloud server rental + duration).
- Going beyond pricing and relating performances, Serverless services are less performant than their counterparts in Cloud Servers even with the same CPU/Memory benchmarks. This is likely due to underlying Serverless using heavily shared components like CPU/Memory/Networking. Ultimately because as developers, we’re essentially renting for raw compute power when using Cloud Providers. Serverless being less performant means “worst bang for the bucks”.
- When referring to Serverless, this includes: AWS Fargate, GCP Cloud Runs.
- Again, not something to worry about until there are thousands of services and a lot of them are long running services. The pricing model would then become more transparent in the bills 🙂
A side note, Netflix built something similar called “Titus” looking to solve similar use cases like large scale deployments and orchestration. See below Titus Architecture – look somewhat similar.
Kubernetes
Titus
References:
Coffee Break 
Leave a comment