Introduction

The landscape of application deployment has undergone a significant evolution over the years. From traditional monolithic architectures to the rise of microservices, the need for agility, scalability, and efficiency has driven transformative changes. In this exploration, we'll journey through the past and present of app deployment, delve into monolithic and microservices architectures, and ultimately immerse ourselves in the world of Docker—an instrumental tool in modern containerized application development.

The past and the present of Apps Deployment

Traditional Deployment:

In the past, applications were predominantly deployed using monolithic architecture. A monolith is a single, tightly integrated codebase where all components of an application are interconnected. This approach simplified development but presented challenges in terms of scalability, maintenance, and deployment.

Modern Demands:

As the demands of modern applications grew, a shift occurred towards more modular and scalable architectures. This led to the adoption of microservices, an approach where applications are composed of small, independent services that can be developed, deployed, and scaled independently.

Monolithic Architecture

Monolithic Applications

Pros:

• Simple to develop

• Simple to deploy – one binary

• Easy Debugging & Error tracing

• Simple to test

• Less Costly

Cons:

• Difficult to understand and modify

• Tightly coupled • Higher start-up and load times

• Redeploy the entire application on each update, and also continuous deployment is difficult

• Less reliable: A single bug can bring down the entire application.

• Scaling the application is difficult

• Difficult to adopt new and advanced technology: Since changes in frameworks or languages will affect an entire application

• Changes are one section of the code can cause an unanticipated impact on the rest of the code

Microservices Architecture

Microservices on VMs

Hypervisor

• A hypervisor is software that creates and runs virtual machines (VMs) also known as guests.

• It isolates the hypervisor operating system and resources from the virtual machines and enables the creation and management of those VMs.

• The hypervisor treats host resources—like CPU, memory, and storage—as a pool that can be easily reallocated between existing guests or to new virtual machines.

• Generally, there are two types of hypervisors.

• Type 1 hypervisors, called “bare metal,” run directly on the host’s hardware. Ex: Microsoft Hyper-V or VMware ESXi hypervisor

• Type 2 hypervisors, called “hosted,” run as a software layer on an operating system. Ex: VirtualBox, VMware Player

• Run each service with its own dependencies in separate VMs

• Each VM has its own underlying OS and hosts a Microservice

• Strong isolation and resource control between other VMs and host

• Each VM can have its own dependencies and libraries for the services. So different services across VMs can have different versions of same dependency

• Matrix from hell problem is no more

Microservices based Applications

Pros

• Decoupled

• Ensures continuous delivery and deployment of large, complex applications.

• Better testing — since services are smaller and faster to test.

• Better deployments — each service can be deployed independently.

• No long-term commitment to technology – when developing a new service, you can start with a new technology stack

Cons

• Slow bootup times of VMs

• Increased memory consumption

• Large OS footprint

• Initial Costs are very high, and this type of architecture demands proficiency in the skills of the developers.

• Testing is difficult and time-consuming because there is an additional complexity involved because of the distributed system.

• Deployment Complexity – there is added operational complexity of deploying and managing a system that contains various service types.

Docker 🐳

Dev: It works fine in my system!

Tester: It doesn’t work in my system

Before Docker

A developer sends code to a tester but it doesn’t run on the tester’s system due to various dependency issues, however it works fine on the developer’s end.

After Docker

As the tester and developer now have the same system running on Docker container, they both are able to run the application in the Docker environment without having to face differences in dependencies issue as before.

What is Docker?

Docker is a software development tool and a virtualization technology that makes it easy to develop, deploy, and manage applications by using containers. Container refers to a lightweight, stand-alone, executable package of a piece of software that contains all the libraries, configuration files, dependencies, and other necessary parts to operate the application.

Ex: Ubuntu + Python + Dependencies

VMs vs Docker Containers

Docker Architecture

• Docker uses a client-server architecture.

• Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers.

• Docker client and daemon can run on the same system, or you can connect a Docker client to a remote Docker daemon.

• For a virtual communication between CLI client and Docker daemon, a REST API is used.

Conclusion ✨

The evolution of application deployment reflects a continuous pursuit of efficiency, scalability, and flexibility. From monolithic architectures to microservices and containerization with Docker, each stage has addressed specific challenges in the ever-evolving landscape of software development. Understanding these paradigms equips developers and organizations to make informed decisions based on the specific requirements and demands of their applications. As we continue into the future, the interplay between architectural paradigms and containerization technologies will shape the way we develop, deploy, and scale applications.