Why APIs are eating the world
Marc Andreessen famously said that software was eating the world. And he's right: as we take advantage of the compute power of the cloud and the distributed sensor network that's the Internet of Things, we're going to see a world that's fundamentally different from the one in which we currently live. It's hard to imagine just what adding a programmable layer to the world will mean, as we make dumb things smart.
But big things have to start small, and we're only beginning to puzzle out how we're going to build this brave new world. Small is a good place to start, as the software world of tomorrow is going to build on the architectural approaches and development methodologies we are using today. One foundational technology is likely to be the microservice approach being pioneered by several influential consultancies.
APIs are best thought of as contracts. They define exactly how two pieces of software are going to interact - just like a well written legal document.
Microservices are, to be honest, just another way of delivering on the old service-oriented architecture (SOA) dream. That's a good thing, as SOA is a technology that promised much - but failed to deliver. But good ideas come around, and the idea of building applications as groups of services with well-defined APIs is one that makes a lot of sense, especially when you're moving to a continuous delivery model.
Small integrated teams are needed to successfully deliver microservices, blending development, test, and operations. It's the same model that drives DevOps (and it's not surprising that agile development process are at the heart of both approaches). You just have to look at Amazon or Facebook, where their microservice approaches have integrated teams delivering tightly focused services that combine to produce their sites. The result is a flexible application that responds to the needs of the user. My Amazon front page won't be the one you see, nor will my Facebook timeline.
Just like any good SOA design, the services that make my pages are being marshalled and connected by a workflow engine that brings in data from one set of services and hands it off to another for display. That's where the service APIs come in, as they're the key to how service data is queried, delivered, processed, and displayed.
If you're going to build your application infrastructure around microservices, you're going to need to ensure that the APIs that each service offers are well defined, well documented, and above all, fixed. That doesn't mean you can't release new versions of an API, or you can't deprecate old services. However, as long as one service uses an API from another, that API can't change. You don't expect Lego to change its bricks, so you'll need to cultivate a similar approach to your APIs.
APIs are best thought of as contracts. They define exactly how two pieces of software are going to interact - just like a well written legal document. Once a contract is in place, it can't be broken except by agreement, or by a court ruling. That's why it's important to have a governance framework in place in advance of any switch to microservices or any other API-driven architecture.
With a governance framework you have the structure that gives you the court and judge (or at least the arbitration meeting room) that can decide the fate of an API. Perhaps the current version of an API uses too much CPU, or an announced retirement date can't be met by an essential piece of code. In a service governance meeting both sides can make their arguments and come to an agreement over the future of an API by working with the other members of the governance group.
In this service-driven world managing your APIs is critical, especially when they can be used by any group within an organisation to deliver their own applications. Once an API has been published it's out there, ready for use. That means you're going to need to consider how it's controlled. Are you going to use an API management layer, like the tools provided by companies like Apigee? Or are you going to have to build the authentication and management tooling you're planning on using in your services by hand?
API management tools and services make a lot more sense than rolling your own. They're designed to connect to corporate directories to simplify authentication, and they offer the ability to control access to APIs; letting you throttle access by dynamically controlling rate limits based on user roles, and even only offering certain API features to certain classes of user. With a good management layer you can develop one API with a full set of features, and then use management tools to tune and control access.
Those APIs don't have to be on servers, or on PCs, or even phones. They can be built into sensors and then exposed to the world at large. There's a Nest smoke alarm on the wall in my home, and it's delivering data to a cloud service that I'm accessing via the If This Then That API marshalling service. Using IFTTT I've written a simple script that records battery level information in a OneNote cloud notebook, taking the Internet of Things and dropping it into a classical desktop productivity suite by linking the APIs of a selection of unrelated microservices.
This is what Andreessen was talking about when he suggested that software was eating the world; the ability to connect anything to anything, via software. So, as it's service oriented architecture that enables that world, let me suggest an alternative formulation: APIs are eating the world. Once we keep that in mind, we can start to construct the tools we're going to need to build the software-powered world.
Now read this: