Harnessing the prowess of API-talism
In the usual case of resolving an issue or a problem, some people might think to jump into a solution pragmatically, but others need to take on a different perspective to give a contextual solution. In short… to harness the potential capabilities of the API, at least you need to know the drivers and how the technology will be the enabler. Some afterthought that I’ve been collecting from the past experiences and try to map it with Gartner’s Critical Capabilities Research, you can see some interesting ideas.
So, what should we do to overcome these challenges? a typical response on how organization prepare them-self for the ecosystem demands, well I’m talking for an example from… I think for most of us familiar with typical e-commerce applications scenario, whereby there are consumer apps, service integration layer (that usually manage by an ESB platform) and the back-end applications as the fulfillment system (figure below). Hence, a common approach to managing the agility, time-to-market for product base solution is to introduce micro-services design in the architecture building block, that has direct integration from the consumer apps to individual services to get development fast enough to be launch and introduce to the market.
In this typical approach, it introduces several concerns, such as:
- The point-to-point integration (spaghetti mess) that SOA is trying to eliminate with the use of Enterprise Service Bus (ESB), an example of a complex application scenario whereby the consumer apps will create dozens to hundreds of service calls. Hence, maintaining and monitoring would be a challenge
- Implementing authentication, authorization and throttling for each micro-services would create duplication and unnecessary efforts
Therefore, to resolve these concerns few patterns are being introduced — as we go along in the journey at Bank Mandiri, we have been exercising some of the patterns (some plus and minuses, cornerstone, roadblock that we have been experiencing), so I’d like to share it with you and discuss to get a feedback from you.
- First Pattern: The API Gateway pattern
In this API gateway pattern, all incoming request comes from consumer apps and must come to a well-defined message gateway that mainly responsible for request routing, composition and protocol translation. The API gateway will often handle a single request by invoking multiple micro-services and aggregate the results. At Bank Mandiri, this is the very first pattern in the beginning we’ve started the journey, we have introduced the API gateway to decouple some of the services from consumer apps and provider apps, at the same time decomposing bulky services into more isolated self-dependent services.
2. Second Pattern: Micro-services aggregator pattern
In a typical SOA implementation, virtual composite services are exposed from an ESB layer to integrate multiple services and other systems. The similar approach, we can adopt into micro-services architecture with the API gateway as the service broker. Within this pattern, we can build composite micro-services or we can call it “micro-services aggregator” that consumes two or more microservices like in our previous example of e-commerce application that consumes the Orders and Shipping micro-services. We can actually writes the business logic in that service aggregator such as conditional items, choices delivery and so on. Cool right!!
3. Third Pattern: Micro-gateway pattern
Within this pattern, it’s great when it comes to scalability of your integration platform, in some typical scenario when one of the micro-services we’ve deployed are constantly being accessed then the other micro-services e.g. the product micro-services frequently being accessed , since lots of request for browsing the product catalog are more frequent the Order micro-services, it is very logical we need to scale those services, but since the API gateway platform still runs on monolothic server. Then, scalling one part of the micro-services requires scalling the entire gateway deployment. To accomodate this situation, a micro-gateway is a good alternative where there’s a micro-gateway per set of micro-services, whenever a micro-services or set of micro-services need to be scaled, then only the portion of gateway that fronting the micro-services will be scaled along with the subset of it.
Then came along the problem of your brownfield (existing) implementation, I think most of the organization has already implemented some integration architecture approach e.g. ESBs. Like Bank Mandiri as example, therefore my recommendation is to go with hybrid approach, whereby co-existance between the SOA/ESB and the micro-services. So, it’s very logical to have a transitional or staggered approach of migrating from existing integration services into the new model
To summarize this sessions, I think you can analyze which pattern that suits your organization considering the condition (business requirement) and maturity of your services, equipped by adequate resource to help you transformed the architecture landscape of your APIs.
Thanks for your attention and keep watching for the next issues…
(To be continued…)
