Once upon a time there lived a monolith application named Mono (creative ah!).

Mono was born into this world as a proof of concept (POC). He was never meant to live beyond a few days. His Creators (developers) showed off the POC to the OverLords (senior management) and gave the OverLords a sense of what could be achieved. The OverLords were so thrilled that they announced to the world, the very next day, that the company had a new product and it was ready to show that off to the world in a week. The Creators were taken by surprise with the OverLords decision but had to comply. They polished up Mono and let him loose into the world. There was a celebration all over the place. Cakes, balloons, and promotions – all due to the birth of Mono. Mono enjoyed the limelight. Plenty of attention and money was thrown in Mono’s direction to add in new features. Life was good!

After a year or so Mono started facing health issues. With the many cakes and celebrations, Mono had become obese. Mono’s “code” had grown so bloated, that even the simplest changes were hard to digest. The original Creators were all gone. The newly assigned Creators did not share the same love for Mono’s bloated “code”. They hated the design and the mess that had become Mono. But they had no choice other than bolting on new features to Mono.

Finally, a day came when Mono could walk no more. Mono came crashing down (and down and down) many times. The original Lead Creator was called in to attend to the sick Mono; maybe he could do some magic. Unfortunately, he could not help much. He only managed to bring Mono back up and running, but Mono was slow. Original Lead Creator declared that Mono was dying and put Mono on life support – no more new features he told everyone. The Original Creator (in tears now) suggested immediate surgery. The OverLords were scared. They stood to lose millions of dollars in business. They immediately approved the surgery at all costs. That started Mono’s journey from the world of monolith to the world of microservices. After an excruciating few months of development, Mono was reborn in a microservices architecture. Mono himself lost 100s of pounds. Mono was nimble and strong once again. Mono’s new name was Mikro. Mikro felt blazing fast. He only had one thing to do and that was it. No more worrying about the 10 other features. Those were born as new sibling microservices. Everyone was born again and felt great again (BAFGA).

Mikro now was able to deal with increased user traffic and called on his sibling microservices to make the users happy again (MUHA). Due to the resounding success of MUHA initiative, the company now had millions of additional users. Life was good again.

After two months, suddenly Mikro noticed issues again. At times his siblings would not respond or they took too long to respond, or even more scary was when Mikro could not reach anyone. It was as if Mikro lived in a dark room isolated from the rest of the world.

The previously happy users were now unhappy. The OverLords were very upset (again), cause their bonus counted on happy users (at all costs). The old Jedi mind tricks were not working. Microservices architecture was supposed to make things great again (MTGA) — but promises were not kept. The OverLords called the Creators and yelled at them. The Creators went back to the drawing board to analyze what happened. They realized that they were not capturing the right metrics to even study the situation, and therefore could not even suggest medical treatment. While Mikro was calling the other services, there was no data about the latency for those calls or if they were even reachable. And this was the same issue that each and every one of Mikro’s siblings faced.

Fear not. There was one among the Creators who was called as GuruNinja. GuruNinja was hired from a job requisition that specifically wanted to hire gurus and/or ninjas. Others were not welcome. GuruNinja created a custom library, called NinjaLib, with some really awesome complicated code that would intercept all the calls to other microservices and collect metrics. NinjaLib would then push the metrics to a central server (NinjaServer was also written custom by GuruNinja) that would then display the metrics on a custom dashboard (you guessed it right — the dashboard was also coded by GuruNinja). Suddenly the Creators had metrics and could debug. They forced all the other Creators to change their microservice code and wrap all network calls with NinjaLib library. The Creators made it happen after a month of feverish coding and testing. Now all microservices were full of NinjaLib library calls. NinjaLib collected metrics on every network call. NinjaLib could also apply some patterns such as load balancing, circuit breaker, or handle timeouts when calling network services. Things got better again (TGBA).

Fast forward another two months. GuruNinja left the company and with him any knowledge about NinjaLib (or NinjaServer or NinjaDashboard). No one knew what to do with it when a bug was discovered or when enhancements were needed to be made to NinjaLib.

Just then it happened that one of the more humble Creators went to a local meetup. There they talked about this thing called Service Mesh (see https://www.nginx.com/blog/what-is-a-service-mesh/ or https://cloud.google.com/istio/). Hmmm, that sounded a lot like what GuruNinja had coded and a lot more features than what NinjaLib provided. And there were open-source implementations available; like Istio, Linkerd, etc. Humble Creator was excited. The next day he talked to the other Creators about Service Mesh. They became excited too. Even more exciting was that the code no longer needed to know about NinjaLib or any specific implementation of such library. Service Mesh proxies could attach themselves to the container (in which Mikro lived) and Mikro would simply route calls seamlessly through this sidecar process.

Without telling the OverLords, the Creators replaced NinjaLib with an open-source Service Mesh implementation. The stealth mode was required since one of the OverLords got promoted due to the success of NinjaLib and might not allow the upgrade (and also with this new Agile thing the Creators were told to empower themselves to make decisions). The Creators removed all references to NinjaLib (or NinjaServer or NinjaDashboard). Suddenly Mikro felt great again (MFGA). There was no strange NinjaLib code and he was once again focused on delivering his core business function vs polluting himself with network reliability-related code. Life was good again (LWGA).

Mikro nowadays lives happily in the cloud along with his other sibling microservices. Observability is being implemented by the platform using the Service Mesh framework. Scaling is being done by the cloud provider. He is excited since he overheard his new Creators talking about giving Mikro new wings by rewriting his features with Serverless frameworks. Mikro is looking forward to the future again (LFFA). But every now and then Mikro has a nightmare about his days as a monolith.

What did we learn…

If you had to start with a monolith – thats ok. Life happens. But if you see it doing a lot more and see symtoms of rot, be pro-active and refactor to a micorservice (style) architecture.

A Service Mesh abstracts away the network from the service. This allows the service to focus on core business functions vs network reliability.

Service Mesh implements – “service discovery, load balancing, encryption, observability, traceability, authentication and authorization, and support for the circuit breaker pattern” – from NGINX article above.

Service Mesh should be an integral part of your architecture going forward. But do not try to build this yourself. Embrace a strong open source implementation.

POC’s can still go into production, so tread carefully.

Stay clear of developers who call themselves Ninja’s and Guru’s.

Finally – Not all Monoliths are bad. Some apps may just be fine being a Monolith. When moving to a Microservice architecture, you are taking on a lot of new challenges (nothing comes free). So think carefully here too!