Overcoming Challenges of Event-Driven Architecture

Event-Driven Architecture (EDA) solves many of the difficulties encountered when building and operating classic monolithic applications, where 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 so that 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. We also reviewed the challenges that often face those attempting to convert existing monolithic applications into microservice-based event-driven systems or to build new systems using EDA. In this post, we’ll discuss how to overcome these challenges.

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.

As a result, developers may have difficulty adapting to the more granular environment of EDA, and 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 the radical 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 a need for the adoption of new tools. Prior tools were not designed to take advantage of new developments such as microservices, containerization, and polyglot environments.

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

Governance Is Critical

EDA enhances the ability for multiple teams to develop different services that all ultimately need to interoperate. Thus, the establishment of standards and a process for assuring adherence will be especially critical to improving the time and cost of usable products. Nomenclature, variable labels, and others must be carefully aligned between domain owners.

Not only will code development benefit from standardization, so too will the various databases each service interacts with. Even the logging of policies, procedures, and frequency should be aligned within governance. In addition, protocols and standards must be shared across all teams to assure applications perform flawlessly.

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

Team governance is also required. This assures each team is not only composed of developers and technologists, but also 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 that often occurs 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 because 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 logic is most often altered by the 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 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 unknown results known where it counts most—in the services themselves.

The unforeseen becomes more challenging as the ecosystem scales and is harder to provide contingencies for and as undesired results often do not occur within any one given microservice. A 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 must be identified.

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 is just one of the methods our product development teams use to drive your success. Contact 3Pillar Global today to learn how we can do it for you.

[adinserter name=”EDA Guide”]