API deployment is the OG stop along the API lifecycle, but is still the most underserved when it comes to API service providers providing solutions, and as part of the full lifecycle API management conversation. I remember back in 2011 folks asking me which of the API management providers would help them deploy their APIs, which at the time none of them would, being a pretty regular concern when it came to doing APIs at all, let alone doing them well. I have seen many “API deployment” solutions come and go, and after a decade I see some movements forward, but overall API deployment is still really difficult in ways that just doesn't make sense.
Data APIs
Making data available via simple APIs is the most common type of APIs you will come across out there, and the most common reason for providing as well as consuming APIs. Deploying data APIs are pretty straightforward to do, and there have been a wide variety of services and tooling made available to help developers deliver these types of APIs. Even with the simplicity of this type of APIs, I haven’t seen too many platform successfully monetize a data API deployment solution, or deliver a dead simple, widely adopted, single push of a button solution to delivering data APIs. It really is one of those areas that should have been 100% solved by now, and would be if it was for the incentive models that exists behind most platforms, but also due to some pretty widespread unhealthy practices when it comes to managing and publishing data, making a lot of data pretty messy to work with when it comes to making available data APIs.
Content APIs
These types of APIs often overlap with the world of data APIs, but I want to highlight them separately because of content delivery network (CDN) considerations, as well as movements in the headless CMS world when it comes to enabling dead simple API deployment. I would say that the headless CMS movement is one of the more significant movement forward in this area, and I am looking hard at solutions like Flotiq and Strapi to help me take the next big steps when it comes to deploying APIs from within Postman. Another significant difference between data and content APIs is who these words are meaningful to, and the business prioritization these individuals possess. Meaning data is going to mean more to developers and data folks, where content is going to be more meaningful to marketing and business folks. These things matter when it comes to having the budget to pay for a solution, which is something that ultimately drives what I am talking about when it comes to the overall state of API deployment.
Algorithms and Business Logic
The third main bucket of APIs that usually throws a monkey wrench into the overall API deployment conversation is when there is actual code, business logic, and algorithms being deployed as part of an API. Meaning it isn’t just about pulling data from a database or content from a storage location, and you actually need to have code working some magic behind the scenes, doing calculations, and bringing that secret sauce to what our APIs are doing under the hood. Once you have business logic and algorithms in play, the complexity of an API goes up significantly. Source control becomes much more of a reality, and automation of the API deployment process can become much less streamlined, requiring more resources to make happen. This type of business logic and algorithm crunching often operates along side pulling data from a database and pulling content from a CDN or other system, further adding the complexity, and often times leading to API providers just sticking with hand-crafted APIs done by competent programmers.
Programming Languages
It is the programming language where the API deployment universe widens in ways that create a significant amount of friction. I can’t remember who said the quote, but it is something about there not being too much difference between each programming language, but there are massive differences between each of the programming language communities. This is where 60% of tech dogma exists. The auto-generation of server and client side code has eroded about 10% of the friction that exists here, but since most of them do not actually get you to a deployed API and you still have to wire things up, there is still so much work to be done by developers. Honestly, the programming language layer of the API deployment needs to be abstracted away and removed from the conversation. It has caused more problems than it has solutions over the last decade. As an API consumer I do not give a shit about what language your API is written in, but as an API provider this is often the number one challenge when it comes to streamlining and automating how APIs are deployed. Something that I am hopeful for the API gateway and serverless layers of all of this to help dispose of much of the legacy baggage that exists, which is mostly because of programming languages.
API Frameworks
One layer up from the programming language portion of this is the framework discussion. There are a wealth of frameworks in almost every programming language that will help you quickly bootstrap the deployment of your APIs. Some are simple, while others are complicated. Some are simple, while others are robust. This is an area where your programming language beliefs will drive your decision making process. Whether a frameworks speaks to your API deployment needs will depend on how you view the world through your programming language lens. API frameworks have been around for a long time and aren’t going anywhere soon. They are the favorite way for developers to deploy their APIs, but is something that keeps the API deployment conversation in the hands of the wizards, and not something that is accessible by muggles. Which is one of the reasons why the overall API deployment conversation hasn’t moved much over the years, because the wizards like to keep things within their control and will keep fighting to keep this knowledge and capability out of the hands of normal business folks, and keeping things complicated and abstract is one way we do this.
Compute
Once you have your API defined, next you need to be able to power it, something that was historically done just like web applications using physical servers in racks, but then it migrated to scalable compute instance in the cloud, and then further being evolved upon using API gateways, containers, and serverless. The compute layer underneath APIs will speak to how performant it is, and ultimately what type of load it can handle. It is something that is becoming much more easy to define, scale, and orchestrate with containers and Kubernetes, but we have just begun to see the scalable automation we need to streamline how we deliver APIs, and while Kubernetes is powerful at scale, it still isn’t something that the majority of wizards can put to use when it comes to API deployment. We have all the parts and pieces to solve this aspect of API deployment, we just have to bring it all down to a level that works for everyone across the spectrum.
Serverless
I’d say that serverless makes my top list of positive movements forward in the API deployment conversation. It is abstracting away some of the friction that exists across programming languages, frameworks, as well as the compute layer of deploying APIs. I think we will keep seeing significant advances in the area of API deployment due to more investment in the serverless layer of the cloud, and serverless will move beyond just being a trend and become a core part of how we deploy our APIs. Serverless APIs isaresomething that all API providers should be exploring, and something that they should begin with learning about via the cloud platform of their choice, but then quickly begin looking at how cloud vendor lock-in can be quickly addressed by going multi-cloud and looking to open source serverrless solutions. It will continue being one of the bright spots in this conversation, and helping us make API much more push button and scalable without much additional effort.
Database
The database is a cornerstone of the API deployment conversation, and create, read, update, and delete (CRUD) APIs are ubiquitous. I have seen more database API deployment solutions come and go in the last ten years without much forward motion at all. The deployment of an API from a database should have been completely solved by now and just be part of the fabric of the cloud. Overlapping with the serverless conversation we are seeing the serverless model being applied to the database layer, but even with this evolution we haven’t seen the fruits of all of this emerge when it comes to API deployment. The database layer of API deployment shouldn’t still be of concern after all this time and is something I’ll hopefully do a deeper dive into to better understand, because I know these challenges aren’t technical, and they are likely due to business or political friction.
Storage
Right after the database, having a heavy object storage strategy, as well as a foundation for the content delivery strategy, continues to define the API deployment conversation. Having a coherent, shared, scalable strategy for handling images, videos, files, and other objects as part of API operations continues to slow the advancement of API deployment automation and orchestration. APIs should just deploy and have database and storage built in by default—this is something that developers shouldn’t have to worry about. Like serverless, the storage needs that goes along with API deployment should be abstracted away and made something that is part of the fabric of the cloud. Storage shouldn’t be an afterthought, and always be a well planned portion of how APIs are delivered across an organization.
Gateway
API gateways have been a fixture of the API space for the last couple of years, but in recent years they have gotten smaller and become more baked into the fabric of the cloud with the consolidation of API management space by 2015. Their continued adoption of OpenAPI as a standard has further evolved the API deployment conversation using a gateway. While you often times still have to wire up backend systems and databases, with most modern gateways you can deploy all the scaffolding for an API with a single OpenAPI. However, like other areas, even with all of these advancements, push button API deployment via gateways is still elusive. I’ve done it with AWS API Gateway and Lambda, RDS, or DynamoDB using a Postman collection, but frictionless API deployment using gateways isn't the silver bullet many of us figured it would be out of the gate. With a little more work though I predict in the next couple of years we will see most of the rough edges with API deployment shaved off and the it become much easier to deploy and scale APIs as needed across any cloud platforms.
Protocols
Another area of fragmentation and expansion that continues to impact the API deployment conversation is at the protocol layer. While HTTP 1.1 APIs are the dominant approach to deploying APIs, HTTP/2 and now HTTP/3 are gaining speed, as well as continued expansion into the TCP, MQTT, and AMQP realms. Like other stops along the API lifecycle this expanding API toolbox is putting pressure on the services and tooling space, expanding their road map, but also making it more complex for their customers to put to work. All of these challenges aren’t going anywhere soon, and the need to deploy multi-speed and multi-protocol API experiences is only going to grow. It is just another reality we have to content with when it comes to realizing our dreams of push button API deployment.
Specifications
The great API specification wars of 2011 to 2016 took its toll on the API conversation. While everything has settled on OpenAPI being the API specification you should be using across the API lifecycle, the growth of AsyncAPI represents the protocol challenges I spoke of a little bit ago, and JSON Schema and Postman collections reflect other API lifecycle challenges and opportunities when it comes to making all this work consistently at scale. You can deploy a new data or content API 100% from an OpenAPI definition today. I would argue you can also do this with more algorithmic and business logic APIs with a handful of OpenAPI extensions, but we still lack a viable, widespread, commercial solution to realize our API deployment dreams. Like some of the other areas discussed, we are real close to some complete API deployment solutions driven by API specifications, but there are still a lot of rough edges to smooth off before we are where we need to be.
Source Control
Depending on the combination of building blocks in play to deploy an API, source control may be needed. While some API gateway solutions made be “codeless”, it is likely, even if it is serverless that you will need to have a source control strategy. GitHub, GitLab, and Bitbucket have define this layer of the software development lifecycle, and they’ll continue to define the API deployment lifecycle, but we will need to establish more streamlined approaches that speak to API deployment specifically, catering to the evolution of how APIs are being deployed, scaled, and made available across an organization. Without source control, API deployment will become just as unwieldy as other aspects of our legacy operations that existed before we developed modern source control approaches.
Versioning
Overlapping with source control, managing the deployment of multiple versions of an API, as well as the specifications and code that powers them continues to clog the API deployment pipes. While there are many proven approaches to versioning an API, many teams still struggle with doing consistently and effectively across their fast changing API infrastructure. It will continue to be something that slows push button API deployment, but when service and tooling providers are able to abstract away the challenges with versioning we will see API deployment rise to new levels across all business sectors, taking away the uncertainty that exists around change today.
Pipelines
CI/CD is default when it comes to delivering software in 2020, and that includes API infrastructure. While there are many enterprise organizations who are still playing catch up in this area when it comes to their legacy processes, it has also has captured such a significant mindshare when it comes to API deployment, that I find people have difficulty thinking beyond it. CI/CD is essential for delivering repeatable API deployments that providers and consumer can depend upon, but when it comes to API gateway driven deployments and Kubernetes orchestrated implementations, we are going to have to make sure our definitions of what CI/CD is is elastic. There are other ways to ensure that deployments are repeatable, and like other legacy practices we have to make sure existing definitions of CI/CD do not define the future of API deployment. As of 2020 they are the default mode of deploying reliable APIs, but their use as part of serverless deployments is already seeing shifting views, but this is something that will continue to be blown out of the water when it comes API deployment at scale using API gateways.
Testing
Testing any APIs that are deployed should always be the default. You should never deploy something you don’t have tests written for, and any API deployed into production should always have those test run natively as part of the deployment process. These tests should also be available to developers to execute whenever they need, while also being able to run on a schedule in the cloud from any region around the world. The maturation of the API testing landscape will contribute to us providing push button API deployment solutions in coming years, making all the investment we have been doing over the last five years well worth it. Testing is a critical stop along the API lifecycle, but is also a fundamental ingredient in deploying APIs in a consistent, repeatable, and reliable way.
Integrated Development Environment (IDE)
One important doorway in this discussion involves where the API deployment process is initiated, and for many developers this means being able to make happen from within our IDEs. This is where we live. This is where we spend our days defining each stop along the API lifecycle, so it makes sense that each of the areas of this API deployment should be accessible from within the most common integrated development environments (IDE) out there. While API deployment will increasingly be set into motion via other interfaces by developers and non-developers, APIs will continue to be born from within the IDEs of development teams across many different industries for years to come.s
Command Line Interface (CLI)
All aspects of API deployment should be available via the CLI. Like the IDE, this is where many developers live, but it is also how much of the automation and orchestration of API deployment will be done. CI/CD depends on the CLI, and to reliably automate all the moving parts we’ve discussed, the API deployment process will have to be exposed via the command line, putting each action required right at the fingertips of developers with a single command. Any tools or service that are being employed as part of the API deployment process which does not have a CLI dimension won’t be around for very long, as our need to scale the number of APIs we deploy increases exponentially.
Application Programming Interface (APIs)
Welcome to the inception portion of the API deployment conversation, and recognizing that APIs should be deployable using APIs. Like the CLI, every facet of the API deployment process should be accessible via an API. I can deploy an API from within Postman using the AWS API Gateway, Lambda, RDS, and DynamoDB APIs today. While it would take me a significant amount of work to make this execute reliably with a push of a button using a Postman runner, it is possible. API deployment using APIs exists today, API providers just don’t always see their APIs as just another API resource and treat the same as they do the rest of the software development lifecycle. APIs are essential to us automating and orchestrating the future of APIs—helping us effortlessly deliver the thousands of APIs we are going to need to conduct business in coming years.
API Deployment is Complicated
Not all of these dimensions of API deployment apply in all API deployment scenarios. However, they do reflect the overall complexity involved in moving forward API deployment across many different business sectors which are being impacted by the overall API industry. I can develop entirely new solutions for moving this conversation forward and they won’t mean anything on the ground across enterprise organizations because they aren’t even seen or fathomable in the current state on the ground. Ultimately you have to find the right blend of these building blocks above which makes sense to large enterprise organizations and make incremental adjustments to how they are already doing things. There will be a handful of organizations you will have green field opportunities to move the API deployment conversations, but mostly it will be about understand the existing software development lifecycle and map to hat, slowly evolving and shifting the conversation while investing in the education of developers and architects along the way. It takes time, and understanding the realities on the ground in the moment to actually make change.
I see this list as a sort of bingo card for bringing a new API deployment solution to market. I am finally in a place after a decade of work where I have the opportunity to make a meaningful impact on the API deployment conversation. I don’t think I will have to develop anything. I just have to understand state of things at enterprise organizations, and then find the right mix of API deployment solutions already being developed and delivered to invest in and support. I don’t think Postman needs to build the next great solution. I think Postman has to just stitch together the most meaningful offerings from across our partners and then bake it into the Postman platform in just the right way. Ideally, it is a suite of solutions that cover all of the cloud platforms, the top programming languages, and the leading gateways, helping orchestrate using the most logical mix of services and tooling that is as closely aligned with how organizations are already delivering infrastructure, but then move forward in the most tactical way. It is a pretty exciting time to be in the business, cause I feel like we are experiencing a sort of second or third wind when it comes to not just API management, but the entire API lifecycle, but and more importantly the single most stop along the way—API deployment.
