Where Middleware Fits Into the API Lifecycle
Where Middleware Fits Into the API Lifecycle
You can't say that you fully understand the API landscape unless you have at least a little bit of knowledge about the middleware space.
Join the DZone community and get the full member experience.Join For Free
Continue to drive demand for API management solutions that address the entire API life cycle and bridge the gap to microservices adoption.
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 APIs like I am.
This particular group is coming at it from a middleware perspective and is trying to understand what APIs have done to the middleware market and what opportunities exist (if any). This starting point for an API conversation got me thinking about the concept of middleware in contrast (or relation) 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. I found this:
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, for proxying, and for providing a gateway for APIs, making middleware as a term pretty irrelevant. I think that 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? It's all along the API lifecycle. Middleware (AKA services and tooling) is popping up through the lifecycle to help design, deploy, manage, test, monitor, integrate, and more throughout the API life cycle. All of the features of our grandfather's 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, and 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 fit pretty nicely with some earlier concepts of what middleware does or can do (i.e., database, deployment, virtualization, management, documentation, change log, testing, performance, authentication, encryption, security, CLI, logging, analysis, and aggregation). 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 Kits (SDKs), embeddables, visualization, webhooks, iPaaS, orchestration, real-time, voice, spreadsheets, communication, support, containers, serverless, and bots.
This is where things really began 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 able to be plugged in anywhere along the lifecycle — 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 with 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 back-end to front-end to anywhere 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.
Published at DZone with permission of Kin Lane , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.