Overcoming Challenges of Event-Driven Architectures

Event-Driven Architecture (EDA) solves many of the difficulties encountered when building and operating classic monolithic applications in which a failure of any service will bring the entire application down. Instead of responding to commands or requests. Services designed using EDA are very loosely coupled to other services. Each awaits the occurrence of specific events to trigger them to take specific actions. Failure of any service will be quickly resolved by immediate re-instantiation of that service. The entire application is never threatened since it is fundamentally an assembly of many individual services.

In earlier posts in this series we discussed the many advantages of EDA and reviewed the challenges that often face those attempting to convert existing monolithic applications into microservice-based event-driven systems or build new systems using EDA. In this post we’ll discuss how these challenges are overcome.

Adaptation to a Different Approach

Solving for many of these challenges requires developers to more aggressively abandon their existing paradigms and preconceptions. Some of what they learned and practiced in building SOA-based applications may apply in an EDA environment, but many run counter to it. They may have difficulty in adapting to the more granular environment of EDA. They may remain more comfortable with their representational state transfer (REST) approach. Their early efforts may be marked by chatty services and continuing to insist that databases are a shared resource.

There is also a natural tendency to avoid the risks created by such radical change as the change from monolithic to microservices and EDA.

Improving and Adding New Skills to Overcome EDA Challenges

Tracing code in a monolithic application is straightforward since all the code for all operations is contained within the monolith. Developers will need to learn the principles of tracing events that occur between services and the reactions those services will produce. A tremendous change of mindset is required to make this transition.

This change of mindset will create need for adoption of new tools. Prior tools were not designed to take advantage of new developments such as microservices, containerization, polyglot environments and more.

In an EDA environment the greatest development challenge will be identifying dependencies and interactions between various services. Rooting out problems will be impossible without using tools designed to assist.

Governance is Critical

Especially given the enhanced ability to have multiple teams developing different services that will all ultimately need to interoperate, the establishment of standards and a process for assuring adherence will be critical to improving time and cost of usable product. Nomenclature, variable labels, and others must be carefully aligned between domain owners. Not only will code development benefit from standardization, so do the various databases each service interacts with. Even logging of policies, procedures, and frequency should be aligned within governance.

Also, protocols and standards must be shared across all teams to assure that the application will perform flawlessly.

Aligning tools used between teams is also valuable to overcoming many challenges. Team training and orientation should be provided regarding tool selection and application. Continuous monitoring of these processes will be accomplished through consistent evaluation of logs.

Team governance is also required to assure that each team is not only composed of developers and technologists, but also of domain experts whose purpose is to keep the services aligned with the business operation objectives of the project. Returning to the mindset issue, EDA development cannot be technology-biased or data-centric. EDA is best employed to respond to business-relevant objectives. One key manifestation here is to focus on database transactions, but EDA should always be focused on business processes.

Revisiting the Major Challenges of EDA

Loosely-coupled events, services, and processes are key components of any EDA strategy. Services and events only become more valuable when the focus is maintained on the business processes they support, and not the databases.

While it may represent something of a leap of faith, business and workflow logic will sooner facilitate development and tracking of EDA code and process flow. Since the logic is most often altered by response to events occurring between services it becomes difficult to follow the logic technologically. It is far simpler to follow the intended workflow in terms of business operations to assure that each event triggers appropriate responses.

The Unknown results that can occur between different microservices is most often analyzed by developers with deep technical knowledge. But for the domain expert, what should happen in the normal flow of business is much more apparent, not really unknown. Pairing their domain expertise of what should happen with the developer who is building the code, is a powerful way of making the unknown known where it counts most, in the services themselves.

The Unforeseen becomes more and more challenging as the ecosystem scales, and is harder to provide contingencies for as undesired results are often not occurring within any one given microservice. Deep understanding of the business processes supported is required to anticipate the unforeseen and provide a more resilient application ready to handle a greater scope of possibilities. One area of particular sensitivity relates to the sequence in which things occur, which may be highly variable. The best response to each possibility in each possible sequence.

When EDA is NOT the Best Solution developers must be able to see and recognize that EDA is not the best solution for any given application. With the proper granularity, the right combination of domain and technical expertise, and the careful identification of all possible events and their responses, EDA enables microservices to become the foundation of a highly interactive, interoperable solution.

 


Event Driven Architecture Table of Contents: