devopsy.kinsta.cloud

Tag: service oriented architecture

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.

December 28, 2022
Microservices: The Advantages of SOA Without Its Drawbacks
Service Oriented Architecture (SOA) was the great hope of organizations decades ago when they sought to advance legacy system integration, reduce and bypass layers, and rapidly access the system of record. At the time, the existing solution was point-to-point integration, creating a brittle “spaghetti” middle layer that was hard to manage. This was replaced by SOA, which was later augmented with ESB. This fixed the spaghetti mess by creating an intermediate set of layers, which added complexity to the integration process.

Unfortunately, most IT departments with legacy systems and SOA still struggle to be as agile as needed in this ever-increasing global and digitized world.

SOA Solved Many Problems, But Not All

Today, upward of 90% of the world’s enterprise applications are monolithic. When they were created, monolithic design was the best approach available. However, as business needs evolved and the demand for greater agility intensified, developers and IT teams are considering breaking free of these monolithic architectures.

SOAs have become a hindrance, not the solution they once were.

The SOA Integration Challenge

The promise of SOA initiatives was extending the reach of core business functions while reducing the internal expenses and complexity that grew alongside monoliths. SOAs achieved these goals by breaking the core functions of a monolith into web services using protocols such as simple object access protocol (SOAP) and eXtensible markup language (XML).

SOAP was built for universal application communications. Because it’s based on XML, SOAs designed with SOAP could, in theory, be used to create an agnostic integration layer. Rather than struggling to piece together various proprietary systems, these protocols would open monoliths on different operating systems so they could work together.

This agnostic integration layer would let system administrators connect pieces of a monolith to an enterprise service bus (ESB) to achieve an agile, plug-and-play SOA. In some cases, this approach succeeded.

A great deal of “legacy SOA” still provides value. In these cases, the value the SOA provides is the behind-the-scenes server-to-server communication that mostly aids developers. When it comes to serving internal and external customers–and their rapidly changing demands–SOA isn’t always up to the task.

To achieve service integration, the ESB must oversee the messages from start to destination. This communication isn’t as simple as the SOA vendors may have promised. Consider an SOA integration within a core banking application. The message must go from the core application on the mainframe to a branch office server. If the business logic states a message is only relevant for one business day, administrators must decide whether to move it to a queue, log or disregard when the day passes. This is a common scenario for core banking applications in an SOA, but how well does it work?

In this example–and others like it–the ESB must know whether a business day has passed to make the right decision about where to send the message. Therefore, the integration requires an algorithm–meaning that ESB cannot simply rely on a universal rule for sending messages between the monolith and external integration.

When administrators introduce new business logic into the monolith integration, it turns what was supposed to be an agnostic service layer into a new application layer, increasing complexity. Instead of simply integrating the monolith into a new digital service, the enterprise ends up with a larger monolith–one that includes the mainframe and all the new integration stacks.

Despite the promises of SOA, the integration problems result in increased maintenance time, greater complexity of code and software and the continued growth (not elimination) of monolithic applications.

The first rule of effective integration is “smart end-points and dumb pipes.” Building logic and layers into the service layer breaks that rule, increases the overall complexity and adds another legacy application to your portfolio.

Bottom line: Trying to optimize the SOA approach will only result in larger monoliths.

Improving SOAs with Microservices

Using microservice architectures helps realize the original promise of SOAs, delivering the benefits of SOAs while removing many disadvantages.

For decades, CIOs have tried to transition away from monoliths by taking traditional approaches to integration, only to find they’ve doubled down on legacy investments. All these integration stacks end up coupled to legacy systems and only result in more work for the IT team–and a less agile organization.

The integration step of SOA was never intended to include business logic. Trying to force business logic into this approach leads to workarounds and extra effort just to achieve a less-than-ideal result.

The key factor is how to incorporate microservices without adverse effects. Luckily, microservices architecture can be forged from SOAs by introducing these new principles:
- Context Mapping: When replacing an existing SOA, teams must consider the size and scope of the new microservice and apply proper contextual boundaries. For example, SOAs that typically sought broad integration with digital services should be broken down into smaller domains to simplify operation.
- Shared-Nothing Architecture: Too many SOA integrations create sprawling dependencies that create complexity in the tech stack. Microservices avoid these cross-service dependencies. For those looking to move to microservices from an existing SOA, it’s important to look at the list of dependencies and work toward standalone functionality.
Ultimately, the goal should be to refactor monoliths in a way that shifts the IT stack toward microservices. By taking the right approach, you can make the most of both microservices and APIs within your SOA. You enhance your digital journey, leading you to IT efficiency, faster cycles, greater scalability and competitive differentiation.

— Zeev Avidan
January 23, 2020
Containers, Service Mesh and API Gateways: It Starts at the Edge

Anyone embracing container technology such as Docker or Kubernetes has no doubt heard about the associated next big thing: service mesh, which promises to homogenize internal network communication between microservices and provide cross-cutting nonfunctional concerns such as observability and fault-tolerance. However, the underlying proxy technology that powers a service mesh also can provide a lot of value at the edge of your systems—particularly within an API gateway.

