Technology Artisan

Today's technology world is mostly composed of "enterprise" software, or mainstream languages. Think kubernetes or python, OIDC and LDAP. Working in this world requires you to know about a lot of those technologies, stay up to date, and know how to tweak the thousands of parameters available to you to make them work exactly as you want them. That's today's equivalent of the manufacturing process, where every part makes sense when you have a lot of the same product to get out of the door, with as little cost as possible per unit. That's working at scale.

In this mode, you try to minimize the cost of every part you create to make as much as possible, with little to no regards to the aesthetics of your system, or the requirements of every single client. The client is supposed to adapt to the product, no matter if the product does not fit the clients need perfectly.

This is why all those software parts need "glue" in between the different components to create a complete system. Thing like Helm, custom shell scripts… Going through the interface between the different sub-systems needs its own translation layer.

The counterpart to the industrial processes is artisan work. When the artisan works, they are in constant relationship with their customer, and strive to understand exactly what the customer want, even when the customer themselves don't know it. They will create a piece that will fit perfectly the spot it is supposed to fit, and make it streamlined and beautiful. They will pour their heart into each piece, taking pride in making each unique piece as good as they possibly can.

The cost will be higher, but the system will fit you exactly.

Think about a standard, store bought tee-shirt vs a custom tailored shirt. If your measurement are "in the norm", then you can easily find a tee-shirt that will fit you. However, having a shirt tailor-made will make it feel much more comfortable, because it was actually made for you and your measurements, not for a standard person. If you have unusually large shoulders, you would have to buy a store tee-shirt a few sizes above to even get into it, and then it would be completely loose around the belly, making it look bad. But a tailor-made shirt will simply have broader shoulders, and adapt perfectly to your morphology.

Think about an ikea cabinet versus a cabinet made by a master carpenter. The ikea cabinet will of course be cheaper, and you can get it right away, but can it fit to a T into this small hole in the wall that you are trying to utilize ? You know that the work of the carpenter will because it is made to fit, and it will fit beautifully within its environment as well, having chosen the correct wood and finish that will match. However, you will have to wait a few weeks for the work to be completed and the price might be order of magnitude different.

The artisan will have the knowledge to make the custom piece, but will also have more limited resources. They will make the best use of those limited resources and of the time allocated for creating their piece.

Now, here is a little secret about today's tech world: The artisan work will probably end up being cheaper on the long run.

• Maintaining a kubernetes cluster is expensive and hard, without even talking about the price of the machines in the cloud.
• Creating a fast, developper friendly, CI/CD experience is expensive and hard.
• Correctly designing a system based on microservices is hard and expensive.

Replacing those with more artisanal work, especially in the beginning will make more sense.

• Having a few machines to manage is relatively easy and cheap
• A simple CLI letting developpers deploy their application is relatively easy and cheap
• A modular monolith is relatively easy and cheap

Notice that I did say that it is relatively easy and cheap. That's because even though it is cheaper, easier and especially simpler than the industrial process, it is usually not simple nor easy either. The tailor and cabinet maker both have a lot of knowledge and experience developped through years of practice to make beautiful, simple and perfectly fitting pieces. The same goes for the technologist. However, a junior developper will have a much easier time learning and improving when working on a beautifully maintained monolith than they will on an equally beautifully maintained microservice-based architecture, simply because of the complexities involved in this last one.

Let's look at a simple example.

You want to add a functionality to a system, without being exactly sure how the interactions with the other components of the system will play out. In the monolith, you can make a good educated guess, write your functionality in a module, and be done with it. If you see that the functionality does not fit in this module anymore, you simply move the code to an other file, and make a simple commit that will show the complete change. In a microservice architecture, not knowing exactly which service will be responsible of the functionality is a recipe for disaster, ie a distributed monolith. If your service starts depending on multiple services and cannot work, even in a degraded state, without those, then you don't have microservices anymore, you just have a more complicated monolith to manage.