Explain Microservices Like I'm Five

Comments

[EJBroeders]

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.

[Milan Chheda]

Thanks for the detailed explanation, EJBroeders! 👍

[EJBroeders]

No problem! :-)

[Donald Merand]

EJBroeders did an excellent job of explaining this for smart adults! I'm going to try my hand at an analogy that hews to the "five years old" side of things, just in case a more generic tale is helpful :)

Imagine you have one best friend with whom you do everything! You read together, ride bikes together, and talk together. One day, your best friend is sick, so you can't read with anybody, or ride bikes with anybody, or talk to anybody, because you only have the one friend.

You decide that you'll make three new friends instead: one who loves to read, one who loves to ride bikes, and one who likes to sit around and talk. One day, your friend who loves to ride bikes falls off her bike and can't ride bikes that day. Fortunately, you still have somebody to read with and somebody to talk to!

Your one friend with whom you do everything is a "majestic monolith" - it's great to have a relationship like this, but it's hard to cultivate and potentially catastrophic if something goes wrong with it. Your group of three friends are microservices - you're spreading the risk around by making friends this way, at the possible expense of more difficult communication, and missing out on a deeper connection.

[Gunnar Gissel]

You can run everything in one big program, but it gets crowded. It's a bit like when the garage is messy, we have to do a lot of work every time we want to take your bicycle out to play.

Microservices are like giving everything in the garage their own garage. A garage for your bike, a garage for my wrench, a garage for my hammer, and so on and so forth.

The smaller garages are really easy to put stuff in and takes stuff out of, but when you want to do something big, like have a squirt gun fight with your friends, you have to unlock lots of little garages to get your water balloons and squirt guns.

When you only have one garage, sometimes it's hard to tell where to start cleaning, or where something is in the garage. When you have many tiny garages, sometimes you lose a whole garage!