Use API-First Design to Address Multi-Cloud Architectures

As companies are planning for cloud and multi-cloud architectures, they also hope to gain  more agility in their applications. Cost, agility, and scale are all key considerations.  Alan Glickenhouse, an IBM API Business Strategist, shares how an API-First design lets enterprises achieve these outcomes without major complexity.

by Alan Glickenhouse, API Business Strategist

Tags: agile integration, API, cloud, design, microservices, System of Record,

Alan Glickenhouse, IBM
Alan Glickenhouse
API business strategist
IBM


"Rather than build an API based on System of Record systems or microservices, create the API based on the needs of the consumer. By building the API first, it will be far more usable, consumer friendly and backward compatible."

CLOUD-CON
Integration & APIs
Enterprise-Grade Integration Across Cloud and On-Premise
Online Conference

 

What is your cloud strategy? 

 

Resistance or an umbrella is probably not a good option. 

Over the last few years, working at IBM I’ve seen a wide variety of customer choices when it comes to embracing the cloud as part of a modern architecture. Planning for cloud may include:

  • private clouds,
  • moving a few System of Record applications to a cloud (or more than one cloud),
  • re-architecting applications using microservices,
  • using SaaS applications, and
  • deploying test environments on cloud now with more cloud usage later. 

 

They all can work, -- on their own, or in combination.

 

But the best way to capture huge and long-lasting ROI from any cloud program comes from taking a breath and asking a few deeper questions about your long-term goals.

 

For example, certainly, ‘system of record’ (SoR) applications will exist on premise for a long time too. But, there are many unknowns.

  • When will you move to the cloud and what will move?
  • Which cloud provider(s) will you use?
  • How can you maintain interoperability and portability between on-premise and any cloud provider so that you can be prepared no matter what cloud choice is made or if cloud providers are changed or added?
  • What if your company merges or acquires another company that is using a different cloud provider?

 

The common theme we’re seeing is simple, but oh so powerful:

 

As companies see cloud(s) on the horizon (forgive the pun), they are recognizing the need for more agility in their applications. This includes the ability to deploy applications or parts of applications to the cloud, have them scale as required, and provide cost savings over sizing on premise solutions for peak workloads. Cost, agility, and scale are all key considerations. 

 

However, the decisions you make at the start need to also let you make adjustments, as needed. Things change. Costs may change, different capabilities in clouds may direct functionality to more than one cloud, and cloud geography or functional limitations may drive the use of additional clouds. The need for cloud independence is being recognized, even by companies that intend to, at least initially, deploy to a single cloud provider. These requirements are often met through rearchitecting all or parts of the existing monolithic applications as microservices.

 

Agile Applications Require Agile Integration

Using microservice architectures for your applications provides cloud independence and agility. Great, problem solved.

 

Well, not so fast. With this new-found freedom of location for applications comes additional complexity for application integration. So again, it’s time for another deep breath (along with another set of powerful questions to ask yourself).

 

Microservices allow applications to move. But even with mobility, how will they integrate with each other? It’s a good question because it makes little sense to have two or more applications on the same or different clouds come to an on-premise integration component to call back out to the cloud and then come back on premise to route the response back to the same or another cloud. Considering also that some applications are remaining on-premise, so moving the integration component (e.g. ESB) into a single cloud does not solve this either.

 

Figure 1 - Modern Enterprise SoR

 

Clearly any single point of integration (such as an ESB, enterprise service bus) is not going to resolve this issue. The same agility and cloud independence is required for the integration components as the applications. How do we obtain this? The same answer – microservices.

 

By deploying microservice integration components we can choose which locations make the most sense to execute specific integration logic (note – integration logic should still not be buried inside the application itself). Using microservices improves the agility and deployment flexibility for both applications and the integration components. 

 

API First Design

Okay, now the problem is solved, right? Almost. But as I’ll explain, there’s just one more dimension to truly deliver some huge benefits: Agility, flexibility and ROI from your cloud-centric app projects.

 

We need to be concerned about our application consumers. We need to consider:

  • minimizing the impact to our consumers as our applications change and move,
  • API management and execution that is just as flexible and scalable as the newly architected applications they access.

We have architected to enable change for our applications and the integrations between them, which is great. Our SoR applications can move, our integrations can be adjusted and changed more rapidly, but how do we shield all this potential change from applications that are calling these back-end SoRs?

 

If the interfaces we are exposing are based on the SoR applications, then every time we change these applications from their monolithic state to the new microservice architecture, we might need to adjust the interfaces. The downstream effect of having to change every calling application each time we change a microservice or back-end application can stifle our desired (and we thought new-found) agility.

Figure 2 - Modern Enterprise SoR with Systems of Engagement and Partner Consumers

 

But, if we separate the called application interface from the application structure and its parameters, then we can keep the interface stable even when the application behind it changes. Rather than build the interface based on the SoR systems or microservices, create the application interfaces (APIs) based on the needs of the consumer.

 

In fact, by building the API first or without knowledge of the back-end application structure, the API will be far more usable (consumer friendly) and backward compatible – even if the back-end systems are changed, moved or re-architected. 

 

Take as an example an interface designed for a “check order status” function in retail. If I base this on the consumer view, then all I need to provide is the user’s order number and identity. But, if I based this on the back-end CRM, ordering, inventory, and logistics systems the interface would be significantly more complicated and not backward compatible.

 

As with the earlier discussion about integration agility, we also need API management agility. This means the ability to deploy APIs near the SoR systems they access which could be on any number of clouds or on-premise. What is the solution? Yes, you guessed correctly – microservices. Having the ability to deploy an API Gateway, analytics, the developer portal and even the API manager on the cloud of your choice, or on-premise gives you the flexibility needed from API through the back-end SoR.

 

API first design provides independence between consumers and providers. Either the consumer or provider can change without affecting the other. If we build the APIs based on the back-end parameters, we cause non-backward compatible changes each time we make a SoR change. Microservices provide independence of location and scale for the APIs, their management, internal application integration, and the SoR applications. Together API first design and microservices provide the agility we need as we plan for multi-cloud deployment.

 

---

Alan Glickenhouse is an IBM API Business Strategist for IBM API Connect, where he focuses on helping companies leverage APIs and microservices to deliver more innovation to their business. You can reach Alan on Twitter at @Arglick.  

 




back