The ephemeral composable stack - HashiCorp: The fine line between independence & chaos

API centricity

Composable has come to mean an API-centric to system design. 

Applications and infrastructure have the benefits of composability when components talk to each other through APIs in order to execute functions and workflows. 

In a ‘composable’ enterprise, new applications tend to be API-first, featuring microservices and other cloud-native attributes. 

Many third-party vendors are also API-first (such as Stripe and Twilio), enabling developers to quickly enhance their apps by taking advantage of the APIs that their applications can be exposed to.

In the older case of heritage [some legacy, some just a little older] systems are more typically API-enabled, so data can easily flow to adjacent apps. In an API-centric system, different services combine to execute those workflows and functions. 

Focus on the service

These core truths are important, they mean that when designing composable systems the focus is on services rather than in which datacentre, cloud or service-provider region the compute takes place. 

HashiCorp’s Sayar: API-centricity works at scale & also serves productivity.

This has implications for flexibility and scale. 

First, flexibility. 

In the world of the composable business, product teams must be able to deliver custom-built software quickly to respond to new market opportunities that emerge. Applications and infrastructure will invariably evolve in unpredictable ways. This fluidity can only be obtained in a system defined by an API. 

Next, scale. 

Consistent DevOps processes and lifecycle management of infrastructure are relatively simple to achieve with just one or two tiger teams and a handful of services; consistency becomes harder to achieve when you have hundreds of teams and thousands of services and you must navigate a plurality of tools, runtimes, team capabilities and cultures. 

This is where API-centricity comes in. It not only works at scale – it serves productivity: tools favoured by individuals can plug together, helping further the individual’s productivity and thereby meeting the bigger organisational goals of delivery.

If this sounds familiar – it should: many of us already use APIs to deliver not just the infrastructure driving digital but, also, the processes to build and maintain it.

This API-centric model is being driven by two related forces. One is a growing maturity among decision-makers and users of cloud. IT and business teams are increasingly willing to make trusted third parties part of their new and expanded infrastructures – to run their apps atop innovative runtimes and plumb in valuable services through those APIs.

The second is that the market and competition are fierce, providing motivation for traditional enterprises to get into the game. Companies that are great at composability will be the winners. 

Independence vs. chaos

Despite these benefits, composable infrastructure has two major challenges. 

The first is organisational. API cultures can (and should be) independent. But there’s a fine line between independent and chaotic. In large DevOps practices, teams build and run thousands of APIs. The default outcome will be ‘API sprawl’. Technical debt will hinder long-term success.

The other major challenge crops up given the diversity of development frameworks used in an organisation. Java and .NET are stalwarts of big engineering shops, but Node, Python and many others are present as well. The challenge here is to translate composability across all these disparate technologies. 

The remedy for both comes at a platform-level, through common architecture patterns, a service catalogue of add-on capabilities and a series of technology contracts between development and operations teams. 

Swapping anarchy for efficiency

This can translate as agreeing to a core set of shared services and APIs, thereby swapping anarchy for efficiency; it can mean defining patterns and prescribed blueprints that marry the API model to your technology stack for implementation that’s simple and repeatable. In either case, the outcome is the same: a workable and consistent environment from development through to production.

Composable is the future, but with many of us already working at the API level, refining the lifecycle management of APIs, building architectures and much more, the future is already here for many. The branding just hasn’t caught on.