In the last blog, we learned about the core concepts of Docker and how we can create a run .net core app in the container. Today, we are going to learn about the docker-compose to run more than one container together.
It is a YAML file. By default, it’s named docker-compose.yml but it can be changed and specified as a parameter.
First of all, we specify the version of the file. This should be the latest version. I am using 3.6.
Next, we define our set of services. This is where the magic happens. We can define multi-services in one file and run all the service with a single command.
Service has a name, image, build context, environment, network and volume. You can see all the options here.
It’s very easy to manage dockers with docker-compose commands. There are two main commands. Docker-compose up / Docker-compose down.
docker-compose up -d –build
Docker-compose up command run all the services in the compose file. You need to run this command from the directory where docker-compose .yml file is placed.
-d paramter is used to detach console from the container.
By default, images are built when you run this command for the first time. If you make changes to the code, you need to use the –build parameter to tell docker to build image(s) again.
Docker-compose down command stops/removes all the services defined in the compose file. You need to run this command from the directory where the docker-compose .yml file is placed.
Docker-compose is very simple, and helps us run multi-container services from a single file. It is very handy and powerful.
You can download the reference source code on my Github.
Microservices is a new buzzword that is very popular nowadays. I have spoken to a few developers and every single one of them defines it differently. Some say ‘Microservices is just a pattern to break the large monolithic application into smaller monolithic applications’ while others describe it as ‘Microservices is just SOA (Services oriented architecture) done right’. In this blog, we will focus on microservices.
What is a Microservices?
It is an architectural style pattern that is used to develop large complex applications into small modular loosely coupled services that are small, independent, easily manageable, and deployable. In simple words, microservice helps you break a large application into smaller applications that enforce SRP (Single responsible principle).
Companies run into trouble when it gets too difficult to manage a large application and upgrade it. Microservices is the answer and can help us break down complex large applications into small independent applications that communicate with each other using language-independent interfaces (APIs).
History of Microservices
Term microservice was coined in mid of 2011.
The idea behind microservice is just good architecture principles. It has been around for a few decades. In the early 1980’s the first distribution technology Remote Procedure Calls (RPC) was introduce by Sun microsystems.
Who is using it?
Companies like Netflix, Amazon, Uber, eBay, and Spotify have a microservice architecture that helps them serve resources with intensive requests in a scalable manner. Also, a lot of other companies are moving their monolithic products to microservice architecture.
There are many advantages and disadvantages of Microservices.
Modular and independent
Microservices are broken down into multiple service components by design, which are easily developed by small teams. Each of the service component is focused on a specific module, can be developed and deployed on docker independently. This helps new team members understand the functionality in less time.
Decentralised and cross-functional
As Conway’s law states “The design of the software can tell us about the social fabric of the organisation and vice versa”. The small teams where every team member is responsible for each business function is ideal organisation for the development of microservices. From Architects, developers, QA engineers, product owner, analysts and DevOps – Each one is responsible for their own piece of microservices.
Microservices are better for fault isolation, if one service fails, other services will continue to work without impacting the whole system. If our monolithic application fails, everything that it’s accountable fails at the side of it. Therefore, microservices are highly resilient, needs orchestrator and good cloud infrastructure for high availability.
Microservices are designed for scaling. Scaling allows applications to react to variable load by increasing and decreasing the number of instances of the services it’s using. Also, microservices are cost efficient as you scale the services based on their demand but in monolithic application you would have to scale the whole application irrespective of which service/function would be highly used.
Microservices are designed to have their own data storage. This raises another question that how do we achieve the data consistency? We use events driven approach and advanced messaging queue technology (Bus Service, RabbitMQ, etc). If a price of product is changed in the product microservice then we have to update the price in basket microservice.
Microservice is a disturbed architectural design pattern. We have to make calls to different services to get the data. This leads to increase in round trips and more latency. However, you can minimise this by using API aggregate design to aggregate the data through API gateway.
Microservices are small and modular but when you have an application which consists of hundreds of microservices, calling each other. It becomes really complex.
Today, we have discussed what is a microservice, it’s advantages and disadvantages. I have also made a demo app for you to understand the whole concept. You can download the code and play around with it. In the next upcoming articles, I will explain a more hands-on approach and walk you through, how you can develop a microservice.