The Importance of APIs in the Container Age
The upcoming API Strategy and Practice (often called API Strat) conference on November 18-20 in Austin will share stories and push current challenges forward for the maturing API economy.
This year has seen several major shifts in how APIs are being deployed by both enterprises and startups alike. Whereas just a few years ago, the bulk of API discussions occurred amongst startups and willing disruptors keen to bring the competition to traditional markets, 2015 has seen a move towards more enterprise adoption with even the slowest moving sectors like banking starting to participate.
Application programming interfaces — APIs — are a code format that enables businesses to provide a simple representation of components of their IT infrastructure — like datasets or service functionalities — in a way that can be integrated into other internal or external IT system architectures.
For disruptive startups, this meant they could build new user-friendly interfaces and mobile applications quickly by exposing data and capabilities via an API. For more slow-moving, larger businesses and enterprise, APIs enabled different IT infrastructure to share data, create new proof of concept product models, or connect to external services without having to share the complexity of their own legacy code base.
As a result, the uptake of APIs amongst the enterprise has been a key maturation signal this year. But it has come amid the need for a new metaphor to describe the benefits of APIs (a task that hasn’t quite been nailed yet), post- “composable enterprise” framing.
APIs Are/Are Not Microservices
In part, this year has seen some commentators describe APIs as part of a microservices architecture. Updating the “composable enterprise” lingo, APIs are being described as microservices in the same way as they were once described as “composable units” — or even as LEGO bricks — that could be refactored into new value chains to generate workflow efficiencies, speed up product development, or create new channels for connecting with target markets.
But the microservices bandwagon isn’t quite the right fit.
Just a few years ago, APIs were being built by startups who wanted to enter markets quickly and usurp the status quo. Now those startups have been on a growth phase where in their speed to create, they have ended up replicating legacy systems with a complex code base where the source code couples functionalities with an often poorly constructed data model underneath. These startups iterated quickly and built new features in response to paying customer needs, but now they are established businesses and are realizing they need to step back and have a long-term view of their API, which often means adopting a more microservices approach themselves.
Up to last year, API design discussions within startups and the enterprise often started with individual use cases and creation of endpoint contracts. As the advantages of APIs were recognized and taken up more globally across a business, complexity was re-introduced with multiples APIs at times referring to the same datasets or functionalities.
This led Teresa Tung, a senior manager at Accenture Technology Labs, to work on the Industrial API Maturity Model, which shows a more lifecycle-oriented approach to developing APIs where individual use cases are leapfrogged by a more systems-based thinking about how an API should be a bundle of related functionalities.
While Accenture’s model was published in 2014, James Higginbotham from LaunchAny, an API design shop based in Austin (where API Strategy and Practice will be held next week), says thinking beyond endpoints is only just starting to emerge in business conversations:
This has been an exciting year for APIs. Businesses are starting to move from thinking in endpoints to API products and solutions, no matter if the API is private, partner, or public facing. As businesses shift to product-based thinking, they seek out techniques for designing reusable APIs that can handle a variety of use cases, many of them unknown at design time.
“As a result,” Higginbotham continues, “I have been working with teams to view their APIs beyond a collection of HTTP-based endpoints. Teams need to understand that APIs are an architectural concern that expose an interface to the underlying systems. Applying systems design and domain-driven design help create clear interface boundaries that can be combined to solve a myriad of use cases.”
What Higginbotham is pointing to is the shortcomings of the microservices metaphor for APIs. In truth, APIs act more as a collection of microservices that are bundled together. In this analogy, individual endpoints may be a better comparison point for microservices.
Higginbotham, who — like Teresa Tung — will also be speaking at API Strategy and Practice, says that this year, he has seen a larger interest in a return to domain driven design (DDD), much as has been seen for distributed architecture systems based on containers.
“For product managers, the lightbulb moment is when they start to see product boundaries,” says Higginbotham. “As the product architecture begins to emerge and DDD is applied, new products and product opportunities can be discovered that weren’t previously identified. It also prevents products from being released that are incomplete and need to be fleshed out to ensure that they deliver value for the target markets.
The biggest pain point that teams face is identifying and designing the API resources. DDD solves this by helping teams find API resources and the collaboration of these resources to realize target use cases. It also identifies opportunities for outbound events using webhooks, which can open up an API to a whole new realm of possibilities that may be missed without a similar design approach.”
APIs As Enterprise Efficiency Engines
Some two years ago, when the term “composable enterprise” had more currency, Laura Merling from AT&T presented at API Strategy and Practice in San Francisco to share her team’s successes in reorienting the monolithic telco towards an API-enabled company. One of her team’s tactics at the time was to meet with each individual business unit, identify subject matter experts, and help them to define the datasets and functionalities that could be packaged up into discrete APIs.
This year, API Strat will hear from Loren Paulsen at Maps Credit Union who has taken a similar approach to building internal support by meeting with various departments and discussing the power of APIs. To demonstrate the value of APIs, his team has mapped out business workflows — such as one that informs customers when a debit card is ready to be collected — and identified opportunities to use APIs to automate stages in the processes. Paulsen has been able to introduce the organization to the use of third party APIs like SendGrid’s email API to speed up production and reduce the costs of current processes. (Now, Maps CU uses the SendGrid API to first try and alert customers to the availability of their debit card, reducing monthly postal costs).
While this can be done by a simple spreadsheet or whiteboard, a new suite of process automation tools — like Built.io Flow — are being released to enable businesses to daisy-chain APIs together and generate the efficiencies that come from removing the human error of data handling from cutting, pasting and re-inputting data. (Neha Sampat, CEO of Built.io, is also an API Strat keynote.)
APIs As the Platform Unit of Value
Another tactic Paulsen has used with some success when building support for internal APIs has been to use an API description format to encourage business product owners and technical leads to be on the same page when designing an API.
API definition formats are probably the single greatest proof of API maturity this year and has allowed the API sector to replicate a similar storytelling power to container technologies.
Codenvy’s container tech infographic published on The New Stack describes how containers are the core unit of value for a platform ecosystem. Platform business model thinkers like Sangeet Choudary have long been beating the drum that for a tech business to morph to a platform play, they must first identify the single unit of value that brings both the producers and consumers to the platform. For the Docker and Kubernetes ecosystems, for example, the container is that unit of value, and it has allowed a whole ecosystem to blossom for tooling components from orchestration, logging, and discoverability, to monitoring, testing and more.
In API circles, this year we have seen the API definition format becoming that single unit of value for API platforms. API Strat co-organizer (along with 3scale) and API Evangelist, Kin Lane, describes a lifecycle with some 17 stages. This year, API tooling — predominantly in the testing space but also at other lifecycle stages — has matured and is increasingly drawing on API definition formats to automate when the tool gets brought into use, much as continuous integration helps container technology push applications along a development-to-production pipeline.
Bruno Pedro, founder of API tooling startup API Changelog — which helps API providers connect with their most engaged users by automating notification and quantifying the size of changes to API documentation and terms of use policies — says the API description format as the core unit of value is an “interesting parallel.”
“It fits well with the current context as to where the API game is right now,” says Pedro. “Going back a few years, we have been through something similar with SOAP, where we had machine readable systems and automated systems that followed the right standards. But it didn’t take off because it was too enterprisey and didn’t have adoption from a global audience. In the last few days especially, with the evolution of Swagger into the Open API Initiative, with IBM and other big players coming on board.”
He adds: “With the maturing of the API tooling ecosystem, and the increased use of API description formats, the better and more easier it will be for people to build more automated solutions.”
As we progress into the final quarter of 2015, this lifecycle tooling has evolved into a new series of API ecosystem tools that are seeking to emulate the Docker platform. It started earlier this year with Apiary’s Apiary for Enterprise, built on the API Blueprint description format. Now SwaggerHub has been released by SmartBear, MuleSoft released API Workbench, Postman released Postman Client, and eager newcomers API Garage, RepreZen and RESTLET Studio are offering alternatives.
Each uses the API definition format to push an API along something akin to Lane’s 17-stage API lifecycle model or Tung’s Industrial API Maturity model.
APIs As the Invisible Hand
So while APIs are maturing and enterprise uptake continues, there seems almost less clarity around a common metaphor or storytelling device to describe APIs in the way that Docker and others have been so successfully able to use with containers and, more recently, the ‘microservices architecture’ terminology.
Perhaps this isn’t a problem at all. Certainly, Paulsen has been able to foster enterprise traction from demonstrating efficiency gains head on rather than framing APIs with a microservices, composable enterprise, or other type of explanation.
Pedro thinks one reason for this might be that APIs are destined to become almost invisible: “My view is that it might take months, or even one or two years, but eventually we will see that all integration between various APIs will be done fully automatically. You will not have to write a single line of code. You will just put what your app needs in terms of integration with other systems and it will integrate for you.”
There are already signs that perhaps Pedro is right. The rise of what Dion Hinchcliffe (another API Strat keynote speaker) describes as the ‘citizen developer’ portends that end users may not even need to know that APIs are what are driving their work forward. Services like Blockspring — that enables anyone to make use of an API via a Google spreadsheet — and the rise of Slackbot integrations point to APIs becoming both more accessible and yet more invisible at the same time.
The API space has seen some major shifts this year. How these are being described will impact on uptake amongst enterprise, government and society in 2016. Conferences like API Strategy and Practice enable leaders to share storytelling and to test out metaphors that effectively describe the benefits and challenges APIs are bringing to business and society.
API leaders including Teresa Tung (Accenture), Neha Sampat (Built.io), Rion Dooley (Texas Advanced Computing Center), Lori MacVittie (F5 Networks), and Dion Hinchcliffe (enterprise thought leader) will share keynotes in a diverse program that includes workshops, session tracks on key API themes, fireside chats and mainstage panels, all together aiming to push the API agenda further.
The New Stack readers are invited to attend at a 20 percent discounted rate, by registering online using the code APISTRATTHENEWSTACK.
Docker and IBM are sponsors of The New Stack.
