Skip to main content

IBM

A Full-Stack API Architecture for a Microservice Evolution

In this blog I’ve taking some liberty to extend the general definition of full stack, in order to describe a system architecture that lends itself well to full stack development. With the emergence of micoservices as an alternative to monolithic applications and service-oriented architectures; there is need to elaborate in more depth on an architectural viewpoint that builds on the various architectural patterns, which are often individually expressed as box-and-line diagrams.

Contextually this distributed system architecture is an augmentation of a REST-based centralized messaging topology. The principal goal of this architecture is to meet the demands of a cross-channel business model that will enable the development various UI solutions. Which will  turn facilitate new customer digital experiences. With an ancillary benefit of positioning the enterprise to evolve an infrastructure for building microservices.

The Architectural Challenge

How do you create a system architecture that supports responsive Single Page Applications (SPA); used across customer markets that may diverge while simultaneously positioning your enterprise to support an API development strategy, as well as providing IT with an evolutionary approach for developing microservices?

A Proposed Solution

To meet this architectural challenge, lets extend the REST-based centralized messaging topology with an enhanced API Gateway pattern and then augment the pattern with a technical stack made up of the following architectural components:

IBM / Red Hat - Unlock Potential App Modernization
Unlock Your Potential with Application Modernization

Application modernization is a growing area of focus for enterprises. If you’re considering this path to cloud adoption, this guide explores considerations for the best approach – cloud native or legacy migration – and more.

Get the Guide

A Full-Stack API Architecture for a Microservice Evolution

Operational Decision Management (ODM)

Using ODM we can incorporate the dynamic behaviors for client channels that vary across markets. Add a distributed full-text search engine housing schema-free JSON documents and this component will support dynamic type-ahead and lookup features to enrich the user experience.

Incorporate a NoSQL database to support the SPA using node.js technology. Use cases for this component will vary based on architectural constraints or challenges. Client drivers, security, potential storage capacity, data integrity, and performance to name a few concerns.

The API solution incorporates a Developer Portal to expose bit internal and public APIs. Introducing the portal even before the organization has started down the path of exposing business capabilities is a good practice. Management of APIs internally lends itself well to agile development. Additionally, it enables the organization to flesh out a well-reasoned API management strategy, and helps to facilitate the dialog of aligning business capabilities to the IT resources models in the important data modelling process of service development.

Although orchestration avoidance is a desired architectural constraint, it may be unavoidable based on information models in the legacy EIS. And as in many legacy environments there may remain a number of EIP Use Cases such as; control and routing, aggregation, transformations, managed file transfers, to mention a few. Additionally, the ESB provides a range of transport and connectivity components for the range of EIS technology variants.

This bring us to microservices. This article is not intended to take a deep dive into micorservice design or implementation. But rather to suggest that with this system architecture we now have a foundation for an evolutionary path away from the monolithic application style to combination of API and microservices architectural style.

At a minimum there are three architectural concerns to consider.

First, the microservices architecture style was prompted primarily through the development of continuous delivery, and the notion of a continuous deployment pipeline, to streamline application deployment.

The second concern is the distributed nature of services. Where all architectural components are fully decoupled and are accessed through some sort of remote access protocol (e.g., JMS, AMQP, REST, SOAP, etc.). Which enables a highly scalable design and enables an agile deployment approach.

Perhaps the concern that is most important, is the concept of service component granularity and modularity which may range from a single-purpose function, to a larger business application. This is grounded in two fundamental principles. First, microservices are business units that model the company processes, and second, microservices have smart endpoints to expose the business logic and they communicate using simple channels and protocols.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Gary Shepard

More from this Author

Follow Us