LinkedIn Facebook Twitter Youtube
Migration To Microservices Architecture – A Miscellany Of Implementation Journeys

Migration To Microservices Architecture – A Miscellany Of Implementation Journeys

Nitika Goel, Chief Marketing Officer, Zinnov; Saranya Elango, Marketing, Zinnov
06 Mar, 2020

“Monolithic Architecture that we were building was great at some point in time. Today, technology teams and expertise are spread across the world. Open innovation is becoming a norm of the day – Innovation is no longer confined within the four walls of the company.” – A fitting opening and an apt context to the discussion summary that is to follow, by Dileep Mangsuli, CTO – India, GE Healthcare, the Session Chair for a panel discussion on the Implementation of Microservices Architecture, at Zinnov Confluence 2019, India edition.

Microservices Architecture is a technology trend that is spurring open innovation, but like any tech adoption journey, it is fraught with challenges. Here are some industry pioneers and the start-up founders sharing their journeys of moving from a monolithic architecture to a Microservices-based architecture in this panel discussion.

Introducing the panelists Padmanabhan Venkatesan, Global Head of Engineering, Hi-Tech vertical, HARMAN Connected Services, Sanjeev Barnwal, CTO, Meesho, and Shashank Murali, Co-founder & CEO, TapChief.

Dileep Mangsuli's quote

Dileep Mangsuli: Padmanabhan, you come from a company with great domain expertise. What really transpired in the company to move over to Microservices architecture and how has the journey been so far?

Padmanabhan: We have been seeing this journey over the past four to five years. It is a combination of several factors, it is just not Microservices – It is Microservices, DevOps, Containers, Agile, Automation, Cloud, etc. This combination has reinvigorated the whole Engineering job market, where people are coming with new skills. Microservices cannot be implemented just for the sake of the technology – it has to be business-driven.

For example, when we started our careers, we used to work on long design documents, and the implementation of the system took almost three years, only to find out that the business has moved on. Companies and competitors like Google, Tesla, Amazon, and Netflix taught us the lesson that if we don’t release updates every day, and make product refreshments frequently, we are going to be left behind. Our sales folks also came back to us and communicated the obsoleteness of the product. So, unless the business realizes the demand, pushing the implementation of a technology does not work.

Microservices is a design concept – it is about reimagining an Enterprise.
So, there are three primary things with respect to Microservices Implementation. They are:
• Businesses must urge to bring about the implementation
• Reimagining design from an event standpoint and not from a static noun standpoint
• Go the whole hog when it comes to Microservices Implementation – Don’t just containerize a monolith in a docker container and call it Microservices. If it is a Microservice, then each and every event has to package its own database, it should be able to network, and remain secure.

That was largely what we have learned from the customers of our internal landscape.

Dileep: Microservices becomes a lot more critical when the systems are complex. When you were starting off as a start-up you wouldn’t have known how complex your systems were going to be. So how did you decide to move to a Microservice-based architecture?

Shashank: I run a company called TapChief where we’re trying to enable an alternative workforce. We started off in 2016 and now we have a headcount of 50. When it comes to us imbibing Microservices into our DNA, it was a function of trade-offs. It was critical for us to move to a Microservice-based architecture because we were facing a completely different challenge. On the backend, we are on Python, Django, Postgres, etc., and on the front-end, we are using Angular 7, and a bunch of other things. As a start-up, with risks associated and with not much credibility in the market, it was difficult to find the right talent especially with the right experience who were willing to work with us. This led us to start using our own platform. We were strong with respect to the backend, but when it came to the frontend, we lacked the required expertise.

There were two primary challenges – We had various types of developers working on our system, and we were doing complicated things and working on solutions for various steps across the business lifecycle, because of which the payloads and bundles were very high despite various optimizations. These challenges were deterring the experience that our product was offering. When we spoke to start-ups on how to solve this challenge, we figured that ours was an uncommon challenge because the start-ups in the market were either app-based, content platforms or e-commerce ones. We were a collaboration-communication tool plus a marketplace. We checked with people in the US, Singapore, etc. to understand what they were solving for such challenges with respect to the front end.

