Microservices Architecture - Functional Decomposition of a Monolith- where do we start ? -a practitioner's view
In the past few years, there have been a lot of hypes regarding converting a monolith into a set of independently deployable services following the principles of Microservices. There are obviously large benefits and there are hundreds of articles in the literature that support the pluses of doing Microservices. Instead of focusing on pluses of doing Microservices, this article will focus on various questions that an organization should ask before initiating an effort towards delving into Microservices architecture. Microservices is no silver bullet by any means. There are few things we need to ask just to measure the team preparedness. This article will focus around those questions below.
While this is true that Monolith comes with issues (large code base, takes lots of time to deploy, brittle, hard to scale, difficult to maintain, hard to introduce new databases (so called fit-for-purpose DBs) and programming frameworks including NoSQL, etc), it's also true that it's simple and easy to develop and deploy, and if designed right, could be scaled as well. So the big question is : when and why would you subscribe to Microservices architecture ?
From my experience, there is no single answer to this question. It all boils down to your individual needs, meaning your business and technical reasons for embracing Microservices, which in turn translate into answering and analyzing the following questions :
1. Do you want to get product features and functionalities available to your end users faster to stay ahead of competition ? do you want to deploy your product in the public cloud or in a hybrid-cloud environment ? Do you want to employ modern tools, programming languages, frameworks, databases, to solve scaling and performance problems ?
2. How is the skillset of your engineering team ? are they innovative and fast-moving ? Can they take calculated risk of introducing new tools, new technologies, new frameworks, new DB technologies including NoSQL, in-memory DBs, columnar DBs, Document DBs, etc ?
3. Can you afford to create a dedicated team focused around converting your monolith to Microservices architecture ? Remember, this conversion can not be done part time or during weekend.
4 How is your current team going to embrace automation ? Each microservice is going to be designed and coded and supported by a set of engineers and this team is going to be responsible for building the service and running the service. are you ready for this culture change as the role of traditional IT Ops will need to change - basically no more IT ops migrating the code blindly into production, for example ?
5. Last but not least, not everything will be easy during the monolith to Microservices transition. are the leaders going to stick with good, bad and ugly phases of this conversion ? This architecture will introduce new DBs, new functional programming languages, new ways of dealing with distributed transaction, New ways of scaling applications, just to name a few. Remember, at the heart of Microservices are the concepts of polyglot persistence (fit-for-purpose DB technology suitable for a particular use case) and Command Query Responsibility Separation (meaning separate out reporting from transaction, to put it simply). Both of these principles are very hard to get right from design and implementation point of view - team will stumble, sometimes the progress will be slow. Understanding the business domain is key and understanding of service boundaries is key as well. Not to mention, avoiding distributed transaction through instituting event sourcing and employing event-driven architecture is another big area of focus. Getting scope of each Microservice just right is an art - therefore one learning from a practioner's point of view is that spend lots of time thinking about service boundary to avoid inter-service dependencies when it comes to dealing with business transaction - model it right. Spend quality time breaking down your monolith using domain-driven-design technique. This will pay off.
In summary, my intention in this article is not to give you advice and direction towards tools, technologies and techniques that are routinely used to convert monolith into a set of Microservices, instead my goal here is to ensure you think through all aspects of this undertaking, particularly challenges of doing Microservices and whether the team and leadership are fully aligned. Its not about new tools and technologies even though they are important and you will need them, instead it's about solving business problems in an efficient and scalable manner with business agility taken into account. While microservices architecture has lots of promises and I have seen it work very efficiently in a fast-paced innovative engineering organization, my advice will be, before you take this on, to really understand what you will be getting into by asking yourselves the above questions - get alignment, start with few independent services first, get familiarity with technology space, automation, continuous deployment and continuous delivery. This methodical approach will go a long way.
