Scaling Microservices with Contract Testing and PactFlow

API growth continues to rise within the modern enterprise. Microservices, are a leading growth driver for APIs as development teams continue to break down monolithic systems, seeking to capitalize on the advantages of decoupled capabilities. Benefits such as reduced costs, reduced time-to-market, faster release cycles and decentralized evolvability are possible. However, as APIs become increasingly prolific and central to core business functions, such benefits do not always linearly scale. There is potential for the complexity of ensuring the overall system (e.g., the interconnections between all microservices) continues to behave as expected, to surpass the anticipated benefits.

Traditional Approaches

Difficulty in achieving expected gains following a transition to more distributed architectures, can be traced to the strategies and practices employed. Teams often continue to have an over-reliance on end-to-end integration (E2E) testing. While there is merit in the goal of end-to-end tests, which is to provide confidence when releasing software to production, they weaken the very essence of self-contained, evolvable microservices.

Under closer examination, challenges with end-to-end tests become apparent:

• Slow
• Fragile – fluctuating data, wrong versions of code, wrong configurations
• Hard to debug
• Complex environment and data management
• Hard to assess coverage
• Expensive overhead – coordinating large all-in-one deployments
• Teams waiting and sequential flows
• Late Go/No-Go decisions

Figure 1 – End-to-End test requires all components to be available

The complexity of end-to-end testing does not scale very well as the number of microservices, and overall size of the system increase. It’s common for natural entropy of E2E tests to occur overtime, increasing the investment required to keep such a strategy operational.

Communication challenges are another side effect of the increasing complexity within the enterprise landscape. Software teams do their best to follow good extensibility practices and communicate those robust extensibility patterns (e.g., Must Ignore) towards consumers. Nevertheless, without well-established API standardization, governance principles, and review processes at the enterprise level, it can be difficult to know what constitutes a breaking change. Teams providing APIs lose sight of who their consumers are. Consumers lose track of what surface area of APIs they are using. In fact, any observable change in the behaviour of an API will be deemed breaking by certain consumers – an observation known as Hyrum’s Law.

Hyrum’s Law

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody

As critical oversight of the landscape wanes, teams result to alternative tactics aimed at reducing the introduction of breaking changes for service consumers. Most common is to start creating multiple versions of APIs or build similar but new ones. Blind spots in what functionality is providing value to, and used by consumers, make it difficult for delivering teams to follow common programming principles (e.g., YAGNI). The impact can directly lead to an accumulation of technology debt and increasing total cost of ownership

Other obvious overheads are:

• Multi-version management
• Communication and over collaboration
• Environment management – what version is running where

Better Alternative for Quality

Contract testing is an approach to calming the chaos caused by the microservices sprawl happening within the modern enterprise IT landscape. The goal of contract testing is to remove the dependency on end-to-end integration tests and reduce the need to maintain complex test environments.

Contract testing targets tackling the coordination and communication challenges associated with delivering distributed systems. It aims at providing a robust mechanism for consumers and providers to validate if any proposed change will break the contracts that exist on both sides of an integration. This tactic is repeated for all services that comprise the overall system.

Benefits of contract testing:

• Simpler – test single integration at a time – without requiring a deployment
• No dedicated test environments
• Fast reliable feedback – no debug challenges
• Scales linearly
• Allows independent service deployment
• Reduced communication and coordination
• Provider knows who the consumers are
• Provider knows how the consumers use

Figure 2 – What consumers use is recorded to form consumer contracts

Contract testing works by allowing consumers of an API advertise their version of the API contract (e.g., the surface area of the schema they use, the endpoints they consume etc.) to providers, generally through a broker. The static knowledge of how consumers leverage the API gives the provider crucial system compatibility information, enabling them to safely determine if any proposed change will be safe to release.

At SmartBear, we talk plenty about the benefits of enabling quality assurance across all phases of the software and API lifecycles, especially benefits reaped during early phases when there’s a focus on asserting quality. The concept is often referred to as shifting left, and aims at having quality being a crucial responsibility of the whole team, and not solely on dedicated testers, engaging after software is built. In the context of contract testing, you can’t go much further to the left in the delivery cycle than letting developers test locally within their integrated development environment (IDE). Equipped with the knowledge of how consumers use the provider services, enable developers to assess the impact any given change will have while remaining in flow-state on their development machine. Consumer driven contract testing facilitates this verification, usually within seconds, and does not mandate the execution of CI/CD processes.

Although many development teams are aware of contract testing and the value it brings to the software development lifecycle, adoption is arguably low across the industry. Possibly this is due to a perception of how disruptive traditional contract testing tools can be to implement.

Don’t choose between Speed and Quality

Companies should not have to sacrifice quality for speed. The capabilities offered by PactFlow, now a member of the SmartBear family, means that you don’t have to.

PactFlow integrates directly into developer coding practices for building and testing APIs—it breaks down silos and allows for faster innovation for teams of all sizes. Developers can seamlessly test contracts across protocols and languages within a common interface, further smoothing the testing process. They can uncover bugs across their API estate in real-time and before deployment. The benefits proactively enhance API quality and reliability, and simultaneously improve both the provider and consumer experience. For larger teams, PactFlow has intuitive functionality to maintain security and control within the tool by offering role-based access (RBAC), secure authentication, and provide a full audit trail of platform activity.

Figure 3 – Contract testing with PactFlow prevents breaking changes

PactFlow’s bi-directional contract testing capabilities put teams at ease with efficiency and replicability. Using provider-driven contract testing, developers can quickly scale by leveraging existing API documentation investments to create tests reusing the OpenAPI specification. Fast, reliable contract testing enables faster speed-to-market, furthering alignment and collaboration between provider and consumer.

We’re excited to welcome PactFlow to SmartBear, expanding our developer-led toolkit, and continuing to drive quality and governance throughout the software development lifecycle. The ability to assess the risk of change, directly from the IDE, without the need for context switching, strengthens our goal of meeting developers where they are. We look forward to enabling the benefits of contract testing across our products, helping teams tackle head-on the challenges of dealing with microservice and API proliferation.

To learn more, check out the press release or visit https://pactflow.io/.