Microservices is one of the hottest buzzwords in tech right now. But just because something is buzzy doesn’t mean we cannot be pragmatic about it. It is important to think about how you can get the hype to work in your organization.
I draw parallels from my experience of early days of VOIP, SDN, and Cloud. As a marketer, I am very interested in the business value customers get out of technologies––especially emerging technologies. And an interesting trend presents itself when you plot the coolness of these technologies on a graph and see the real value they bring to the market––similar to the hype cycles published by research firms.
Initially, the technology starts as great idea due to a need in some pockets, and the solution is developed to fulfill that need. People start looking at it saying “hmmm…that’s interesting.” Then, as its popularity grows, the technology keeps improving on the coolness factor, and the awareness goes beyond the niche use-cases.
At this point, everyone is focused on only the benefits of that technology. Few people look at the costs––and even fewer question the impact. And soon people start claiming it as the best thing ever. In fact, claims start floating that all the use cases in the whole wide world can be solved by that particular technology––including the ones that don’t even need to be solved using that.
Soon, it becomes a buzzword. It becomes a resume building exercise. Vendors start using it to tech-wash their products. Customers start using it as a label to sanction their existing projects that are not even related to that technology. In fact, more value is made at conferences for that technology than the actual adoption. The coolness starts to crumble. And then there is some sort of backlash. Some of the original practitioners of the technology start boxing the technology back into the niche case it was originally developed for.
But then, as time moves on, pragmatism starts to prevail. Costs and impact become subjects for discussion. The technology is no longer one singular thing but multiple flavors start emerging; for example today, in the cloud, we have IaaS, various flavors of PaaS and SaaS. Also, the market finds ways to integrate the new technology with legacy systems. This is where true value starts getting created beyond the initial niche and to a broader set of customers.
In fact, last year at MuleSoft’s Toronto summit, Ross Mason, our founder, came up to me and challenged us on these very questions on microservices. As it happened, we were implementing microservices architecture internally and having some good discussions with large enterprise customers at that time. The timing was right. Conor Curlett, the microservices expert on our Chief Technology officer’s team, worked with our internal development groups, field, and customers on these questions and came up with a pragmatic way of looking at microservices architecture.
We have defined these six patterns of microservices for enterprises so that you can adopt a microservices architecture that is right for you and an approach that fits the problems you want to address in your organization.
We have laid out these principles into a whitepaper that outlines how organizations should select the microservices architecture that makes sense for their own business, goals, and culture. I encourage you to leverage these principles for your enterprise: Top Six Microservices Patterns For Enterprises
Don’t let the hype cycle overtake the reality of what microservices architecture can do. Microservices doesn’t have to be too cool to be useful, but you need to adopt it in a way that makes sense for you.
This syndicated content is provided by Mulesoft and was originally posted at https://blogs.mulesoft.com/biz/microservices-biz/microservices-architecture-patterns/