Which application architecture model is best for you in the cloud era?

Increasingly, businesses are going through a digital transformation journey to meet evolving consumer needs. Customers are also more and more likely to be using social networks, mobile applications, and digital technologies. Due to this change, digital strategy is now an integral part of the overall business strategy.

Many enterprises are obtaining computing power through cloud services platforms via the internet and adopting a cloud-first strategy for most application development. This has furthered a change in application design—previously, functionality and statefulness were prioritized, but now most consumer-facing applications are moving to Software-as-a-Service (SaaS) and digital platforms. The application design focus is now much more focused on user experience, statelessness, and agility.

Choosing the right application architecture depends on your business requirements. In this post, we will examine four architecture choices for enabling digital transformation, depending on general business needs.

Traditional 3-tier application architecture

We all know about the 3-tier application architecture—it is a client-server architecture with a typical structure consisting of the presentation layer, application layer, and database layer.

It has a user interface, business/data access logic, and data access. Many enterprise applications were created using the simple 3-tier application architecture.

What is the issue with 3-tier application architecture?

Simply speaking, the 3-tier application model is outdated. It was designed for application development before the proliferation of public cloud and mobile applications and has had difficulty adapting to the cloud.

Over time, an application can become too large and complex to make frequent changes. Not only that, but it also requires the maintenance of at least three layers of hardware and software, which can be inefficient for the business.

The 3-tier application model is also frequently called a monolithic architecture. These days, we have multiple new architecture models, and below, we will examine a few that are available now in the cloud era.

1. Microservices architecture

In a cloud model, complex applications designed as a collection of services and data are fully decoupled from the application. Microservices are an architectural style that structures the application as a collection of services. Each service can be written in a different programming language and tested separately. They are independently deployable and organized around business capabilities.

Take the example of an e-commerce application developed using microservices architecture. Each microservice can focus on a single business capability (e.g., shopping cart, search, customer review). Each of these can be a separate service written in different programming languages, deployed in different infrastructure, and managed by different teams.

Each service communicates with the others using a lightweight protocol. For a 3-tier, we all know about the Model View Controller (MVC) framework. Sidecar, Ambassador, and Adapter are some of the frameworks that support microservices architectures.

Microservices architecture vs. monolithic architecture

In monolithic architecture, all these components coexist as a single module managed (mostly) by a single team—everything is bundled together. If you need to update, you need to deploy the entire application, and this slows down changes for larger complex applications. For smaller applications, monolithic architecture is often the best solution.

See the video “What are Microservices?” for a closer look at the differences between microservices architecture and monolithic architecture:

Microservices, containers, and Kubernetes

One of the best choices for creating and running microservices application architectures is by using containers. Containers encapsulate a lightweight virtualization runtime environment for your application and allow you to move the application from the developer’s desktop all the way to production deployment. You can run containers on virtual machines or physical machines in the majority of available operating systems. Containers present a consistent software environment, and you can encapsulate all dependencies of your application as a deployable unit. Containers can run on a laptop, bare metal server, or in a public cloud.

Many organizations use Kubernetes to manage containers and ensure that there is no downtime. Kubernetes provides container orchestration in multiple hosts and is used for container lifecycle management. You can automate deployment, auto-scale your application, and build fast and ship fast using Kubernetes.

For a deeper dive into Kubernetes, see our video “Kubernetes Explained”:

Red Hat OpenShift is one of the most popular leading hybrid cloud enterprise container platforms. Many public cloud providers offer Containers-as-a-Service (CaaS). Some of the other Kubernetes engines available are IBM Cloud Kubernetes Service, open source Kubernetes, AWS (EKS, ECS, and Fargate), Google GKS, and Azure AKS.

Usually each microservice is built by a different small team, and they choose their programming language and deployment schedule. A service mesh like Istio is used by enterprises to govern communication between microservices and management. In a service mesh, requests are routed through proxies (such as Sidecar) between microservices.

2. Cloud native architecture

Cloud native architecture is designed specifically for applications planning to deploy in the cloud, and microservices are a critical part.

Cloud native is an approach to building and running applications that exploits the advantages of the cloud computing delivery model. Cloud native is a term used to describe container-based environments, and it is about how applications are created and deployed, not where.

Cloud native technologies empower us to run applications in public, private, and hybrid clouds. Cloud native development is essential to getting applications to market quickly; it helps people, processes, and technologies to build, deploy, and manage apps that are ready for the cloud.

The video “What is Cloud Native?” gives more of a background on the cloud native approach:

