Many organizations leverage an API gateway to provide edge security and a good developer experience. What these organizations usually create is a layer of experience on top of complexity. The outcome of an API gateway intentionally or not is a layer on top of the complexity without reducing it in most cases.
We’re going to review this practice and how to reduce the complexity. Whether you’ve already implemented your gateway, are in the early stages of implementation, or are just interested in how to complement an existing API gateway, we’ve got you covered.
How we got here
Ever since systems were created there was a need to communicate between them. For example to create a bank account there needed to be communications between multiple systems.
Take the account creation process example below:
In this instance, three different systems on multiple operating systems needed to communicate. This created a lot of code that wasn’t able to be reused in any shape or form. So what happened if they needed to check for accounts that were on the watch lists? Even more code needed to be written. And if a developer left the organization, the code was viewed as brittle and other developers were hesitant to touch it as it was critical infrastructure.
As more of these situations were developed, architects began looking for an answer to this problem.
First things first: the enterprise service bus (ESB)
Architects then came up with the enterprise service bus (ESB), a type of integration that reduces the complexities but adds each system to the bus and decouples the need for individual brittle integrations between the systems.
This worked well, and services were able to be called by external systems using services or a services-oriented architecture (SOA), which provided the best of both worlds: a decoupled experience for systems and/or vendors outside of the organizations and a mechanism that didn’t require tons of redundant code for internal systems.
Let’s take a look at these architectures below:
Adding new systems became a breeze while not having to touch existing code. This made reuse top of mind. Developers were no longer stuck looking at brittle code. The possibilities were endless.
With these systems, APIs could be exposed to external partners using a consistent contract. You knew exactly what you needed to send and what you were going to get back.
The original APIs were SOAP-based which required a contract on both sides. Later on, innovation extended to browsers and mobile devices fueling the digital transformation which required a much more nimble contract. These were done using REST, which didn’t require the servers’ contract on hand for changes to occur. This was a big step in the right direction.
The problem is that these ESB patterns created a monolithic application which when changes were required, the entire service or application needed to be changed. This created a long change cycle, which depending on the organization, could require months or years to change. This became unrealistic in the modern age, so there needed to be another way.
Enter player 2: microservices
Organizations realized that they needed to decouple these monolithic applications into smaller consumable parts, which is where microservices came into play. Each microservice was designed to expose just a bit of the functionality required. This was so that a change to the component wouldn’t affect the rest of the application, minimizing the effort to get an application through the testing requirements and into production in less time.
Now that organizations had the flexibility to make changes as needed, one thing that became clear was additional governance was required to ensure that these services were secured and discoverable. This introduced the need for API gateways.
Third time’s a charm: API gateways
API gateways were an easy solution to allow for security and provide an area to exchange services. Users were now able to easily discover and use services, and developers had an easy-to-use developer experience. But the new problem was backend code to connect these systems were performed using custom code, leaving developers afraid to modify it. What’s more, sometimes they would replace the code, leaving no enterprise coding standard. This meant every developer would have to fend for themselves.
This means that API gateways allowed users to take two steps forward by creating a level of security and discoverability, but five steps backward as the amount of technical debt being created was huge and so much time was spent just keeping the proverbial lights on, as shown in the diagram below:
This then begs the question that many CIOs and enterprise architects ask: “How can I take my existing investments and reduce my technical debt or time-to-market in an efficient and timely manner without starting over?” Here’s where the MuleSoft Anypoint Platform can help.
Orchestration
Now that we know how we got to this point, what can we do to address it? We know that having composable services is key to agility and speed to market, but what if you could quickly compose and change backend services with clicks not code?
MuleSoft’s Anypoint Platform provides the capabilities to have a complete integration platform but allows you to leverage what you have in place already. If you have an API gateway/manager in place, it works with that and can be integrated with your existing API Catalog. If you have microservices that are running outside of Anypoint Platform, you can leverage what you have within it as well.
The Anypoint Platform fits within your environment and extends the value of existing investments. It provides a number of benefits, including:
- Clicks, not code: Anypoint Platform provides an environment that enables developers to quickly consume services without the need for custom code.
- A full suite of connectors: Anypoint Platform provides a full suite of connectors that enable users to connect to nearly any system without having to understand the backend technology. This makes it easier to change underlying technologies without impacting existing services.
- Reuse: Anypoint Platform promotes reusability by providing a repository that creates reusable assets. This includes APIs that are imported from the API catalog, and other integration templates, examples, and accelerators. This includes assets from your organization and those provided by MuleSoft to make your life easier.
See how Anypoint Platform can extend the value of an existing API manager:
Let’s look deeper into this:
- Existing services can be exposed in the existing API catalog and imported into Anypoint Platform. As new services are added this can be done using the CI/CD pipeline of choice.
- Services can be orchestrated via Anypoint Platform by using clicks, not code.
- Existing services can be called from the existing API manager, but the orchestration process is handled by Anypoint Platform.
- New services can follow one of the two following paths:
- New services can be exposed using the Anypoint Platform which enables all the platform benefits mentioned above. These services can still be exposed in the existing API manager.
- New services can be exposed using the existing API manager and coded using the methodology of choice. This path will expose some but not all the platform benefits mentioned above.
- Once an orchestration has been created using the new services, it can be exported from Anypoint Platform into the existing API catalog using the CI/CD pipeline of choice.
Conclusion
We’ve covered lots of ground very quickly here. Let’s summarize what we talked about:
- Early Integrations required lots of custom code and accrued too much technical debt.
- ESB and SOA reduced this technical debt, but the result was monolithic applications that took too long to change.
- Microservices allowed quick change but added too much technical debt which basically brought us back to step one.
- API managers added a layer of developer experience and security but little to nothing of reducing the accrued technical debt.
- Anypoint Platform can provide the best of both worlds. It can be a full Integration/API platform, but is composable enough to work with your existing API managers.