This led us to split the frontend. We realized that the data had to be available across the board from a user’s perspective. From an engineering angle, we thought that running multiple servers, each serving a purpose, was the need of the hour. It made us create various libraries and standardize the way we were doing things on the frontend. This is how and why we adopted Microservices architecture for the frontend. We continue to be a monolith on the backend.

Dileep: Sanjeev, you have used not just your platforms, but also various social platforms to your best advantage. How did you connect a social platform with your platform and create a Microservices-based structure?

Sanjeev: Meesho enables everyone and anyone to set up their social store. We have grown twenty times in the last year. I will talk about how this rapid growth led us to move from Monolith to Microservices.

In the beginning, it is very important for a start-up to iterate very quickly, because, a start-up tries to solve a new problem. So, start-ups talk to the users, figure out what is the right solution for their problem. Given the resource constraints for a start-up in its initial years, doing this in a Microservices setting is very hard, which is why start-ups adopt a Monolithic architecture.

I built the whole thing from scratch and was managing for the next year and a half with just five developers. This is why it made sense for us to start off with a Monolith. We scaled hence, more developers started joining us (20/30 people in the backend).

This gave rise to two major challenges:
• Our iteration pace was getting slowed down
• As we scaled, certain parts of our Monolith got the most hits; it made it economically inefficient for us to scale the whole Monolith.

So, we slowly moved to Microservices architecture. What worked for us, was that we clearly identified the business domains. Ours is a social marketplace, which makes the tech stack very similar to an e-commerce marketplace. So, we identified our domains such as logistics, supply, demand, etc. Then we tried to segregate responsibilities across these domains, tried to establish a contract, and were comfortable with our service getting broken down into further smaller services. The focus was always on building solutions for the users, iterating quickly, and going to the market fast. Now that we have 80 developers, almost 80% of our systems run on Microservices. The crux of it is tech should be viewed as just a tool. There is no one right answer that fits everyone.

Sanjeev Baranwal's quote

Dileep: Be it Monolithic architecture or Microservices, one challenge facing it is security. How do you tackle the security challenges?

Padmanabhan: Security, both in terms of data and platforms, is critical. One of the approaches that we adopt is that we don’t overengineer it. We ask essential questions like:
• What is the administrative overhead?
• What are the leakage zones that we are creating?
• What are the vulnerabilities that we are creating from a network call standpoint?
• How much can we encrypt?

A prudent design from a scalability standpoint and from a security standpoint is extremely important. We have certain design guidelines that we follow. We don’t call out a service that doesn’t fit into the whole scheme of things and focus on hardening the service.

Padmanabhan Venkatesan's quote

Dileep: How do you, a start-up that doesn’t have a security organization stamping before release, ensure security?

Shashank: We realized early on in our journey that the space that we operate in requires a lot of sensitivity when it comes to data (both professional and business data) – the professional data of our customers that include the kind of work that they are doing, their incomes, etc. and also the business side of data that includes the objectives they are trying to achieve through our platform, what they are leveraging the professionals for, etc.

We adopted two approaches:
• Prioritization – Do not touch tasks which you cannot take on today
• Code reviews, mentoring, one-on-one sessions to ensure security, given the fact that our workforce comprises predominantly of young developers who are mostly freshers.

Shashank Murali's quote

Dileep: With financial transactions being monitored closely owing to the Government’s initiatives like demonetization, how do you ensure security?

Sanjeev: Meesho is an extremely data-driven organization that makes the security challenge even more complex for us. There are multiple ways in which we tackle these challenges. They include:

• Ensuring centralized access control
• Ensuring that the ‘principle of least privilege’ is always followed – exposing only the amount of data that is required to arrive at a correct decision
• Encrypting financial transactions and carrying out analysis on the encryption side
• Ensuring the presence of right gatekeepers along the data pipeline

A start-up that is empowering homemakers by enabling them to start their own social stores, another start-up that enables an alternative workforce, an established company that powers automobiles – each has a different story to say when it comes to moving to a Microservices-based architecture from a Monolithic Architecture. We have seen mixed adoption stories of Microservices in the frontend and Monolith in the back end, and that of 80% adoption of Microservices. Clearly, there is no one-size-fits-all solution when it comes to tech implementation, and Microservices is no exception.

Is your organization looking to move to Microservices-based architecture? Drop us a note at for expert insights on the adoption of Microservices and seamless migration to it.