Kubernetes can seem notoriously difficult to get right. It is! This is true even if you use a managed service from one of the big cloud-providers. Azure Kubernetes Service, Amazon Elastic Kubernetes Service, (yes, even the Fargate variant!), or Google Kubernetes Service. They are all prone to misconfigurations and bad decisions that no amount of managed service can help you with. However, it could be much worse! Imagine you had to use kubeadm to install a Kubernetes cluster from scratch on old workstations in the basement of your office?
I am interested in what it takes to go from a blank slate to a production-ready Kubernetes cluster in Azure Kubernetes Service. I do not know what it would take to get there. What does production-ready even mean? Working towards a production-ready AKS cluster is similar to using the scientific method to confirm or disprove our hypotheses about something. We can have theories and hypotheses that we can confirm, but never prove in any absolute form. With AKS, we can get out cluster to a state where we believe it is secure and that it will be able to handle everything that is thrown at it. We can never be sure though. I would also say that being production-ready is a moving target. We could production-ready today (as far as we can tell), but tomorrow there are 10 critical vulnerabilities discovered in a dependency that all our applications use. Not production-ready any more!
This is the challenge I will take on in this new blog series I am embarking on. This series will be different from what I have written before. In this case I do not know all the answers and all the bits and pieces that I write about. This series will be more exploratory in nature, and what I do in one post might undo what I did in another. Maybe I encounter something that contradicts an assumption I did early on in the series, which forces me to start over. To put it another way: this journey will not be linear, it will take an irregular path with twists, turns, and probably one or more knots along the way. Let me put that last bit in a quote to highlight it:
[T]his journey will not be linear, it will take an irregular path with twists, turns, and probably one or more knots along the way.
Along the series I will have a git repository where I keep all code related to the project. The goal is that each post in this series results in one commit on my main branch, but sometimes that might not be possible.
This series might be the longest running series I have ever written. That is a bold statement to make in the introduction to the introduction of the series, when nothing else has been written. To not having to pay for expensive services in Azure during all the time I am writing this series I will keep everything as code, which will allow me to destroy everything at will and set it back up when needed.
What should we run in the cluster?
What will I run in the cluster? This is the most difficult question. It has to be an application that is complicated enough to warrant a Kubernetes cluster and allow me to use some of the most common Kubernetes features. At the same time I am primarily interested in the design of the Kubernetes architecture and not really in the design of the application that will run there. Ideally the application will consist of a few components that need to communicate with each other. Hopefully each component will be simple enough to be 100 code lines or less.
I decided that I will set up a simple e-commerce website. The website will have a frontend, and a few backend services:
- A user service that keeps data about registered users and allows users to sign-in.
- A product service that provides the website with available products and their metadata.
- A cart service that keeps track of what the customers have placed in their carts.
- An order service that will receive and process orders.
This is a basic e-commerce website, and the features are limited. This application will allow me to set up a few different services running in my cluster.
For users of my e-commerce website the following use-cases will be implemented:
- As a user I want to be able to sign in to my account
- As a user I want to be able to browse products and add them to my cart
- As a user I want to be able to place an order
What about the tech-stack?
When making technology choices for a project you should stop and ask yourself a few questions:
- What is the problem you are trying to solve?
- Do you have any current environment you need to take into account?
- Do you have any constraints on the choices you can make?
You should weigh different options against each other and select the one that suits your situation the best. There is almost never a definite answer, there are always tradeoffs that you have to make.
I will take this advice into account along the journey. However, as hinted about above (twists, turns, knots), I will not be afraid to change my choices along the way if I feel that it would make sense to do so. The only choice I will make right now is that I will use Azure Kubernetes Service (AKS) as the Kubernetes cluster. This is because the whole point of this blog series is for me to learn more about AKS, and specifically to make a production-ready AKS cluster.
In the future I foresee the introduction of other technologies in the spirit of simulating a migration from one tool to another. One concrete technology I want to introduce is HashiCorp Vault. Why? Because I am eager to learn more about HashiCorp Vault, to compare it to alternative products and see what its strengths are. Maybe I will perform other migrations as well, for instance to replace one GitOps operator with another. These migrations will be done in the spirit of testing what exactly it entails to perform these kinds of migrations. But as I said, this is for the future.
Blog post timeline
Just as with other blog series I have written in the past I have no planned schedule for when new posts will come in this series. Sometimes I will post often, sometimes I will not.
That was a short summary of what this new blog series will be about. I feel that I am aiming very high with this one, but I hope I will get there in the end! In the next part I will start designing my AKS environment and hopefully get an initial cluster up and running. I will also set up the git repository that will be the home of all the source code related to this project. See you there!
Top comments (0)