Skip to content
Close
21 min read

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:

text

  • 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

text

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:

text

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

text

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.