How a single mandate changed software development forever
There's conjecture about exactly when it was issued and by whom, but a mandate made twenty years ago is continuing to shape the software development process today.
Dubbed the 'API Mandate', it was issued by someone within Amazon as guidance for the company's large team of developers. It stated that, effective immediately, all development teams must expose their data and functionality to others through service interfaces, now known as APIs.
The mandate went further. It stated that development teams must only communicate with each other through these interfaces and that there should be no direct linking, no direct reads of other data stores, and definitely no back doors.
A shift from monolith to microservices
The reason for the issue of the mandate was an increasing challenging being faced at the very heart of Amazon. As the company had grown, so too had the complexity of the software supporting its operations.
Amazon's IT team realised it needed to shift away from a strategy of monolithic software building. They needed to break things down into smaller components which could then communicate with each other as required.
The team turned to service oriented architecture (SOA) design, and then went even further by empowering small, agile teams to build microservices. By following this strategy, individual components of an application could be built and their common functionality shared with other microservices. In this way, building blocks were linked together to meet the computing demands of any particular business use cases.
APIs were a key part of this shift as they provided an efficient means for services to interact with each other. Each API was also fully documented so it could be found and used by other teams across the company. This was designed to eliminate redundancies and duplication of work.
A new business opportunity
Amazon's embracement of APIs not only changed the way software was developed internally, it also created an opportunity to create an entirely new business venture: Amazon S3.
S3, or Simple Storage Service, became an offering that allows any customer in any industry to store and protect any amount of data. As its popularity grew, it became a significant new source of revenue for Amazon.
As well as making S3 possible, the microservices and API strategy followed by Amazon also enabled the company to establish its Elastic Compute Cloud (EC2) service. It was effectively the dawn of the on-demand, cloud-based computing era.
APIs may have actually been in existence since the 1960s, but what Amazon did was reveal their potential to revolutionise data centers and software development. By building arguably the largest distributed cloud on earth, Amazon has led the way and offers an example of just what can be achieved with APIs.
Follow the rules
Other organisations keen to harness the power of APIs and put them at the heart of their IT infrastructures need to follow a set of rules.
Two of the most important are that APIs are forever, and their backward compatibility should never be broken. Developers should also work backwards from customer use cases and create APIs that are self-describing and have a clear and specific purpose. APIs should also be created with explicit and well-documented failure modes.
Despite the fact they are already in widespread use, the future potential of APIs remains huge. According to Kong's 2022 API - Microservices Connectivity Report, almost 70% of tech leaders say budgets for APIs will continue to increase in 2022.
An era of 'API first'
It's clear that adopting a strategy of API-first development can deliver significant benefits. It can support innovation, make businesses more responsive, and allow new opportunities to be tackled as they appear.
Rather than having to work with bloated, unwieldy applications, development teams can be agile and much better positioned to deliver what is required by a growing organisation. The mandate might be 20 years old, but it makes just as much sense today.
