A review of different architecture models and the rationale for selecting the appropriate architecture for any application built for private or public cloud infrastructure
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.
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.
The criteria used for comparing the capabilities of the three models are:
The Monolithic Architecture is a consists of the following elements:
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
Disadvantages
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
Disadvantages
The Micro Services Architecture is a consists of the following elements:
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
Disadvantages
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:
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
Disadvantages
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.
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.