We enable business and digital transformation decisions through the delivery of cutting-edge ICT solutions and products...
Chances are, you have multiple API gateways in your organization. Enterprises adopt multiple API gateways for several very good reasons, from meeting different security needs to move to the cloud, to making their infrastructures – and their businesses – more resilient and agile.
But it also complicates things. When you have multiple API gateways, it’s harder to see all the APIs you actually have and to understand who’s consuming them. It’s more expensive to run multiple API gateways that don’t talk to each other, especially in hybrid on-premises and cloud deployments. And as you move to the cloud, increase API traffic through the adoption of microservices, or just add more APIs to meet business demands, the challenges grow.
Many companies have adopted a two-gateway architecture: an external gateway that controls the traffic between the enterprise and the outside world, and an internal gateway for various applications and systems flows inside the company. Why?
Different security requirements
The key rationale behind a two-gateway architecture is the different security requirements between the internal and external worlds:
An additional benefit of a two-gateway architecture is in the case of a breach or cyberattack on one, the other can
keep running so all applications don’t come to a complete halt.
Cost optimization
To save money, a business can make use of external gateway such as AWS gateways running in the company’s private cloud. Using the internal gateways for internal calls optimizes costs.
Legacy infrastructure
As one of our customers explained, “We wanted to have more functionality externally. We have a lot of complex legacy systems internally, and you need to have knowledge of how those systems work. Our partners and customers will never understand them, so we are trying to translate that for them. We are API-first externally, but not at all internally.”
2. On-premises vs. cloud vs. hybrid deployment
Most companies transitioning from an on-premises infrastructure to the cloud choose new API gateways for a couple of reasons:
1) because an API gateway that served them well on-premises doesn’t meet emerging cloud needs, or
2) because certain API management capabilities come packaged with new cloud-based applications or systems.
Companies that are fully committed to the cloud typically use two gateways for two or three years while they transition
APIs and functionalities from the old on-premises API gateway to the new cloud API gateway.
For most companies, however, having multiple API gateways is a permanent situation as they opt for a hybrid architecture that keeps some applications on-premises while moving others to the cloud.
3. Central vs. local governance
Conway’s Law states that the way an organization is structured will reflect the way software can be built. Enterprises,
especially large multinationals, often have multiple gateways because different business units or geographies have
different needs and requirements.
Culture
In our survey, one customer said their IT landscape “is so huge, you will probably find everything there.” This client made attempts to centralize certain API management functions but faced resistance from business units that preferred to do things their own way. Today, IT has no visibility into all the different digital capabilities or assets that are deployed across the company.
Mergers and acquisitions
In some companies, multiple API gateways (either temporary or permanent) are a result of entities with entirely different IT systems coming together.
4. Closing a functionality gap
The role of an API gateway is broad, from security, such as authentication and authorization, to traffic management, including routing and load balancing, to monitoring and visibility. When an enterprise, or even a single business unit, outgrows the capabilities of an existing gateway, they often add another to close the functionality gap.
5. Development vs. testing vs. staging vs. production
Most businesses have multiple API gateways for different stages of the API lifecycle to avoid confusion about which endpoint to use at which time in which environment. As new projects are launched, API management is a part of a larger ecosystem of components.
6. Microservices vs. monoliths
Traditionally, applications were built as monoliths — a bundle of code deployed as a single, self-contained unit. With a microservice architecture, software developers get to deliver an application as a suite of modular services that are independently deployable and scalable. This typically results in API traffic running in multiple service meshes and Kubernetes-based clouds (from on-premises to AWS, Google, and Azure).
Contact Musato Technologies to learn more about our innovative ICT solutions and services that are empowering businesses across many industries.
Leave a Reply
You must be logged in to post a comment.