Although it may appear that service mesh technologies have suddenly sprung up overnight, the reality is that many organizations have been using what we now identify as a service mesh for quite some time (including Verizon, eBay and Facebook). One such organization is Lyft, a U.S.-based ride-sharing service with a $1 billion annual revenue. Lyft also happens to be the creators of the open source Envoy proxy that is powering a lot of development in the service mesh space, such as the Kubernetes-native Istio control plane and Ambassador API gateway.

The State of SOA Networking

In a talk last year, Matt Klein, one of the creators of the Envoy Proxy, described the state of service-oriented architecture (SOA) and microservice networking in 2013 as “a really big and confusing mess.” Debugging was difficult or impossible, with each application exposing different statistics and logging and providing no ability to trace how requests were handled throughout the entire services call stack that took part in generating a response. There was also limited visibility into infrastructure components such as hosted load balancers, caches and network topologies.

“It’s a lot of pain,” he said. “I think most companies and most organizations know that SOA [microservices] is kind of the future and that there’s a lot of agility that comes from actually doing it, but on a rubber meets the road kind of day in and day out basis, people are feeling a lot of hurt. That hurt is mostly around debugging.”

Maintaining reliability and high-availability of distributed web-based applications was a core challenge for large-scale organizations. Solutions to the challenges frequently included either multiple or partial implementations of retry logic, timeouts, rate limiting and circuit-breaking. Many custom and open source solutions used a language-specific (and potentially even framework-specific) solution that meant engineers inadvertently locked themselves into a technology stack “essentially forever.” Klein and his team at Lyft thought there must be a better way. Ultimately, the Envoy proxy project was created to be this better way.

Working Outside-In: Edge Proxy Benefits

Although the open source release of the Envoy Proxy project made Klein and the Lyft engineering team look like an overnight success in September 2016, the reality was that the journey was filled with challenges over the four years from the initial hybrid-SOA Lyft architecture to their current microservice- and service mesh-enabled system. In a more recent talk at the 2017 Microservices Practitioner Virtual Summit, Klein talked about the essential need for—and associated challenges of—demonstrating business value for a technology-focused migration toward a service mesh network topology.

Klein’s first piece of hard-won advice was, “Start with [an] edge proxy.” Microservice-based web applications need edge reverse proxying to avoid both the exposure of the internal business service interfaces (which would violate the principle of loose coupling) and the high operational overhead of exposing each service via an independent URI or RPC endpoint. Existing cloud offerings are “not so good” in this edge proxy or gateway space, or are presented to engineers as a potentially confusing range of differing products. Instead, Klein recommended starting an implementation of modern proxying technology at the edge, as this provides business value in the form of improved observability, load balancing and dynamic routing. Once an engineering team has understood how to operate proxy technology at the edge, the benefits can be rolled inward toward ultimately creating an internal service mesh.

Evolution of the Edge: From Proxies to API Gateways

AppDirect, an end-to-end commerce platform for managing cloud-based product and services with an estimated $50 million annual revenue, has undertaken a similar journey to Lyft, as highlighted in a recent blog post, “Evolution of the AppDirect Kubernetes Network Infrastructure.” The dynamic and ephemeral nature of cloud technology and container orchestrators such as Kubernetes, which provide many benefits in terms of scalability and resilience, mean that they are additional challenges for exposing public endpoints for business functionality provided via a composite of microservices.

The AppDirect engineering team took a measured approach to solving these challenges, beginning with making core parts of the configuration static (such as service ports exposed) and placing a load balancer in front of each application. Their second iteration embraced more dynamism using HashiCorp’s Consul distributed key/value store and the HAProxy reverse proxy that supported “hot reloading” of configuration as it changed at runtime. Ultimately, however, the team were keen to leverage the richer functionality provided by a more fully featured API gateway.

“The goal of our API gateway was to leave the exposed public APIs untouched and accessible even to legacy URLs and partner-customized domains, yet allow us to grow by ‘injecting’ and replacing old components one by one,” according to the blog post.

After evaluating a series of open source and commercial offerings the AppDirect team deployed the Kubernetes-native Ambassador API gateway, which builds upon the Envoy proxy:

“Relying entirely on the Kubernetes native API—which we know and love—Ambassador is lightweight, stateless, and uses no external datastore. Ambassador exclusively makes use of Kubernetes annotations to drive the active route configuration (i.e., it is the control plane of Envoy’s data plane),” the team noted in the blog post.

Although AppDirect has not fully implemented a service mesh for internal communication, the company is already learning about the benefits of technology like the Envoy proxy and, critically, how to handle deployments of this in production.

Making Sense of it All

The adoption of service mesh technology within cloud native implementations and migrations is only just beginning, but it is already possible to identify that this technology fills a gap currently identified with modern container-based application platforms such as Kubernetes. All of the benefits of a service mesh—such as rate limiting, circuit-breaking and observability—also can be leveraged at the edge of systems. If you want to explore and learn about this technology, starting at the edge of your systems and working inward can be an effective strategy. This can also allow the technology to demonstrate value, such as improved observability and resilience, earlier than attempting to work inside out.

— Daniel Bryant

June 19, 2018