Today's web applications, we can categorize into three common architectural patterns.

1. Monolithic architecture
2. Microservices architecture
3. Serverless architecture

We do this categorization based on the backend—the server-side part of web applications. This is where we—DevOps engineers—are most interested in.

There are other architectural patterns too. For example, you can identify several architectural patterns from how the frontend of a web app is created. But they do not have much influence on our work as DevOps engineers.

The backend architectures do have a direct impact on how we practice DevOps.

So, let's explore these three backend architectural patterns in detail.

Monolithic architecture

A monolithic application is built as a single, unified unit.

All the components—the user interface, business logic, and data access layer—are packaged together into a single deployment artifact, like a single JAR or WAR file for a Java application. If the application is developed in an interpreted language like Python, the artifact could be a zip file containing all the Python code, JavaScript, CSS, and static images.

Traditionally, you'd deploy monolithic applications by installing the application on the OS in a virtual or bare-metal server. But, nowadays, most monolithic web applications are deployed on Docker. In this case, the deployment artifact is a container image.

Note that some people consider containers as synonymous with microservices. They are not. Even though you containerized an application and deployed on Docker, it will still be a monolith, if the code is architected as a monolith.

Pros of monolithic architecture

• Simplicity: For smaller projects, a monolithic architecture is straightforward to develop and test. Everything is in one place, which makes debugging and managing dependencies easier.
• Lower initial cost: You don't need to worry about complex distributed systems. A single codebase and a single database can get you up and running quickly.
• Easier to deploy: The deployment process is simple. You just deploy the single artifact to a server or a set of identical servers.

Cons of monolithic architecture

• Tight coupling: Components are tightly dependent on each other. A change in one part of the application can have unintended side effects elsewhere.
• Scaling challenges: You can only scale the entire application, even if only one part of it (like a specific API endpoint) is under heavy load. This is inefficient and can be costly.
• Slower development cycles: As the application grows, the codebase becomes massive, making it difficult for multiple teams to work on it simultaneously without stepping on each other's toes.
• Technology lock-in: It's difficult to introduce new technologies or programming languages into a monolith without a major refactoring effort.

For DevOps, a monolithic architecture means simpler CI/CD pipelines, but at the cost of flexibility. A single failed test or build can halt the entire deployment.

Microservices architecture

This architecture breaks down a large application into a collection of small, independent, and loosely coupled services.

Each service represents a specific business capability, such as "user management" or "product catalog." These services communicate with each other through lightweight APIs, usually over HTTP.

Each microservice is an independent deployment unit. Containers are the de facto standard for deploying microservices. As each microservice is built into a separate container image, you get not one but a number of artifacts to deploy.

For a simple application, this number could be 10 or 20. But, complex applications may have hundreds of microservices, and thus hundreds of container images to deploy.

This is where DevOps practices really shine as you probably do not want to build and deploy hundreds of container images manually.

Due to the nature of microservices, apps architected in microservices support DevOps practices:

• Continuous deployment (CD): Because each service has its own pipeline, you can deploy a new version of a single service without affecting the entire application. This enables true continuous deployment and faster release cycles.
• Automation: The independent nature of services makes automation a necessity and a core benefit. You automate the build, test, and deployment of each service, leading to a highly automated and efficient workflow.
• Team autonomy: Teams can own a specific service from development to operations ("you build it, you run it"). This fosters a culture of ownership and responsibility, which is a cornerstone of DevOps.
• Scaling: You can scale a single service that is under heavy load without wasting resources on scaling the entire application. This is much more efficient and cost-effective.

Docker and Kubernetes are the platforms for running microservices applications. Kubernetes is the popular of the two as Kubernetes is more scalable and also supports many microservices-friendly features like automatic failure recovery.

But if you have only a handful of microservices, Docker would be better off due to its simplicity.

Pros of microservices architecture

• Flexibility: You can use the best technology for each service. For example, you could use Python for one service and Node.js for another.
• Resilience: If one service fails, it doesn't bring down the whole application. The failure is isolated.
• Easier to maintain: Smaller codebases are easier to understand and manage.

Cons of microservices architecture

• Operational complexity: Managing a large number of independent services is complex. You need to handle distributed systems, service discovery, distributed tracing, and more. This is where tools like Kubernetes, Istio, and distributed logging come into play.
• Data management: Each service often has its own database, leading to challenges with data consistency across the application.
• Increased infrastructure overhead: You might need more servers and more complex infrastructure to run the same application functionality.

Microservices is a relatively new architectural pattern compared to monolithic architecture which has been around for several decades. But, that's not to say the microservices pattern is better than the monolithic pattern.

They are just architectural patterns and excel at different use cases.

Serverless architecture

The serverless architectural pattern came into being in 2014 with the introduction of AWS Lambda. Since then other cloud platforms also have introduced similar services to run serverless application.

Serverless architecture abstracts away the underlying server infrastructure entirely.

Instead of provisioning virtual machines or containers, you simply upload your code in the form of functions, and the cloud provider manages the execution environment. The code only runs when it's triggered by an event (e.g., an HTTP request, a file upload, a database change).

Common platforms for serverless web applications

• AWS Lambda: The original and most popular serverless platform. It's the foundation for many serverless applications.
• Azure Functions: Microsoft's offering, deeply integrated with the Azure ecosystem.
• Google Cloud Run: Google's serverless solution, offering tight integration with other Google Cloud services.

Pros of serverless architecture

• No server management: This is the biggest advantage. You don't have to patch operating systems, manage servers, or worry about capacity planning.
• Automatic scaling: The cloud provider automatically scales your functions up or down to zero, based on demand. You only pay for what you use. This can lead to significant cost savings.
• Faster development and deployment: Developers can focus solely on the business logic, and deployment is often as simple as a single command.

Cons of serverless architecture

• Vendor lock-in: Your code is often tied to the specific serverless platform's APIs and event model, making it difficult to migrate to another provider.
• Cold starts: If a function hasn't been used recently, it might take a few seconds to "warm up" on the first request, leading to latency.
• Debugging challenges: It can be more difficult to debug and troubleshoot issues in a distributed serverless environment compared to a traditional server.
• Stateless nature: Serverless functions are typically stateless, which means they can't maintain session information. This requires a different approach to state management.

For DevOps, serverless simplifies many tasks, but it introduces a new set of challenges around monitoring, observability, and managing the event-driven architecture.

---

Choosing the right architecture is a critical decision that influences every aspect of the application's lifecycle. As DevOps engineers, our job is to understand these trade-offs and help the team choose the right path to build reliable, scalable, and efficient systems.

We will be diving deep into web application architecture in upcoming posts.

If you've still not subscribed, subscribe to The Cloud Letters to read them in your inbox.