I have had a series of calls with an analyst group lately, discussing the overall API landscape in 2017. They have a lot of interesting questions about the space, and I enjoyed their level of curiosity and awareness around what is going on--it helps me think through this stuff, and (hopefully) better explain it to folks who aren't immersed in API like I am.
This particular group is coming at it from a middleware perspective and trying to understand what APIs have done to the middleware market, and what opportunities exist (if at all). This starting point for an API conversation got me thinking about the concept of middleware in contrast to, or in relationship to what I'm seeing emerge as the services and tooling for the API life cycle.
Honestly, when I jumped on this call I Googled the term middleware to provide me with a fresh definition. Middleware: software that acts as a bridge between an operating system or database and applications, especially on a network. What does that mean in the age of API? Did API replace this? There is middleware for deploying APIs from backend systems. There is middleware for brokering, proxying and providing a gateway for APIs. Making middleware as a term pretty irrelevant. I think middle traditionally meant a bridge between backend and the frontend, where web APIs make things omnidirectional--in the middle of many different directions and outcomes.
The answer to the question of what has API done to middleware is just "added dimensions to its surface area". Where is the opportunity? "All along the API lifecycle". Middleware (aka services & tooling) is popping up through the life cycle to help design, deploy, manage, test, monitor, integrate, and numerous other stops along the API life cycle. All the features of our grandfathers API gateway are now available as a microservices buffet, allowing us to weave middleware nuggets into any system to system integrations as well as other web, mobile, and device applications.
Middleware as a concept has been distilled down into its smallest possible unit of value, made available via an API, deployed in a virtualized environment of your choosing, on the web, on-premise, or on-device. This new approach to delivering services, and tooling is often still in the middle, but the word really doesn't do it justice anymore. I wanted to go through all the areas of my research and look for any signs of middleware or its ghost.
Some of the common areas of my research that I think fits pretty nicely with some earlier concepts of what middleware does or can do. I would say that Database, Deployment, Virtualization, Management, Documentation, Change Log, Testing, Performance, Authentication, Encryption, Security, Command Line Interface (CLI), Logging, Analysis, and Aggregation are some pretty clear targets. Of course, this is just my view of what middleware was to me, from say 1995 through 2007--after that, everything began to shift because of APIs.
As web APIs evolve the reason you'd buy or sell a tool or service to be in the middle of some meaningful action when APIs started being about Software Development Kit (SDK), Embeddable, Visualization, Webhooks, iPaaS, Orchestration, Real Time, Voice, Spreadsheets, Communication, Support, Containers, Serverless, and Bots. This is where things really begain working in many different directions, making the term middle seem antiquated to me. You are now having to think beyond just any single application, and all your middleware is now very modular, API-driven, and can be plugged in anywhere along the life cycle not just any application, but also any API -- mind blown.
The schism in middleware for me began when companies started cracking open the SDK and were using HTTP to give access to important resources like compute with storage with AWS, and SMS with Twilio, offering a peek behind the curtain for developers. Then further expanding to regular humans with embeddable tooling, iPaaS with services like Zapier, and other services and tools that anyone can implement, no coding necessary. All of this was fueled by mobile, and the need to break down the data, content, and algorithms for use in these mobile applications. Things have quickly gone from backend to frontend, to everywhere to everywhere. How do you get in the middle of that?
Anyways. I'm guessing this story might be a little incoherent. I'm just trying to find my words for future conversations on this topic. As the regular world is confronted with this API thing, they have a lot of questions, and they need help understanding how we got here. Honestly, I feel like I don't fully have a grasp on how we got here. So writing about it helps me to think through this stuff, and polish it a little bit for the next round of conversations.
