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.