Using APIs and Microservices as a Fast, Low-Cost and Low-Risk Innovation Engine

APIs and microservices are proving key to digital transformation – both to re-architect apps or for moving to the cloud.  IBM’s Alan Glickenhouse points to a third benefit: Rapid Innovation.  He shares guidance, business ideas and even architecture tips to let you take your APIs and microservices to the next level.

by Alan Glickenhouse, API Business Strategist, IBM

Tags: API, agile, architecture, cloud, IBM, innovation, microservices, systems of record,

Alan Glickenhouse, IBM
Alan Glickenhouse
API business strategist
IBM


"Microservices open the door to lower costs and high-control (aka low risk) – all without disrupting your system of record systems."

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

There are not too many topics hotter than microservices in the IT world right now. But perhaps you are missing out on one of the best ways to use microservices – for rapid innovation!

 

In my role as IBM API Business Strategist, I discuss with clients all the time how APIs and microservices can help businesses. Such approaches can speed time to market, increase customer reach, expand market reach and lower cost and risk.  

 

Today, many companies are focusing their microservices efforts on two main scenarios:

  1. Re-architecting applications – To enhance or modernize their existing applications (and app frameworks) to make them more agile.
  2. Cloud Migration – To convert existing apps (or create new ones) using scalable, self-contained services. These can then easily be ported to a container-based cloud infrastructure.

These two approaches to microservices have proven they can deliver benefits – and so it’s no surprise they are becoming more mainstream.

 

But there’s a third scenario for microservices that deserves attention.

 

We call this approach “Rapid Innovation” and it will really take your microservices and APIs up a notch – and help drive your company’s ability to innovate with less risk and low cost.

 

The Initial Models for Using APIs
At the outset of their adoption of APIs, most businesses are looking to expose existing data and transactions from a Systems of Record using APIs only, without microservices adding any additional business logic.

 

The goal is to expose crucial data and transaction information from legacy systems into easy-to-consume self-service business APIs. These APIs allow easy access to existing legacy systems. 

 

For the most part, these APIs provide developers a simple and reliable way to access crucial data which can be used for new business projects – all without requiring changes to the back end SoRs. This ‘without change’ dimension is important, as these new APIs are accessing existing core assets already being used for other purposes within the enterprise. 

 

See Figure 1 – Today’s Topology for API Creation and Consumption

 

An API developer (1) can create an API on their laptop and do unit testing. When ready they push the API to the API Management Server (2) for governance, lifecycle management, setting of security, rate limits, and deployment. 

 

The API is deployed to the Developer Portal (3a) and the API Gateway (3b) and is ready for action. A business developer (4) signs up to use the API.  The application they create (5) then calls the API which causes the flow through the API Gateway. (6) for security and policy checking, accesses the SoR, and returns the result. Analytics (7) from the gateway are gathered and viewed via the API Manager.

 

Using APIs and Microservices for Innovation

This initial scenario works fine if all the needs of the business developers can be met by exposing existing assets.  But at IBM, we recommend companies should also explore using APIs and microservices for other business benefits.

 

Ask yourself these ‘what if’ questions: 

  • What if your business is trying to experiment with a new innovative offering that is not done today? 
  • What if your competitor or new market entrant implements a new offering that needs to be countered? or,
  • What if your business recognizes a new requirement that is not currently available in the existing SoR systems? 

In many of these situations, new business logic will likely need to be created. This change, in turn, would also likely require a change to the SoR. But, as we said before,  SoR changes shouldn’t be made quickly. SoR is where your company’s Crown Jewels info (Golden Records for customer data, product data, transactions, financials, etc.) reside.  No surprise that with so much crucial data in the SoR, most every company moves slowly and cautiously when it comes to making SoR changes for fear of causing a system outage or to ensure security and governance.

 

So, here’s the balancing act:

How can a company encourage new ideas yet ensure the integrity of their existing SoR systems, data and applications? 

 

How can a company promote changes quickly (‘fail fast’ techniques) without sidestepping best practices for SoR prudence?

 

Enter microservices. Done properly, when used to innovate with business logic, microservices open the door to lower costs and high-control (aka low risk) – all without disrupting your SoR systems.

 

Microservices Deliver Innovation by Balancing New Ideas with Old (Proven) Best Practices

Using a microservice tier in the architecture, businesses can rapidly create and run new business logic outside the SoR. The microservices can reach into the SoR to obtain the assets available today, then introduce the new business logic that is being tried and respond to the API request. 

 

Figure 2 – API and Microservice Topology

 

The Developer toolkit (1) is used to create a microservice. The API Management server (2) also manages the microservice governance. When the microservice is ready for deployment it is pushed to the (8) container manager (e.g. Kubernetes) which manages the Microservice compute runtime clusters. API calls that benefit from the new microservice business logic would follow flow (9) which calls the microservice, obtains existing data from the SoR and then provides the new business logic before returning to the API caller.

 

Once the microservice solution is live it is easier to tweak the implementation and adjust for improvements while in the microservice tier rather than SoR. Finally, a decision is made as to the success of the microservice solution. If a failure, then the microservice solution is thrown away with minimal cost or impact. If the solution is a success, then the microservice can either be left in place or migrated to the SoR under appropriate change management. 

 

Typically, companies will leave the solution in the microservice tier if the need is only for a limited set of scenarios or channels. If, however, the solution would be of broad company value it should become part of the normal company operations and managed as part of the SoR.

 

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