What is a headless microservices architecture? How does it help business?
The conversation that comes up again and again is about migrating a monolithic architecture to a microservices one, because it’s headless! But then, what makes an architecture headless — and how can something exist without a head?
Our good friend Ross is starting on his entrepreneurial journey. Let’s check out what he is upto, to figure this out!
Ross has recently started a small business. He buys ingredients, cooks and then sells waffles on his bicycle and he is profitable! It has been a one man journey till now, but he wants to scale!
Key Insight: This is typically how a conventional monolithic architecture (with a head) works. It’s a one monolith show, and it does almost all of your work.
Benefit: Just install it, and forget about it! Well don’t forget, but be at peace.
Ross is bored already! Selling waffles was never the endgame. He wants to scale, and he believes it’s time to start a multi-cuisine restaurant, but there are challenges. Ross cannot do it all. Even a super cook cannot cook all the cuisines that are part of Ross’ vision! Even if he could try and learn all the cuisines, he cannot master everything. And then there is the issue with delivery, he cannot learn and deliver immediately and what will happen when there are multiple orders? Can he cook all cuisines perfectly and at speed? Something’s off here.
Ross is super confused. Selling waffles was so easy!
Key Insight: These are also the typical challenges of a conventional monolithic architecture. When more and more requirements keep pouring in, everything gets super entangled and super complex. Delivering at speed and scaling up when required are not easy at all!
Time to pivot. Ross realizes that each cuisine which he is envisioning can be done with a cook specialized for that cuisine. The operational costs will go up a bit, but it’s worth it. Each customer can order faster, is served faster, the cooking will be delicious and Ross’s reputation will remain unblemished.
Ross also brings in a waiter. The waiter will take the order from the customer, go to the backend, handover the order and finally bring in the delicious dish to the customer. The waiter doesn’t have to worry about anything, as long as the request is fulfilled from the backend!
Key Insight#1: This is how a typical microservices architecture works! No need to worry when another specialty comes up. Introduce another micro-service to service that specialty and we are good!
Key Insight#2: The waiter doesn’t have to think about how the order is cooked as long as it is done at the backend. You can say that he is decoupled from the backend. This is what is meant by HEADLESS in a headless microservices architecture. The presentation layer doesn’t have to worry about what is requested by whom, in what context, in which channel, et al. That’s taken care of by the backend.
In simpler words, the waiter doesn’t have to lose his head!
The restaurant is a super success. Ross is a maverick and he wants to scale. He wants to introduce Thai and Chinese cuisines too. He knows what to do. He is bringing in two cooks specialized in these newer cuisines. He doesn’t have to worry about the waiter. The waiter will take the order, send it to the backend and return with the dish. Magic!
Key Insight: A headless architecture makes it easier to scale and to introduce newer services as newer requirements come in.
Conclusion: In essence, a headless architecture means that the presentation layer (or the waiter) is decoupled from the backend (or the cooks). Are you determining whether to go for one? A good NorthStar can be whether, what you are envisioning is a multi-cuisine restaurant or just selling waffles.
P.S. — Simplified to understand from a business perspective.
