A review of different architecture models and the rationale for selecting the appropriate architecture for any application built for private or public cloud infrastructure
Abstract
Applications that started as simple web based applications are now as complex, if not more than large conventional enterprise applications. In addition, there is a proliferation of devices that can be used to access such applications - ranging from laptop computers, mobile devices to other wearable devices and smart devices that form the Internet of Things. As a result, these applications need to handle a large number of concurrent connections and an increasing volume of unstructured data.
In response to this fast changing pace of applications, the underlying infrastructure has also morphed from the conventional manually deployed devices into software driven infrastructure referred to as the cloud. This includes private cloud infrastructure on premise, or publicly hosted cloud services. Hence the scope of software development has extended beyond business applications and databases into provisioning and managing the underlying computing, network and storage devices.
As a result of these major changes, the architectural models that were used to design early web applications are no more able to handle the level of complexity, load and automation that are required for the large, modern applications that are built for the cloud.
This paper describes various canonical architecture models and proposes broad decision factors based on which an appropriate mix of components can be chosen from these canonical models to create the required architecture for any given application.
Canonical Architecture Models
There are three canonical architecture models that represent phases of evolution of applications with significantly different capabilities. These models are not exclusive - for an application may consist of a hybrid architecture that combines aspects of each of these models, However, it is easier to highlight the differences by treating them separately.
The following sections briefly describe these three canonical models, and highlight their components and capabilities.
- Monolithic Architecture
- Service Oriented Architecture
- Microservices Architecture
The criteria used for comparing the capabilities of the three models are:
- Componentization: Nature of reusable components used to build complex applications
- Integration: Mechanism used to integrate between components of the application
- Scaling: Mechanism used to scale the application to handle increasing amount of load
- Change Management: Mechanism and process for managing change in the application
- Development Process (SDLC): Process best suited for developing and deploying applications using the architecture model
Monolithic Architecture
The Monolithic Architecture is a consists of the following elements:
- Front End - A user interface rendered in web browsers. Typically generated as HTML embedded with CSS and Javascript from the server
- Application - A server-side element consisting of a single application that served requests behind a web server. Typically deployed as a single monolithic executable
- Database: A backend database that holds all the data for the application. Typically a relational database split into multiple tables
The following table describes the various capabilities of this architectural model:
| Criterion | Capability |
|---|---|
| Componentization | Reusable libraries that are compiled into the application |
| Integration | In-process synchronous function/method calls |
| Scaling | Scaling by replicating application on multiple servers with load balancing |
| Change Management | Handled by clubbing changes into periodic release cycles with strict governance |
| Development Process | Waterfall process with well defined roles and responsibilities, and strictly controlled release process |
Advantages
- Easy to manage development process for smaller applications
- Several mature tools and platforms are available
- Testing is simple for all the functionality is available in a single place
Disadvantages
- Difficult to manage when application becomes complex
- Components cannot be independently modified or deployed
- Inefficient resource utilization for scaling as entire application has to be replicated
- Unable to handle large volume or complexity of data
Service Oriented Architecture
- Front End - A user interface rendered in web browsers. Typically generated as HTML embedded with CSS and Javascript from the server
- Orchestration - centralized implementation of business rules and processes that utilize reusable services
- Services - Independently deployable services that share a common data model
- Database: A backend database that holds all the data for the application. Typically a relational database split into multiple tables
The following table describes the various capabilities of this architectural model:
| Criterion | Capability |
|---|---|
| Componentization | Independently deployable services that share a common data model typically defined by a WSDL |
| Integration | Point-to-point synchronous integration between service components using strict contracts (WSDL) |
| Scaling | Independently scalable service components, providing better utilization of resources |
| Change Management | Business rules can change independently in different services, but changes in data model are difficult to implement |
| Development Process | Independent teams implement different services in an agile process, aided by automated integration/regression testing |
Advantages
- Efficient management of larger applications with large number of components or services
- Several mature tools and platforms are available
- Leverages cloud infrastructure elasticity to manage resource-efficient scaling
Disadvantages
- Difficult to manage when number of component services become very large
- Difficult to make data model changes as services share the same data model through strictly defined contracts
- Orchestration becomes difficult to manage when business rules change frequently
- Unable to handle large volume or complexity of data
Micro Services Architecture
The Micro Services Architecture is a consists of the following elements:
- Rich Internet Clients - Self contained client applications built using Javascript frameworks, or native applications for various devices
- API Gateway - a component that isolates and consolidates backend microservices into use-case specific front end services for client applications
- Micro Services - independently deployed applications that handle self contained services that typically implement an entire vertical including business logic as well as associated databases
- Events Store / Queue: a component that records all significant events in the application and helps to synchronize operations between multiple micro services
The following table describes the various capabilities of this architectural model:
| Criterion | Capability |
|---|---|
| Componentization | Independently deployable self-contained services that have their own data models and databases |
| Integration | Loosely coupled asynchronous integration between services through publish-subscribe events |
| Scaling | Independently scalable service components, providing better utilization of resources |
| Change Management | Business rules as well as data models can change independently in different services |
| Development Process | Independent teams implement different services in an agile process, aided by automated integration/regression testing as well as automated continuous integration and deployment |
Advantages
- Efficient management of applications with large number of components or services
- Highly scalable and flexible model that handles large volume of data with different types of client devices
- Services can be granularized at any level with minimal impact on the entire application
- Leverages cloud infrastructure elasticity to manage resource-efficient scaling along with automated deployment
- Provides support for Polyglot Persistence thereby supporting different data models and big data platforms
Disadvantages
- Business functions that span multiple services are more difficult to test
- Development tools and platforms are not as mature as other architecture models
- Requires developers to be trained in continuous integration / deployment methodologies - a DevOps culture.
Hybrid Architectures
The three canonical architecture models described above are not exclusive in nature. Most applications do not start off as very large applications and often it is advisable to start with a monolithic architecture when the application is young, and then gradually start peeling away functions into independent services.
This section describes some typical scenarios where a hybrid of the three canonical models provides the required convenience, flexibility and scalability.
One typical hybrid architecture is where a monolithic application is incrementally modernized into a micro services architecture. The following diagram represents a hybrid of a monolithic application and a micro services architecture.
This Hybrid Architecture is a consists of the following elements:
- Legacy UI - The user interface that may have been developed along along with the legacy monolithic application. Typically generated as HTML embedded with CSS and Javascript from the server
- Monolithic Application - The legacy monolithic application that provides core capabilities of the application, and that are gradually extracted into independently running micro services
- Legacy Database - The legacy database that may have been deployed along with the monolithic application and that hold all historical data
- Rich Internet Clients- New user interface components or native applications for various devices that could be integrated into the legacy UI
- API Gateway - a component that isolates and consolidates backend microservices into use-case specific front end services for client applications
- Backward Integration Services - services that are developed for integrating the new micro services or new user interface with the legacy application or database
- Micro Services - independently deployed applications that handle self contained services that typically implement an entire vertical including business logic as well as associated databases. Such services could be extracted out from the legacy monolithic application. Typically, performance critical services that need independent changes or scaling are good candidates for such micro services.
- Events Store / Queue: a component that records all significant events in the application and helps to synchronize operations between multiple micro services. The backend integration services also use the events queue to synchronize with other micro services.
The following table describes the various capabilities of this architectural model:
| Criterion | Capability |
|---|---|
| Componentization | Core service components embedded in the monolithic application as co-compiled libraries. Performance critical and fast changing services created as independently deployable self-contained services that have their own data models and databases |
| Integration | Tightly coupled integration between backend integration services and monolithic application or database. Loosely coupled asynchronous integration between new micro services through publish-subscribe events |
| Scaling | Monolithic application scaled by replication. Newer micro services independently scalable, providing better utilization of resources |
| Change Management | Changes in monolithic application are clubbed together into fixed release cycles. Changes in newer micro services handled independently |
| Development Process | Core team working on monolithic application continues to work with waterfall process. Independent teams implementing newer micro services follow an agile process, aided by automated integration/regression testing as well as automated continuous integration and deployment |
Advantages
- Provides a seamless modernization path for legacy monolithic applications without significant downtime
- Increasing efficiency of management of legacy applications with continuous refactoring and modernization
- Allows the organization to adopt the DevOps culture of continuous integration / deployment incrementally
- Provides a path for migrating performance sensitive application components into a highly scalable and flexible model that handles large volume of data with different types of client devices
- Services can be incrementally granularized at any level with minimal impact on the entire application
- Leverages cloud infrastructure elasticity to manage resource-efficient scaling along with automated deployment
- Provides support for Polyglot Persistence thereby supporting different data models and big data platforms
Disadvantages
- Though such an incremental modernization architecture provides a path to move from legacy monolithic applications to the micro services architecture, the in-between stages requires the organization to maintain both versions simultaneously
- Business functions that span multiple services are more difficult to test especially if split between legacy and modern architectures
- Development tools and platforms are not as mature as other architecture models
- Requires developers to be trained in continuous integration / deployment methodologies
Choosing the right architecture
As demonstrated by the previous section with a sample hybrid architecture, it is possible to choose aspects of various elements of the canonical models based on the requirements of a particular application and development team.
This section attempts to identify some broad decision factors based on which the various elements of these models can be combined to arrive at an appropriate architecture for any application.
| Layer | Decision Factors | Recommended Option |
|---|---|---|
| User Interface | Support for legacy browsers required Support for multiple devices not required Relatively stable UI without frequent changes |
Server-side generated UI, HTML with embedded CSS, Javascript |
| Support for legacy browsers not required Support for multiple devices required Frequently changing UI |
Rich Internet Clients using modern Javascript frameworks | |
| Application / Services | Clearly defined business functions with minimal changes over time Tightly integrated components that are difficult to separate Relatively small development team |
Monolithic Application |
| Complex use cases with simpler underlying data models Business rules changing frequently with minimal or no changes in base components Large development team split by technical capabilities |
Orchestrated Services | |
| Complex use cases, complex data models Business rules changing frequently Large development team split by business functions |
Micro Services | |
| Database Note: Please refer to Database Selection Matrix for choice of database technologies | Well defined data model No significant changes in data model over time Well known query requirements for all use cases |
Single database appropriate to the data model |
| High level of variability in data model Data model changes frequently Different type of querying capabilities for different use cases |
Polyglot Persistence - different databases coexist, Command-Query-Responsibility-Separation (CQRS) |
These are broad decision factors for selecting various architectural elements. Design of any application architecture will obviously need a much more detailed analysis of actual requirements.
Conclusions
The three canonical architectural models described in this paper highlight key differences in capabilities between them based on the criteria of componentization, integration, scaling, change management and development process.
These canonical models are not exclusive and there can be a hybrid approach that can be followed based on the maturity of the application and the technical and evolutionary requirements.
Some broad decision factors have been identified based on which the various elements of the architecture model can be designed.
.png){kind=icon}