Why microservices need event-driven architecture
Microservices promise to help break down monolithic applications and enable the consistent delivery of services. But they can't do the job without help. This is where event-driven architecture (EDA) comes into play.
In the following Q&A, Jonathan Schabowsky, Field CTO of Solace, provides greater insight into the growing convergence of microservices with EDA. and argues that a true understanding of it will be essential for organizations looking to get the most of their microservices-based business applications.
Q: How do you see the industry in terms of microservices adoption?
Schabowsky: We're seeing more microservices being built into transformation projects, breaking down monolithic applications into self-contained, independently deployed services. The latest O'Reilly study shows 61% of enterprises have adopted microservices. In my experience, however, only a small subset of those companies have been able to incorporate event-driven microservices into that work.
Q: The survey also suggests that close to 40% have not adopted microservices in a profound way as of yet. What's at issue?
Schabowsky: The application of microservices is, of course, more complex than meets the eye. In fact, it brings with it a lot of issues -- it can be fragile and not coincide well with existing legacy ecosystems. Not all microservices are identical, and don't always deliver the enhanced scalability and agility that are promised.
One major barrier is the service decomposition paradox -- the smaller the microservices, the more services required, leading to stability and performance issues due to typical distributed system issues such as network latency. Because of this, user experience can suffer as well. There is a balance between decomposition and an architecture that minimizes latency and maximizes performance.
Q: Does legacy integration present a challenge for fulfilling a microservices architecture?
Schabowsky: Here's the disconnect -- many existing systems live on premises, while microservices can live in private and public clouds. The ability for data to transit wide area networks, which are often unstable and unpredictable, can be tricky and time consuming. Add to that the challenges being created by the Internet of Things, big data, mobile devices. This creates significant risks to microservices initiatives.
Older systems are not quick and easy to update, but on the flip side microservices need to be swift and flexible. Older implementations rely on aging communication protocols, while microservices rely on APIs and open protocols. Most legacy systems will be deployed on premise, while most microservices live in the cloud. Newer systems such as IoT networks use highly specialized protocols, but most microservices APIs and frameworks do not support them as standard. Event-driven architecture addresses these mismatches between legacy systems and microservices.
Q: Please describe how an event-driven architecture works in a microservices setting.
Schabowsky: EDA takes data from being static to fluid. For example, stuck, at rest in a database locked underneath an API to being fully in motion - consumable as business-critical events happen in real-time. RESTful Microservices alone are not enough.
Q: Give us an example of an event-driven architecture at work.
Schabowsky: Imagine implementing a marketing campaign for a new bank-offered credit card. With an EDA, you can more easily digest account creation events -- such as such as opening balances and addresses -- and use the metadata in follow-up marketing efforts. Other businesses can, by combining EDA and microservices, build highly distributed, scalable, available, fault-tolerant, and extensible systems that are capable of consuming, processing, aggregating, and correlating large amounts of events or information, in real-time.
Modern events platforms must also assist DevOps automation and provide an almost entirely self-service process for developers. Businesses need to be able to go with the flow in a rapidly-changing world. They need applications that can adapt to their needs, and event-driven microservices enable that.
Q: What about the tooling for event-driven microservices? Is it ready?
Schabowsky: The tooling is in place for synchronous request/reply microservices, but unfortunately data collection and communication has been heavily neglected, which has meant that the tooling for asynchronous event-driven interactions between microservices now severely lags behind. Many gateways and service meshes or API management solutions have focused on synchronous, request/reply exchange patterns. The catch is these tools don't integrate with legacy systems.
The eventing/messaging tools we have historically seen out there aren't compatible with today's agile development approaches, and don't function well within DevOps or self-service environments. But it is eventing/messaging that handles the characteristics of distributed computing best. That lack of eventing/messaging tools is keeping organizations from embracing event-driven thinking and using event-driven architecture to unlock the potential of microservices architecture.
Q: Is this where orchestration comes in?
Schabowsky: As I mentioned with the service decomposition paradox, the smaller the service, the less value it discretely offers the end user. The true value comes from orchestration of these microservices. Think of composers creating musical scores involving a wide range of instruments. Then think of each score and musician as a microservice, as part of a complex symphony. Such orchestration is required in an enterprise with many complex applications. A microservice may produce an event, but does not control when it will be processed -- this is up to other services. This requires microservices orchestration.