Microservices is a style of setting up a project though using only very small modules. Instead of a more classic project in which everything is more coupled, a microservice architecture tries to decouple all modules as much as possible. Possible modules / microservices in this sense are authentication service, signing up service, logging service, content delivery service, etc.
Each module / microservice is a small program that runs stand alone which connects with the other services through light weighted API calls, often through a Rest interface. To manage all those different services and spin them all up at once software like Docker swarm, Kubernitz, and Openshift has been developed. Those packages allow to monitor multiple applications / services and provide the flexibility to provide each service with the resources that it needs.
The advantages of this type of architecture is are: Better scalability of the project, instead of giving the whole application more resources only the modules that need it get more resources. Better error resistance, one service failure does not bring the whole system down, but only a fraction of it, which can then be independent of the rest of the system restarted. And easier parallel development through the loose coupling.
The downside is that a project needs someone who can manage such a cluster and set everything up. Also the developers of different services have to communicate and document how the services should be used, say the API.
It is in summary a complex architectural system in which a large application is broken down in many loose coupled microservices. Which makes it more manageable with respect to resource usage and easier to develop with many independent teams.
Microservices is a style of setting up a project though using only very small modules. Instead of a more classic project in which everything is more coupled, a microservice architecture tries to decouple all modules as much as possible. Possible modules / microservices in this sense are authentication service, signing up service, logging service, content delivery service, etc.
Each module / microservice is a small program that runs stand alone which connects with the other services through light weighted API calls, often through a Rest interface. To manage all those different services and spin them all up at once software like Docker swarm, Kubernitz, and Openshift has been developed. Those packages allow to monitor multiple applications / services and provide the flexibility to provide each service with the resources that it needs.
The advantages of this type of architecture is are: Better scalability of the project, instead of giving the whole application more resources only the modules that need it get more resources. Better error resistance, one service failure does not bring the whole system down, but only a fraction of it, which can then be independent of the rest of the system restarted. And easier parallel development through the loose coupling.
The downside is that a project needs someone who can manage such a cluster and set everything up. Also the developers of different services have to communicate and document how the services should be used, say the API.
It is in summary a complex architectural system in which a large application is broken down in many loose coupled microservices. Which makes it more manageable with respect to resource usage and easier to develop with many independent teams.
Thanks for the detailed explanation, EJBroeders! 👍
No problem! :-)