Microservices First Approach without assessing its fitment is one of the common mistakes one see across multiple engagements. I doubt if there is any development project which does not have microservices tag associated with the same!!! It is quite understandable when technology paradigm goes through the hype cycle. One of the interesting tweets I saw in this space..."If you can’t build a well-structured monolith, what makes you think microservices is the answer?" This tweet highlights the importance of design maturity in the adoption of microservices. That's one of the primary challenges which needs to be addressed by any organization is starting the journey of adopting microservices. I want to cover few criteria for fitment of Microservices Architecture in this blog.
Most important criteria for me is to have the ability to allow independent evolution of sub-capabilities of app/product/platform. This is very important when you are developing the product/platform. I was part of the development of Service Procurement Management product long back. Using the first version of the product, we got the first customer who is fortune 500. Based on that success, we got four significant customers in the immediate quarter, and most of them want to go for a global release. Interestingly those customers came up with their own request for additional features to "sub-capabilities" of that product and so is the timeline for the release. Those feature requests were not only just but key to the evolution of the product. At the same time, there was one case where the customer only wants a subset of capabilities of the product. So we had a scenario where individual sub-capabilities of platform needed to evolve at its own rate and needs to move to production at its own pace. This is one of the ideal cases for the adoption of microservices architecture. Interestingly, this case prompted me in publishing an article on "microservices based development" way back in 2008 in dzone. (Obviously, during that time, the microservices concept was not there in the mainstream, and my initial idea was built using technology elements of that time...I would put it as an idea under evolution :) )
Another important factor one may want to consider whether sub-capabilities of the application have different scalability requirements. For instance, take a scenario of e-commerce platform, one of the heavily used capabilities is product service when compared to order management services as the number of product views turning into order is comparatively lesser. So in this case, scalability requirements for sub-capabilities of the platform are different, so the microservice architecture is ideal in this case. In addition to the same, microservice based architecture could also help in building high availability and highly resilient applications.
Another important aspect I would like to highlight is that when you are not clear about the domain of "problem space (that's of application/platform)," do not start splitting the app into microservices. Early splitting will create more headaches than solve the problem as you will not have clear insight into the boundaries of the microservices
In this blog, I tried to cover challenges and things to take care while adopting microservices. I want to highlight the need for a core team with strong design maturity to drive the microservices adoption. As I said in the beginning, organizations which were incapable of building modularized monoliths have a greater chance of failure while adopting microservices.
Most important criteria for me is to have the ability to allow independent evolution of sub-capabilities of app/product/platform. This is very important when you are developing the product/platform. I was part of the development of Service Procurement Management product long back. Using the first version of the product, we got the first customer who is fortune 500. Based on that success, we got four significant customers in the immediate quarter, and most of them want to go for a global release. Interestingly those customers came up with their own request for additional features to "sub-capabilities" of that product and so is the timeline for the release. Those feature requests were not only just but key to the evolution of the product. At the same time, there was one case where the customer only wants a subset of capabilities of the product. So we had a scenario where individual sub-capabilities of platform needed to evolve at its own rate and needs to move to production at its own pace. This is one of the ideal cases for the adoption of microservices architecture. Interestingly, this case prompted me in publishing an article on "microservices based development" way back in 2008 in dzone. (Obviously, during that time, the microservices concept was not there in the mainstream, and my initial idea was built using technology elements of that time...I would put it as an idea under evolution :) )
Another important factor one may want to consider whether sub-capabilities of the application have different scalability requirements. For instance, take a scenario of e-commerce platform, one of the heavily used capabilities is product service when compared to order management services as the number of product views turning into order is comparatively lesser. So in this case, scalability requirements for sub-capabilities of the platform are different, so the microservice architecture is ideal in this case. In addition to the same, microservice based architecture could also help in building high availability and highly resilient applications.
Another important aspect I would like to highlight is that when you are not clear about the domain of "problem space (that's of application/platform)," do not start splitting the app into microservices. Early splitting will create more headaches than solve the problem as you will not have clear insight into the boundaries of the microservices
In this blog, I tried to cover challenges and things to take care while adopting microservices. I want to highlight the need for a core team with strong design maturity to drive the microservices adoption. As I said in the beginning, organizations which were incapable of building modularized monoliths have a greater chance of failure while adopting microservices.
No comments:
Post a Comment