Introduction to Docker and Container based development
Advancement of Application Architecture throughout the years
An application architecture can be referred to as a map that explains how the software applications of an organization are congregated together and how those applications interact with each other in order to meet business or user requirements.
Generation 1 — Physical Servers
In earlier days, we deployed our applications in physical servers. There were 3 different physical hardware boxes for Web Servers, Application Servers and Database Servers.
✽ The problems existed with this architecture are;
➣ Maintenance Issues — Multiple people were needed
➣ Required space
➣ Required Operating Systems
➣ Required separate network
➣ Costly
➣ Waste — Each server may not get 100% utilized
Ex: App Server & Web Server ➜ Do not use 100% of processing power and memory of that box.
DB Server ➜ Does not use 100% of space of that box
In order to overcome these problems, the Hypervisor technology came into picture.
Generation 2— Virtual Servers
Let us see how this virtual environment is formed with the help of a diagram.
✽ The waste problem is solved.
How ❓
Here, we have used only 50% of the processing power. The remaining 50% can be used to create other Virtual Machines. Ex: If you need any Mail Server, Proxy or a Load Balancer.
Disadvantages of this architecture
♨️ Costly
↪︎ Licensing costs
↪︎ Costs for patching / Maintenance / Updates
♨️ Lots of Management work
↪ ︎If we need another web server, we have to create another VM, we need to install another Operating Systems and web servers.
♨️ Time consuming
↪ To spin new VMs
↪ Time spent to do configurations because same host name cannot be there in same network.
♨️ Maintenance costs
Unsolved problems in this architecture
📍 Still there are multiple Operating systems
📍 Timing issues since it takes time to start VMs because we need to boot up. Booting cannot be done in seconds.
Generation 3— Container-Based Applications
The main purpose of container-based development is to not being locked into one vendor/platform.
Let us see the architecture of container-based applications.
● Here, Costs for patching, licensing and updates as well as maintenance cost problems are solved since everything is utilized on top of a single Operating System.
● A container is not equal to a hypervisor and it is way too smaller than a hypervisor. Hypervisor has its own Operating System, but docker does not have any.
The image below illustrates how the containers differ from virtual machines.
Docker / Container
There was a cloud platform called .cloud. Docker was created as a separate project by Docker Inc.
✦ Docker is an open source project licensed by Apache 2.0 License. This is not owned by Docker Inc., but they were the pioneers in this project. Docker was developed using Go Language.
✦ Docker is a Container. When using Docker, separate Operating Systems and virtual machines are not needed. Since we do not have multiple operating systems, multiple licensing and patching are also not needed. Docker is on top of a host operating system. As operating system has already started, it starts your application very quickly.
✦ There is a FALSE belief that Docker is not persistent(Everything gets lost when shut down). By nature, Docker is Persistent. It does not destroy your work once shut down. As a best practice, it is advised to use your data in an external storage environment if it is a Database Docker.
✦ In Docker, there are no limitations technically. You can port into containers no matter if it is stateful or stateless. But you may not be able to get full fledged features.
Ex: If your app is developed to use a physical box or a VM, your app may be bundled everything together. In that case, you cannot get full-fledged feature sand benefits of Docker.
However, you cannot push into Docker if you have a classic and multi boxed old environment. It is always better to go with a micro level service architecture if using container based applications. When using Docker, you can have a single, responsible small application and can create an independent container for that and can let that container run as it leads to have a self healing capability to your application.
Docker Engine
✦ Docker engine is not a Docker project. It is a small part where core orchestration, registry, security and services are built on top of the docker engine.
- Orchestration
Orchestration is the process where all the instances are taken together and striding towards a common goal. Different containers can be created for HTTP runtime engine, authorization process, login, services.
2. Registry
This is a place where we can store our Docker images.
Ex: MongoDB, MySQL or any other Docker Image. We can push these into a registry.
✦ Docker Hop is the largest cloud/repository/registry that contains more than 250K repositories and over billion downloads. You can download whatever the repository or Docker image you want, customize it and push back. If your environment has multiple hosts and if you want to use these customized images back, you can download or point those hosts to a particular Docker registry. So that you can download your customized version.
✦ Repositories can be either private or public. If a repository is private, only you can access it. If the repository is public, anyone can pull it. But only you or the people that you have granted can commit to your repository.
Kubernetes
Kubernetes is a tool/platform/software which can be used for orchestration process which was initiated by Google. But now it is an open source project. Kubernetes can be used for web hosting at scale.
Features of Kubernetes:
◾️ Storage orchestration
◾️ Service discovery
◾️ Self-healing
◾️ load balancing
◾️ Automatic bin packing
◾️ Secret and configuration management
Open Container Initiative — OCI
Docker Inc. launched their product and some other companies started using it. But they figured out, it does not match their specifications/requirements. They realized some architectural issues. Therefore, they implemented a similar type of framework called ‘Rocket’. (RKT) And there was a conflict as there were 2 different companies taking 2 different paths almost for the same initiative. Hence, they created a mutual agreement/organization called OCI.
The main objective of Open Container Initiative is to govern and specify container development. It supports in moving vendor/platform specific code into engine.
Important Facts
🔔 In order to get best results using container based applications, you may need to redesign your application.
🔔 Almost all cloud platforms support Docker.
Ex: Amazon, Google cloud
🔔 When writing codes, you can modify Docker application, push and test it. If all tests are passed, it will move to Docker registry. From Docker registry, continuous integration happens.
