Have you ever tried to recreate a dish you had at a restaurant?
…how did that go?
Unless you’re a Chef and found all the right ingredients, I think I can guess your answer.
If you work in tech, you might have heard the most common excuse when something is not working: “…but it works on my machine!”.
I’ll tell you how these concepts above are comparable.
When you run some code on your machine, it might assume that it has certain packages and dependencies installed; even different versions might change the result.
In this case your code might not run on a different machine that is not setup the same way as yours.
When you recreate your favourite dish at home, you might have bought a different sauce, different type of flour, you have different skills to the Chef at the restaurant and even the environment matters, such as fridge temperature and the way your oven cooks. All these aspects will have an impact on the final product.
In order to have the same result as your favourite restaurant, imagine to package it and bring it home with you.
Now you have the same Chef with their oven, their working station with all the right ingredients, all setup in your living room, preparing you your favourite dish.
This is the concept of a container.
You can package your application with all the dependencies needed in a container so that any machine will be able to run it the same way.
Now imagine that you want to upgrade the oven. Unfortunately when you first packaged your restaurant, you wanted to save space and compressed it in one only very tightly coupled piece of furniture that includes oven, working stations, sink, fridge, etc., all connected. You can’t change the oven only, without having to “un-link” it from everything else and that’s a hell of a work. It takes longer, costs more, requires higher skills and you still risk to break everything.
If you had your kitchen divided in stations instead, you would have the working station with the fridge, the cleaning station with a sink, the cooking station with the oven… all separate, and you would be able to upgrade the oven without touching the rest. You simply swap the cooking stations once you have the new oven and your kitchen will keep running the whole time.
In tech, the concept of stations can be translated as microservices.
You should have a “loosely coupled” architecture, which means dividing your application per responsibility, following the Single Responsibility Principle. That way you can make changes to a microservice, without impacting the other ones, in an easier, faster and cheaper way.
Now, to combine the concepts of microservices and containers,
a best practice is to have one microservice per container, and each container would only have the dependencies required by its microservice. For example, the cleaning station wouldn’t need the Chef’s skills, would it? It would need a kitchen porter, who is not needed in the working or cooking stations.
The combination of your microservices, will return your application. It will be easier to manage, faster to deliver, cleaner to change.
Hope you enjoyed my creativity and looking forward to you reading more of my “explaining tech with real life examples” blogs!
Don’t hesitate to get in touch with me via LinkedIn at /debora-piu.
