Microservices: Hype vs. Value
Microservices: Hype vs. Value
This article follows the mounting hype around microservices and examines the actual use cases versus costs of microservices architecture.
Join the DZone community and get the full member experience.Join For Free
Deploy commerce faster and keep pace with the demands of your customers and executives. Read this blueprint to learn how to create your own microservices-based commerce foundation so you can quickly move onto building innovative and unique shopping experiences for your customers.
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. 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 a 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.
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.
In the healthcare industry, data interoperability has long been considered a holy grail. And eight years after the passage of the HITECH Act, which promised to create incentives for healthcare providers to “meaningfully use” electronic health record technologies and open access to medical data, interoperability still remains a massive challenge.
Late last year, the US Department of Veterans Affairs announced the completion of a Proof of Concept for a Digital Health Platform (DHP) which promises a solution to these interoperability challenges. The DHP is a cloud-based technology platform integrating Veteran data from VA, military and commercial electronic health records (EHRs), applications, devices and wearables to a Veteran’s healthcare team in real-time. Delivering on their vision required the adoption of a composable architecture, using APIs to abstract away complexity from EHRs and other systems into discrete units of business capabilities, represented via microservices.
In this webinar, the DHP team will present methodology and technology insights drawn from the public-private collaboration that built the proof-of-concept, and share the role MuleSoft’s Anypoint Platform helping enable this vision.
The value of the DHP team’s approach extends far beyond healthcare or government. IT leaders across all industries can join our webinar to learn how their unique architectural approach can address connectivity challenges. We’ll be discussing how microservices can be used to increase IT agility, as well as how APIs can be used to more efficiently connect on-premise legacy systems to cloud applications. In addition, we’ll be discussing how MuleSoft’s Anypoint Platform supported the development of the composable architecture powering the DHP PoC.
Opinions expressed by DZone contributors are their own.