This chapter discusses an aspect of modern application development not covered by the original 12 factors. Regardless of the type of application you’re developing, chances are if you’re developing it for the cloud, then your ultimate goal is to have that application be a participant in an ecosystem of services.
Assume for a moment that you have fully embraced all of the other factors discussed in this book. You are building cloud-native applications, and after code gets checked in to your repository, tests are automatically run, and you have release candidates running in a lab environment within minutes. The world is a beautiful place, and your test environment is populated by rainbows and unicorns.
Now another team in your organization starts building services with which your code interacts. Then, another team sees how much fun you’re all having, and they get on board and bring their services. Soon you have multiple teams all building services with horizontal dependencies1 that are all on a different release cadence.
What can happen if no discipline is applied to this is a nightmare of integration failures. To avoid these integration failures, and to formally recognize your API as a first-class artifact of the development process, API first gives teams the ability to work against each other’s public contracts without interfering with internal development processes.
Even if you’re not planning on building a service as part of a larger ecosystem, ...