It’s been a hot minute since we got into the really technical side of things over here, so let me take you through a recent chat with a colleague about managing complex software systems.
One of the recurring challenges is how to make sure they’re reliable and flexible, this got us talking about some of the tools behind microservice architectures. If you’re not familiar, microservice architectures are multiple smaller programmes that together deliver those big complex systems.
I’ve recently been working with a few of these tools, so in this post I’ll explain how they can work together to make sure what you’re creating is seamless and scalable – with a nice camping analogy thrown in.
What does engineering and camping have in common?
I’ll start with some definitions.
Docker: Where it starts. Docker is a programme that allows you to organise your code into microservices – from here we’ll call them containers.
Kubernetes: This is an open-source tool that allows you to manage your containers.
Helm: This is where it all comes together. With Helm you can automate the deployment and management of your Kubernetes applications.
Going into slightly more detail, a container is an isolated environment for your code. It’s important to note this means that a container also has no previous knowledge of your operating system. An image is a snapshot of this environment and contains instructions for creating the container. The container then runs your code.
Docker images are built from Dockerfiles, these are the text files that contain the commands required to set it up. There are many commands you can use in a Dockerfile including FROM (the base image you want to build from), COPY (files you want to copy from your local environment into the container) and CMD (the first command run on container startup).
Now let’s imagine we’re going camping. In this analogy, our containers are similar to tents and Dockerfiles are the equipment lists needed to set up our tents.
FROM = tent style/design, number of zipped doors and number it sleeps
COPY = the equipment you need in the tent
CMD = first thing you do (boil kettle, nap, grab a beer and turn on the lights)
Summer
Let’s carry on with our camping analogy. You want to start a glamping campsite. You’ll provide the tents, you set your first tent up and like how it turns out. It’s blue, sleeps 4 and comes with solar-powered fairy lights and airbeds with linen. Not one to keep this to yourself, you get some friends to try it out and stay there before you open business to the public. They love it, and you decide that your setup is perfect. You duplicate your setup for five more blue tents and start getting paying customers to stay.
In technical terms: This is at the moment a group of Docker containers, which you manage yourself.
Autumn
Your business is a hit. You’re fully booked for the next 3 months and decide to expand. So far the business seems to be doing well with the tents setup as they are, so you want another group of tents, perhaps in a different colour to make the site look more aesthetic.
You decide to hire someone to manage the original group of blue tents and someone else to manage a new group of 6 orange tents. The managers are responsible for maintenance of the tents, making sure all of the equipment is available and working, and they flag to you if it isn’t. They’re also trained to rebuild tents if they fall down in adverse weather.
It’s quite a nice arrangement. The tent managers are responsible for the details of each setup. It will only deviate from this if you want something changed. This means the tent configurations can be left to them while you focus on the bigger picture – like how to keep cows from the neighbouring field out of your glamping area.
In technical terms: The managed groups of tents are now Kubernetes deployments, each one being managed and maintained without your input via a Kubernetes manifest (a YAML file where you define features of the Deployment). The example YAML manifests below define deployments for blue and orange tents, 6 of each and both sleeping 4 people.
Winter
Now we’re in winter and adverse weather seems to be happening more often. The tent managers have been doing a great job keeping all 6 tents in their respective group well-maintained. But the bookings are thinning and you realise you don’t need to pay people to maintain all 12 tents when a portion of them are sitting empty. You instruct your tent managers to reduce their group sizes to 4 apiece (8 in total).
You also get several complaints about the warmth of the tents. You had perhaps forgotten that this is glamping not camping, and customers don’t expect a temperature difference between a canvas sheet and their own home. You realise that your initial setup may have been perfect for summer but is less so for winter. You tell the tent managers to add blankets and duvets to the tents. These changes seem to do the trick and bookings drift back to pretty much full.
In technical terms: The changes here are things which you would change in the Kubernetes deployment manifest and re-deploy. In the YAML snippet below blankets have been added to the blue tents deployment.
Spring
It’s spring and things are starting to pick up. You instruct the tent managers to increase the tent numbers back up to 6 apiece in anticipation of a flood of booking requests as the winter frosts thaw.
However, the site’s demand doesn’t pick up with the warmer weather as you expected. You wonder what you could do to encourage visitors. You decide to start offering electric hookups and WiFi for the tents. You don’t have the expertise to install and maintain those features, so you employ 2 more people to manage them for you. You initially set the price for each feature at £5 per tent, so people wanting both electricity and WiFi would pay £10.
It works – it turns out that people love coming to fields to surf the internet rather than sitting at home. You are once again flooded with booking requests and figure you can probably raise the electric and WiFi prices. You ask the service managers to start charging £7.50 per feature, £15 for both.
In technical terms: The services you’ve added are Kubernetes objects, such as Services, Ingress and ConfigMaps. There are loads of types of Kubernetes objects which you can add to your deployment to make your application externally available, apply configuration etc. These are also deployed manually via YAML manifests, like the electric hookup example below.
Summer (again)
You’re starting to get the hang of this glamping thing. You realise that there are yearly fluctuations in popularity and predictable variations in the market. Each change is communicated to the managers.
However, you end up communicating the same information to separate people. The tent managers are often busy doing different things to the service managers, so you spend time chasing them down to let them know how many tents are going to be in rotation in the next few weeks. “I sound like a parrot”, you say to yourself, “if only I could just tell one person all this stuff”.
It dawns on you that the factors which change don’t include every aspect of a tent setup or site features. In fact, the variables can be distilled down to a select handful. For a group of tents, the fact that we’re talking about tents rather than brick buildings is a constant. The fact that customers have an 11pm curfew never changes and the fact that the tents don’t include toilets never changes.
The number of beds can change, the style of tents may change and the thickness of bedding provided depends on the season. And so you could actually instruct almost anyone to pass on this information to the tent and feature managers. If you want anything changed you’ll leave a sheet of paper on their desk informing them of the few tweaks you want to make to the site.
It is so much easier now that you just have to worry about a single file, rather than maintaining and considering every detail of every tent and feature on the site you painstakingly set up. You have so much more capacity to concentrate on the bigger picture – like whether a scone has jam then cream or cream then jam.
In technical terms: This extra layer of management is what Helm provides. Instead of individual manifests for each Kubernetes object which you have to deploy yourself, and factors are modifiable via a single YAML file (always called ‘values.yaml’), you can deploy an entire application with a single command, rollback with a single command, update or delete with a single command.
All of the Kubernetes objects (which with some applications can be tens or hundreds) are controlled easily and as a group rather than individually. You’re still able to interact with them at a more granular level, but you don’t have to. The example YAML below shows a values file for the orange and blue tent Deployments. The key variable factors are defined in this file and templated into the Helm chart.
Values.yaml deployment.yaml
Reflecting on your success
Some time in the future you sit back in your deckchair and reflect on how far you’ve come. You now own the neighbouring cow field and the one beyond it, keep the cows in your own garden and can rotate your tents around the fields depending on their muddiness. You asked your site manager to increase capacity, hiring 4 more tent group managers. A new service manager is in charge of the weekly food rota – meat-free Mondays, pizza Wednesdays and fish and chips on a Friday.
The entire site is well-established, but configurable by a single point of communication. All managers are open to changes and flexible enough to carry them out. If the site manager said “site closed” they would all bring their tents in. If the site manager said “the most recent changes have done diddly-squat for our profit margins, we’re rolling back” the tent and feature managers would revert whatever modifications had just been made. You feel like you can easily control this business and everyone is better off for it – a huge success!
In fact, you think you could probably handle another one or two of these…
So there you have it. Using Docker, Kubernetes and Helm in harmony can be as seamless as that. And bonus, your software is now reliable and scalable! You’re able to make smaller changes that contribute to your big picture and there’s limited downtime. Next time you’re considering microservice architecture, think about how the tools behind them can come together to work for you.
If you’d like to stay up to date with all of our latest blog posts, case studies and upcoming events, subscribe to our monthly Made Tech Insights newsletter.
About the Author
Software Engineer
