What to expect when you're working with microservices and containers
A microservices architecture splits your application into multiple services that perform fine-grained functions and are part of your application as a whole. Each of your microservices will have a different logical function for your application. Traditional applications have monolithic architectures where all your application’s components and functions are in a single instance; microservices break apart monolithic applications into smaller parts.
Containers are packages of your software that include everything that it needs to run, including code, dependencies, libraries, binaries, and more. Docker and Kubernetes are the most popular frameworks to orchestrate multiple containers in enterprise environments. Compared to virtual machines (VMs), containers share the operating system kernel instead of having a full copy of it, such as making multiple VMs in a single host. Although it’s possible to put your microservices into multiple VMs, you would typically use containers in this case since they take up less space and are faster to boot up.
Why use a microservices architecture?
The microservices architecture was created to address problems caused by monolithic applications. Microservices are already widely used, and some large-scale websites already transformed their monolithic applications to microservices.
Some benefits of using a microservices architecture are:
- Developers will work on a smaller codebase compared to a larger one in a monolithic app. When components of the application are loosely coupled, developers will easily understand the source code and not slow down development. Not to mention, your IDE will be faster if you’re working with a lesser number of lines of code. Developers will not need to deal with the complexities and dependencies of functions that can be found in a monolithic app.
- Responsibilities of the developers will be more defined. A team can be assigned by components or microservices of the app. Code reviews will be faster. Making updates will be quicker and there would be no need to build and deploy everything compared to a monolithic app.
-
The application’s technology stack can differ through microservices. The application will no longer need to depend on one language or library. Microservices can leverage different programming languages as developers see fit.
-
Continuous delivery will be easier. Compared to a monolithic app, you will not need to deploy everything again for a simple change with microservices. You may choose to rebuild and deploy the only microservice that needs to be updated. Frequent updates will be faster.
-
Scalability will be independent to each microservice. You can choose to scale each component of your app depending on the resource it needs. You wouldn’t need to make multiple instances of everything compared to a monolithic app. Scaling the microservices will efficiently use the resources available instead of having multiple copies of the whole application in a monolithic app.
Data can be decentralized. You can choose to use different databases or storage for your microservices. You can choose a NoSQL database if your microservice suits it better than a relational database. A microservice may also only need a simple key-store database such as Redis. As in the diagram below, you can choose a combination of Cloudant, MySQL, and MongoDB databases. You can take advantage of different databases to store different data types.
Isolate failures. An error or a bug in one microservice does not bring the entire system down. When you have loosely coupled components and a microservice in your application hangs or throws errors, there’s less chance that other microservices will be affected since they are in their own containers and don’t entirely depend on each other. A monolithic app can bring the entire process of your application down if the bug or error is not caught properly.
For details check here
https://developer.ibm.com/depmodels/cloud/articles/why-should-we-use-microservices-and-containers/