The Power of DevOps: Streamlining Software Development and Delivery - Part 1 ( Microservice - Container)

In current rapidly evolving days Application development continues to move toward a container-based approach, increasing our need to orchestrate and manage resources. If we need to understand the power of DevOps then we need to understand What DevOps means and how it is used and what problems it solves along with how we manage it simplify, automate, secure and deliver.

Why we move to container-based approach ?

In order to understand microservices, we need to understand what are monolithic applications and what led us to move from monolithic applications to microservices in recent times.

A monolithic architecture is a traditional model of a software program, which is built as a unified unit that is self-contained and independent from other applications. Application is built as a single unified unit while a microservices architecture is a collection of smaller, independently deployable services.

A microservices architecture, also simply known as microservices, is an architectural method that relies on a series of independently deployable services. These services have their own business logic and database with a specific goal. Updating, testing, deployment, and scaling occur within each service.

What happens when you build an application as a single, deployable unit that works quite well, but over time it grows in size and complexity along with your business? It often becomes more challenging to maintain, development velocity slows, performance get impacted and risk of failure increases. In this case, the evolutionary path is for the monolith to evolve into a distributed system, typically a micro service architecture which spread across different nodes which share and common goal. This Distributed systems aim to remove bottlenecks or central points of failure from a system. A microservices architecture is one type of distributed system, since it decomposes an application into separate components or “services”. For example, a microservice architecture may have services that correspond to business features (payments, users, products, etc.) where each corresponding component handles the business logic for that responsibility. The system will then have multiple redundant copies of the services so that there is no central point of failure for a service. With microservices the services should be decoupled so that invoices or payments services can be accessed even if the ordering or product listing service system is down. Also, it allows you to optimize or evolve the invoice (microservice) table independent of others. Each service might end up having its own datastore to access the data it needs. This introduces new problems since some data will be duplicated in different databases. Bounded contexts can identify the best strategy to handle shared or duplicate data. You may adopt an event-driven architecture to help syncing data across multiple services. For instance, your billing and delivery tracking services might listen for events emitted by the account service when customers update their personal information. Upon reception of the event, these services will update their datastore accordingly. Even You can also choose to keep all customer information in the account service and only keep a foreign key reference in your billing and delivery service. These services then interact with the account service to get relevant customer data instead of duplicating existing records. Different solution for the problem.

Hope this clarifies the different approach and problem it creates and solution which needs to be applied.

A monolithic architecture is a singular, large computing network with one code base that couples all of the business concerns together.  To make a change to this sort of application requires updating the entire stack by accessing the code base and building and deploying an updated version of the service-side interface. This makes updates restrictive and time-consuming.

Monoliths can be convenient due to ease of code management, cognitive overhead, and fast development speed due to the simplicity of having an application based on one code base. This allows everything in the monolith to be released at once hence testing and debugging is simplified.

Microservices architecture decouple major business, domain-specific concerns into separate, independent code bases. Microservices don’t reduce complexity, but they make any complexity visible and more manageable by separating tasks into smaller processes that function independently of each other and contribute to the overall whole. 

In short, having a microservice architecture makes developing and maintaining each business capability easier. But things become more complicated when you look at all the services together and how they need to interact to complete actions. Your system is now distributed with multiple points of failure and you need to cater for that. You need to take into account not only cases where a service is not responding, but also be able to deal with slower network responses. Recovering from a failure can also be tricky at times since you need to make sure that services that get back online do not get flooded by pending messages.

Adopting microservices often goes hand in hand with DevOps, since they are the basis for continuous delivery practices that allow teams to adapt quickly to user requirements.

Development process

Monolithic applications are easier to start with, as not much up-front planning is required. You can get started and keep adding code modules as needed. However, the application can become complex and challenging to update or change over time.

A microservice architecture requires more planning and design before starting. Developers must identify different functions that can work independently and plan consistent APIs. However, the initial coordination makes code maintenance much more efficient. You can make changes and find bugs faster. Code reusability also increases over time.

Deployment

Deploying monolithic applications is more straightforward than deploying microservices. Developers install the entire application code base and dependencies in a single environment. 

In contrast, deploying microservice-based applications is more complex, as each microservice is an independently deployable software package. Developers usually containerize microservices before deploying them. Containers package the code and related dependencies of the microservice for platform independence.

So Lets see what container does in the Devops process (DevOps is a software practice that allows a shorter development lifecycle with automation tools).

[Containers are completely Isolated environment which shares same OS & Kernel with specific compute resources, services and network resources].

When we talk about Container what generally comes in to our mind is Docker. Hence without understanding Docker and its components we cant proceed further.

[Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications, whether on laptops, data center VMs, or the cloud as a Container]

Docker Image: It's like a recipe card for an app. It lists all the ingredients and steps, just like cooking. Docker images start with a base and get customized.  

Docker Container: Containers are like baking pans . Each holds a part of your app, separate yet self-sufficient. You can run multiple containers side by side, like baking several cakes at once.  

Docker Registry: Docker registries are like libraries filled with recipes. It's where you find pre-made recipes (images) or add your own to the collection.  

Docker Engine: Meet the tech chef , Docker Engine. It makes sure everything runs smoothly, just like a chef running a kitchen.  

Dockerfile: Think of Dockerfiles as cooking guides. Each line is an instruction, like a recipe. Building images is like cooking – each step adds to the final result. 

Docker Swarm & Kubernetes: These are like teams at a big event. They manage different tasks, making sure everything runs smoothly, like a well-coordinated crew.

So if we summarize Docker is a containerization platform and runtime and Kubernetes is a platform for running and managing containers from many container runtimes. Kubernetes supports numerous container runtimes, including Docker

Please refer Part 2 for more details about the Kubernetes