Author: Jonathan Schabowsky

  • 3 Quick Fixes for Event-Driven Architecture (EDA) Complexity

    3 Quick Fixes for Event-Driven Architecture (EDA) Complexity

    Event-driven architecture (EDA) and the adoption of event streaming throughout enterprises are increasingly becoming essential architectural requirements for businesses across almost every industry. However, the more companies use it, the greater the complexity becomes. Event portals can play a pivotal role in not only gaining comprehensive insights into the intricate and expanding event-streaming ecosystem but also facilitating the auditing, management and governance of events.

    According to a recent IDC Infobrief, 93% of companies employing EDA across various applications reported that EDA either met or exceeded their expectations. Moreover, 82% of IT leaders intend to apply EDA to two to three new use cases within the next 24 months.

    Nonetheless, the number of event streaming use cases results in a surge of data volumes. This, in turn, entails the adoption of more brokers, projects and products for event streaming. For instance, an organization might use open source Kafka for one specific use case while turning to brokers like Confluent for another and Amazon MSK for yet another distinct purpose.

    While the real-time processing of data is certainly a positive development, numerous experienced EDA adopters have yet to maximize its potential. Frequently, the situation involves a one-to-one exchange, where a stream is consumed only once, or organizations, having advanced through various stages of maturity with multiple streaming use cases, find themselves entangled in a complex network of brokers, clusters, topics and overlapping schemas.

    Let’s explore three typical challenges that organizations encounter as they progress toward event-driven maturity.

    Success Needs Visibility – Make Sure Your Event Portal Can Provide It

    Application decoupling is great for runtime, but this lack of visibility on both the publish and subscribe side can cause issues when making changes to existing applications. Application producers don’t know who the consumers are and consumers don’t know who the publishers are.

    An event portal offers a single window into an event-steaming ecosystem. It provides a native discovery agent to scan, for instance, a Kafka cluster and its schema registry to produce a visual representation of every topic and its schema(s) across multiple versions–and, importantly, who its consumers are.

    If an organization were to decompose its monolithic applications into event-driven microservices that communicate with each other via, say, Apache Kafka, one of the biggest challenges is to understand and manage the infrastructure and information flows.

    Specifically, how to see the microservices affected by a given change before deploying a new feature or function to ensure it won’t bring that system down – even for as few as five seconds.

    By using an event portal, organizations can automatically scan their system and visualize a complete map of endpoints and event streams instead of manually diagraming event streams between microservices.

    Using Data at Its Best – in Real-Time

    Let’s extrapolate the poor visibility issue from one application across the entire enterprise.

    For instance, if you’ve been using Kafka for several years, especially with many departmental or specific application-type use cases, your Kafka cluster now is a treasure trove of real-time data. But data is most valuable at the moment it’s produced – as per Forrester: “Data is, without a doubt, valuable. But when stored in vaults and locked down, it is not.” Real-time data is the most valuable data that exists. But siloed event streaming data means other departments, decision-makers, customers and partners don’t know about it – therefore, it’s not getting shared or reused to its full potential.

    Typically, developers don’t have anywhere to go to find this data treasure trove. Some have resorted to building Confluence or Wiki pages that try to document that this data exists, using SharePoint or Word documents. Noble intentions, but without real-time data mining and updates, this information quickly gets stale and out of date.

    Again, this is where an event portal makes a difference, providing a perpetually up-to-date catalog of data detailing all topics, event streams, schemas and pub/sub interfaces for each application, along with owners and points of contact, as well as changes for each of the managed EDA entities. This helps expedite development by letting developers easily share, discover and re-use any existing Kafka or event streaming asset, both inside and outside the organization.

    For a real-world example of this in action, look at the Federal Aviation Administration and its SWIM (system-wide information management) infrastructure that distributes real-time information to FAA systems across the United States.

    Through secure gateways, external partners of the FAA can tap into the flow of events. Airlines and other industry partners that need the SWIM data get it in real-time, without perpetually requesting updates. Whether it’s the availability of gates at an airport, the position data of planes in the sky, or the weather for a region – external partners have the latest information without needing to ask.

    Don’t Forget to Govern Event Streams!

    The decentralized and dynamic nature of event-driven systems introduces unique security challenges. One of the common trade-offs with event streaming is that it does include access control rules, but developers can err on the side of being too permissive to ensure agility. If streams are not visible, properly cataloged, and data updated regularly, this presents problems with data security, governance and compliance.

    Using an event portal designed to give organizations visibility and control over their event streaming can turn security from reactive – to proactive. Users can organize systems into application domains, create and import payload schema definitions in a variety of formats, including AsyncAPI, define event interactions between applications and microservices, and create events and associated topic addresses using topic structure-proven practices. With the right visibility, administrators can ensure security, governance and compliance with internal policies and government regulations.

    EDA to the Rescue!

    A single, multi-broker event gateway technology offers a solution for organizations to uncover, regulate and oversee the life cycle of their real-time event streams throughout the enterprise. Its significance will continue to grow as more organizations adopt EDA as a fundamental platform.

  • Best of 2022: Using Event-Driven Architecture With Microservices

    Best of 2022: Using Event-Driven Architecture With Microservices

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Microservices architecture is on the rise, already forming a key part of several current transformation projects, breaking down traditionally monolithic applications into self-contained, independently deployed services that are identified using domain-driven design.

    Stats from a recent study found that more than 60% of respondents have been using microservices for a year or more. In particular, finance and banking lead the way in using microservices, but many other industries are following suit including retail/e-commerce and telecoms.

    Not only do microservices hold the potential for enhanced scalability, flexibility and durability, but the time taken to deploy and maintain components is also significantly improved. This isn’t the case for all microservice architectures. Major impediments come in the form of ecosystem integration challenges and weak distribution processes.

    Busting the Myths of Distributed Computing 

    The implementation of microservices is more complex than one may first think, exacerbated by the fact that many DevOps teams fall into the trap of making false assumptions about distributed computing.

    The list of distributed computing fallacies was originally addressed in 1994 by L. Peter Deutsch and others at Sun Microsystems, and still holds true today. There are key fallacies that hold special importance to microservices implementation: reliable, homogenous, and secure networks, latency is zero and transport cost is zero.

    The smaller you make each microservice, the larger your service count, and the more the fallacies of distributed computing impact stability and user experience/system performance. This makes it mission-critical to establish an architecture and implementation that minimizes latency while handling the realities of network and service outages. 

    Uncovering the New, Updating the Old

    Microservices require connectivity and data to perform their roles and provide business value, however, data acquisition/communication has been largely ignored and tooling severely lags behind. We can see this with API management or gateway products that only support synchronous, request/reply exchange patterns. This only goes to exacerbate the challenges of distributed computing – they don’t have the ability to integrate with or acquire data from legacy systems.

    At the same time, eventing/messaging tools have also been stuck in the antiquated, non-agile world, being incompatible with many of the guiding principles of microservices such as DevOps and self-service. 

    Solving the Logistical Maze of Integration 

    As services become smaller and their purpose more singular, the potential for reusability increases, but that’s contingent on the ability for services to collaborate. Acquiring data for greenfield systems is easy, but microservices almost always come as a side effect of digital transformation, modernization — or the need to build new capabilities at a more rapid pace. 

    The Disconnect

    Most existing systems live on-premises, while microservices live in private and public clouds so the ability for data to transit the often unstable and unpredictable world of wide area networks (WANs) is tricky and time-consuming. 

    There are mismatches everywhere: updates to legacy systems are slow, but microservices need to be fast and agile. Legacy systems use old communication mediums, but microservices use modern open protocols and APIs. Legacy systems are nearly always on-premise and at best use virtualization, but microservices rely on clouds and IaaS abstraction. 

    The case becomes clear – organizations need an event-driven architecture to link all these legacy systems versus microservices mismatches.

    Creating the Perfect Microservices Harmony 

    The smaller the service, the less value it offers the end-user – value comes from orchestration. Historically, orchestration was handled by a central component like BPEL engines or ESBs, or, these days, API gateways.

    Orchestration is a good description – composers create scores containing sheets of music that will be played by musicians with differing instruments. Each score and its musician are like a microservice. In a complex symphony with a hundred musicians playing a wide range of instruments – like any enterprise with complex applications – far more orchestration is required. 

    Microservices are Well-rehearsed

    So, an example of microservices orchestration is when a microservice performs a series of steps within the code. The input or output of a microservice is a data event that has domain significance. But what is key is that since the microservice is merely producing an event, it does not have knowledge of if or when it will be processed. Other services must register their interest in the event, or set of events, and react accordingly. This all needs microservices orchestration. 

    Time to Shift the Focus

    Event-driven maximizes agility as it liberates data from being ‘at rest’ to being ‘in motion’ – consumable in real-time. Choosing the right eventing or messaging platform is one of the most critical steps to realizing the vast benefits of microservices.

    Microservices per se are not enough. Gartner has identified this need as far back as 2018 when it spotlighted ‘event-driven’ as one of its top strategic technology trends, citing “Digital business is event-driven, so organizations need to invest in event-centric design practices and technologies to exploit digital business moments.”

    The Full Potential of Event-driven Microservices

    Merging event-driven architecture with microservices can house major benefits. Developers can build highly scalable, accessible, robust and versatile systems that can digest and aggregate exceptionally large amounts of events and information in real-time. 

    Not only should modern events platforms be able to be deployed in every cloud and platform as a service, but they should also support DevOps automation. In such an ever-changing world, developers need a seamless self-service experience – only made possible with event-driven microservices.