An increasing proportion of Integrella’s work is with businesses that are already well-versed in APIs and microservices development. The reason they have chosen to work with us is not that they don’t know how to build and manage APIs, but because they are struggling to reach the delivery velocity required to help their businesses prosper and grow. In short, they want to know how they can go faster without sacrificing quality.
One of the great promises of microservices is that each service can be maintained independently of the others. The granularity provided by this independence promises speed and agility in delivery. There are, however, some real-world factors that can make these benefits difficult to realize, especially as the numbers of services and endpoints increase. Examples of these factors include dependency between services, testing complexity and differences between services in deployment requirements and management features.
First, the bad news
The unfortunate effect of these and other such factors is to create management challenges for which the solutions often include management practices designed and perfected for monolithic systems. In other words, the advantages of the microservices architecture are often sacrificed in the interest of having an orderly and predictable environment. When this happens, delivery speed suffers.
The bad news for organizations facing this dilemma is that there is no single silver bullet that can double, triple or quadruple the rate at which they can safely deliver change in their microservices environments. These environments are complex systems comprising interconnected people and processes as well as technology, and they differ in important ways from organization to organization. The chances of effecting a major positive change in delivery velocity by adopting a tool or conducting a weekly meeting are slim.
The good news
However there are good – and perhaps best – practices that can be adopted and tuned by any organization seeking to improve its rate of delivery.
Here are a few:
Consistent Layering – Most organizations are familiar with the application network model popularized by MuleSoft. Surprisingly few, however, have applied it in a rigorous way. Having a layering system that is well understood by all of the members of your technical team and by your API product owners reduces the need for case-by-case analysis of the impact of planned changes and will save time and increase efficiency across a wide range of activities.
Deterministic Dependency Management – One of the primary aims of most API deployments is to make the underlying functionality widely available. This does not, however, mean that every API should be available to all possible services and clients, known and unknown, without constraints and controls. Knowing with certainty what services are allowed to invoke what other services is another powerful way to narrow the scope of analysis and testing required to support change. Service meshes, with their built in white- and black-listing capabilities, are an especially good way to control and manage inter-service dependencies.
Workhorse Unit Testing – Imagine that some mythical wizard of software quality could issue an ironclad guarantee about the quality of a newly developed version of a microservice. The guarantee might state the microservice adhered perfectly to its published contract, implemented flawlessly all the management features required by its ecosystem and performed at least as well as its predecessor version while using no more resources. With a guarantee like that a new version could reasonably be deployed to the production environment without any integration testing and with an absolute minimum of ceremony.
Of course, there are no such guarantees. The closest an API team can come is to have excellent automated tests for its APIs covering all the dimensions listed in the previous paragraph. Although these microservice unit tests will never be strong enough to obviate the need for additional quality assurance measures, they can be enormously helpful in limiting the required scope and scale of integration testing. Equally important, this kind of testing also identifies problems earlier in the release lifecycle when the time and cost of resolution are lower.
Query Interfaces – Much has been written recently about GraphQL and, to a lesser extent, conceptually similar technologies such as Falcor. The debate about whether and when query interfaces can or will supplant more traditional RESTful and REST-ish APIs is beyond the scope of these notes. It is clear, however, that query interfaces, for reading data in particular, can be used to reduce the overall number of API endpoints and the frequency of changes to those endpoints required to meet the needs of the client community, assuming, of course, that the client community is willing and able to use them. All other things being equal, fewer interfaces will translate to greater agility and increased velocity, a principle that argues strongly for considering the use of query interfaces.
Twelve-Factor Compliance – Twelve-Factor isn’t explicitly about speed of delivery. Most or all the practices that it recommends are, however, directly applicable to microservices and will contribute to velocity, perhaps immediately and certainly in the medium and long terms. By periodically reviewing its development, deployment and operational practices against the twelve factors, a technical team may from time to time discover gaps between its own practices and some of the twelve factors. Closing these gaps when and as appropriate should help increase the speed of delivery.
Realise the promise of microservices
The possibility of delivering change quickly and safely is one of the great promises of the microservices architecture. Realizing that promise, however, requires carefully selected and tuned working practices, some of which may be challenging to implement. The short-term impact of any one of the practices described in this paper on delivery speed may be small. The cumulative impact of adopting some or all of them, however, could result in significantly increased delivery velocity.
Helping enterprises deliver APIs faster and better is a big part of Integrella’s business. If you want to discuss how these ideas and others could be applied to your API program, please contact us.