How to choose an architectural model for your cloud applications?

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.

1. Monolithic Architecture
2. Service Oriented Architecture
3. Microservices Architecture

The criteria used for comparing the capabilities of the three models are:

1. Componentization: Nature of reusable components used to build complex applications
2. Integration: Mechanism used to integrate between components of the application
3. Scaling: Mechanism used to scale the application to handle increasing amount of load
4. Change Management: Mechanism and process for managing change in the application
5. 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:

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:

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:

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:

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.

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.