Microservices: From Hype to Practice
Microservices-based architectures continue to be one of the hottest topics in enterprise IT, and as hype has given way to real-world use, the realities and challenges of microservices have become more sharply defined. Namely, enterprises are finding that microservices can deliver the advantages their proponents promise but that doing microservices well is often devilishly complicated.
Single-function, fine-grained services that can be independently deployed and replaced, microservices differ from legacy approaches, such as hard-to-update monolithic applications in which many functions are tightly coded together. Being intrinsically more modular and agile than these older approaches, microservices promise a level of software development responsiveness that has prompted salivating among the many IT leaders desperate to keep pace with the rapidly-changing digital economy.
Perhaps unsurprisingly, surveys indicate that recent adopters are attracted to microservices due to the same benefits that attracted early adopters: agility, speed, and scale. Arguably more revealing and exciting, surveys also suggest some businesses are not only achieving these benefits but also using microservices in more ways than many anticipated, including both to create new applications and to re-architect existing ones.
Some of the evidence is more suggestive than empirical (such as a strong correlation in some surveys between companies heavily invested in microservices and companies delivering continuous integration and delivery) but some is more specific. T-Mobile,* for example, has leveraged microservices to increase software development release cadences from quarterly to monthly, to weekly, and in some cases even daily — enabling the company to more quickly bring new services to customers.
“In the beginning, we could get away with the systems that we had but to [continue improving customer experiences], you really have to start changing these systems up,” said T-Mobile vice president of IT Chuck Knostman in an interview in 2018. “You have to make that architecture much more scalable and integratable across many, many different business lines.”
But microservices-based architectures are still difficult to execute and manage; companies are replacing big, fat applications with hundreds or thousands of much smaller services — and as the number of services grows, so does the complexity.
This complexity can manifest in many ways. Often, a microservice will present functionality too valuable to confine within the team that created the microservice. It might be useful elsewhere in the company or even to external partners or customers. To fully leverage such a microservice (and many businesses have thousands of them), it needs to be made sharable. The de facto approach to sharing microservices is to package them as application programming interfaces (APIs), then use API management tools for the control and visibility necessary to securely extend the APIs to new users.
“For every microservice we build, we actually produce an API and we can do that automatically,” Knostman said. “When a developer is done building their microservice, they can basically click a button, and the API is available for others to consume.”
Microservices and APIs similarly underpin Flex Digital Health’s* BrightInsight platform, which can integrate data from regulated medical devices to provide real-time intelligence to medical device and pharmaceutical customers. The platform handles over 20 million API calls per day with an average response time of less than a second.
“A lot of different microservices work together to provide functionality for customers,” Ferry Tamtoro, CTO and VP of Flex Digital Health, said in an interview. “Then APIs provide a user-friendly interface for our customers so that they don’t have to access every single microservice.”
But making microservices consumable may be only one aspect of managing microservices complexity. Managing service-to-service interactions may a challenge in its own right, apart from extending any given service to new teams, developers, partners or use cases.
“Many teams at HP are already adopting microservices and container orchestration technology to deliver products faster and cheaper,” said Galo Gimenez, distinguished technologist and platform architect at HP Inc.,* in an interview. “As monolithic applications transition towards a distributed microservice architecture, they become more difficult to manage and understand. These architectures need basic services such as: discovery, load balancing, failure recovery, metrics and monitoring, as well as complex operational requirements: monitoring, deep telemetry, rate limiting, access control, and end-to-end authentication.”
HP and many other enterprises are solving this challenge with API management or through a service mesh such as Istio that provides a standardized way to connect, secure, monitor, and manage microservices, any of which can still be shared via APIs.
As this momentum demonstrates, microservices-based architectures passed the hype test in 2018 and are likely here to stay — but that does not mean it’s always simple for businesses to extract value from their microservices investments. Luckily, with more organizations documenting their best practices, the challenges are becoming more manageable — and the rewards more attainable. It’s become clear that many of the API management skills businesses have already been building can translate to the microservices arena, and with services meshes emerging as another important component, microservices became a bit more user-friendly in 2018, with more improvements and advances sure to follow in the new year.
*T-Mobile, Flex, and HP Inc. are Apigee customers.
[Looking to learn more about microservices? Get your copy of our recent eBook, Maximizing Microservices.]
