Kubernetes is currently the latest and greatest Devops tool. In my opinion, it is the best way for your application to conform to a true Microservices architecture.
After being dedicated to a project where I was working fulltime in porting over a product to Kubernetes, I am very much a fan of the technology and have no doubt, it is the wave of the future for DevOps. It was a great opportunity for me to learn K8s since I had never worked with it before. As a result, it also provided me a good amount of lessons learned that will surely help me in the future with using K8s. I am still not an expert and there is still plenty for me to learn and in this current world of DevOps. It is an evolving industry where technology continues to improve and that is what makes it exciting.
Kubernetes is an open-source orchestration system for automating deployments, scaling, and management of containerized applications. When I first worked on Containers and Docker several years ago, I knew it was a game changer. When I learned about K8s and its popularity, it was no surprise that a management system for containers was a big hit. After attending Kubecon 2018 in Seattle, I became a true fan as I saw how friendly the culture has been in sharing the knowledge and experience from people working in K8s and putting it into production.
In Part 1 of 3, I want to go over some general concepts and ideas that are relevant to using Kubernetes. For a lot of smaller startups that were founded over 5–6 years ago, if they haven’t done a refactor of the application, I will bet that a lot of them still have a monolithic architecture. For companies that are not running in containers yet, this is a great time to spend some time testing out the application in containers in preparation of migrating to Kubernetes.
The concepts I want to address in this post will be:
- Monolithic vs Modular/Microservices Architecture
- Benefits of Microservices
- Mutable vs Immutable Infrastructure
Monolithic vs Modular/Microservices Architecture
Monolithic architecture is when the components of your application are designed to be self contained, interconnected, and interdependent. In a tightly-coupled architecture, each component and its associated components must be present in order for code to be executed or compiled.
Modular or Microservices design is when the design of your application is loosely coupled and each service can be developed, deployed, and changed independently. In general, this design can reduce risk since the modules are independent.
I want to make it clear that Microservices may not always be the right solution because there can be situations where your application can work better with a monolithic approach. If your system is very complex or super simple, there can be benefits of having a monolithic approach, such as better throughput, or just having less elements to test and debug.
In summary:
Benefits of Microservices: Agile development and independently scaled
If your company or team is looking for ways of improving the application architecture, deployment process, CI/CD, adding automation, or ideally all of the above, you should be moving towards the Microservices route.
- Developer independence: Small teams can work in parallel and can generally iterate faster than large teams. Having smaller teams work on different components can avoid conflicts and increase efficiency.
- Isolation and resilience: If a component dies, you spin up another while the rest of the application continues to function. Having multiple instances of each component will obviously help if other components rely on it to function properly.
- Scalability: Smaller components take up fewer resources and can be scaled to meet increasing demand of that component. Components are not created equally. Some components can use a lot more resources or throughput if it has a lot more read/write traffic while other components can have minimal usage but still be important.
- CI/CD automation: Individual components are easier to design for a continuous delivery pipeline. There is a lot more flexibility when components can be deployed separately and independent from each other.
Mutable vs Immutable infrastructure
When it comes to infrastructure design, you want to make sure that your application can be easily updated or modified. Traditionally on physical servers, before the cloud and virtualization, you had to just make updates or modifications on the existing servers. You can do so on a regular basis and as long as you are doing it in a consistent manner, it can be easily replicable and traceable. This is Mutable Infrastructure.
Kubernetes promotes Immutable Infrastructure
Immutable Infrastructure is when your existing servers are not just changed but replaced. With the advent of cloud instances, containers, and VMs, you have the ability to easily swap out old servers with new ones. It allows for a very predictable deployment process and promotes consistency and reliability. Virtualization is fast, easy, and cheap to recreate. It is easy to have version tracking and rollbacks are easy to do. It is easy to use different deployment methods such as rolling restarts, canary, or blue-green deployments.
The biggest advantage of Immutable Infrastructure is that it prevents “configuration drift.”
Each server becomes slightly different than all the others, leading to subtle configuration bugs that are difficult to diagnose and nearly impossible to reproduce.
A great detailed comparison of Mutable vs Immutable Infrastructure can be found here: https://www.digitalocean.com/community/tutorials/what-is-immutable-infrastructure
For the three main concepts that I have addressed above, I hope they are solid enough reasons to encourage and convince anyone to at least consider migrating the architecture to Kubernetes if not just containers. If you don’t, there will be a very good chance that you will be left behind in keeping your technology stack up to date. This is important because it will be hard to attract good engineering talent in joining the company if you aren’t using the latest technology.
In Part 2-Best Practices & Lessons Learned, I will go over some of the lessons I learned from migrating our SaaS application to Kubernetes and provide some tips and takeaways.
In Part 3-Production Checklist, I provide a checklist that might be useful when implementing K8s in production.