The cloud native architecture model uses DevOps, continuous integration (CI), continuous delivery (CD), microservices, and containers. Most of the enterprises use the twelve-factor methodology for designing scalable and robust cloud native applications.

In the cloud, applications must be able to run concurrently in multiple nodes, share a configuration/session state, have a centralized logging mechanism, and be able to deploy using DevOps and a CI/CD process. Many cloud providers give guidelines for cloud native development—Amazon Web Services (AWS) has its well-architected framework, Google has various guides on how to build cloud native applications, and Microsoft Azure has its cloud patterns guide.

Usually, cloud native applications are stateless by nature. The services communicate with each other using REST-based protocols or messaging. The API Gateway, container registry, message-oriented middleware (MOM: Publish/Subscribe or Request/Response), service mesh, and orchestrations could be part of cloud native architecture.

3. Event-driven serverless architecture

Event-driven architecture (EDA) is based on decoupled systems that run in response to events. An event-driven architecture uses events to trigger and communicate between decoupled services. EDA has been here for a long time, but it now has more relevance in the cloud.

So, what is new? If properly used, it can provide a significant increase in agility, cost savings, and operational benefits. The distributed serverless EDA can execute code known as functions that scale automatically in response to a REST API or an event trigger.

For the serverless model, there is no server management needed. The serverless model is also quickly scalable (so quick updates and deployment are possible) and it is stateless.

Here are some of the currently available cloud serverless services from different cloud providers:

Types of serverless

• Functions-as-a-Service (FaaS): Upload pieces of functionality to the cloud and let these pieces be executed independently.
• Backend-as-a-Service (BaaS): Utilize services from a third party, such as application management, database management, and cloud storage.
• Mobile-Backend-as-a-Service (MBaaS): Functions for mobile applications.

4. Cloud-based architecture

How can we make monolithic applications work well in a cloud environment? Cloud-based architecture is best suited for building a modern web application (static/dynamic websites), deploying a web application, connecting to a database, and analyzing user behavior.

A traditional cloud-based application architecture involves load balancers, web servers, application servers, and databases. It can benefit from cloud features such as resource elasticity, software-defined networking, auto-provisioning, high availability, and scalability.

This type of architecture is ideal for organizations that don’t have to worry about maintaining a server. The serverless functions support different programming languages, such as PHP, Java, .NET, Node.js, Python, Ruby, Docker, and Go.

API Gateway is an important service that makes it easy for developers to create and publish secure APIs. The APIs will act as a front door for applications to access data and business logic. It also takes care of authorization and access control. Developers use API Gateway to invoke different serverless functions for different API calls.

How to decide which architecture model is best for your application

The decision you make when choosing an architecture model can influence the success or failure of your project. You should make your choice based on your application and on non-functional requirements. For example, you don’t choose airplane transportation when you want to travel just a few miles.

Consider the following before choosing an architecture for your app project:

• Is it monolithic-first or microservice-first? (For smaller projects with a simple application requirement, monolithic may be a right choice.)
• Is your team ready to utilize microservices?
• Does your team have an existing cloud-based DevOps and CI/CD process?
• What is your hosting model? Private, public, hybrid?
• How does the application architecture affect your project?
• Does a combination of multiple architecture model work for you?
• Do you need persistence and sessions for your applications?

Summary

Web application architecture keeps evolving to meet the digital business requirements and changing IT infrastructure environment. Technologies such as Artificial Intelligence, Analytics, Automation, Advanced Robotics, Edge Computing, Blockchain, Internet of Things (IoT), and APIs are redefining what is possible in many industries. Increasing complexity in infrastructure, application, and data size requires new architecture approaches. Most of enterprises are adopting a multicloud approach by using one or more cloud providers. Enterprises are consuming cloud services by either using private, public, or hybrid with SaaS, PaaS, or IaaS models.

In earlier days, application deployment was a difficult process and could not be done during normal business hours. However, different deployment methods (such as blue-green and canary deployment) along with DevOps and CI/CD (continuous integration and continuous delivery) now allow deployment at any time without any application outages.

Monolithic architectures are still valid for many applications but the right architecture must be used for your digital use case to achieve agility and time-to-market. For a simple application, consider choosing a traditional monolithic approach. The cloud native or microservices patterns work great for evolving applications with complexities. It makes sense to use microservices architecture when you have multiple experienced teams that use multiple languages and deployment schedules. A comparison between traditional 3/N-tier application vs. cloud-based architecture models is given below for reference.

To get started building, sign up for an IBMid and create your IBM Cloud account.