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:
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.
