Microservices are here to stay
Breaking a complex set of operations (aka monolithic architecture*) down into discrete and small parts** has lots of advantages:
- Makes it easy to change one part of the application without affecting others (good for developers)
- Doesn’t require the entire application to be restarted when something changes (good for admins)
- Allows scaling each service individually based on its resource requirements.
- Instead of having to run huge servers, the microservices can be deployed on smaller hosts with only the minimal resources required.
- Adds extra flexibility because each service can be implemented in the language most suitable for the operations that service performs
- Provides security benefits because if different parts are isolated from one another, an attacker who is able to hack / break one service does not gain control of the entire application.
*Aka monolithic architecture
**Discrete and small parts
But all these benefits don’t come alone, microservices architecture have their own disadvantages:
- It’s difficult to know which hosts are running certain services because these are spread across multiple servers
- The number of hosts will grow fast as the microservices architecture scales out, resulting in over-provisioning, increased costs and management complexity
- If different programming languages are used, each service will require its own set of libraries and frameworks, making deployments more complex
And to solve all this count on…
Linux containers can help mitigate many of these challenges:
Containers make use of kernel interfaces which allow multiple containers to share the same kernel while running in complete isolation from one another. This isolation makes deploying microservice code developed using different languages and frameworks very easy.
The portability of containers makes deployment of microservices a breeze. To push out a new version of a service is as simple as stopping the running container and starting a new one based on a Docker image using the latest version of the service code. All the other containers running on the host will be unaffected by this change.
If a given service isn’t using all the resources (CPU, RAM) on a host, additional services can be launched in containers on that server that make use of the idle resources, helping with the efficient utilization of resources in your platform.
In summary, the use of a microservices architecture with linux containers addresses both the need to make better use of compute resources and the need to maintain increasingly complex web-based applications.
Geko team has years of experience with Docker and container lifecycle, we can help you with:
- Docker-based development environments
- Container orchestration (Kubernetes or Docker Swarm)
- Container build and delivery (links a CI y CD)
- Monolith to Microservices migration
- Platform optimization