What’s a Microservice: A short story
Imagine you have 1 person doing 10 jobs. His name is Mono. He’s your monolith.
Now imagine you have 10 people each responsible for 1 of the 10 jobs Mono does. They go by “the squad”, and these are your microservices.
Why would I pay 10 people to do the job I can pay one person to do?
Well to put it bluntly, if Mono is out sick, you’re shit out of luck.
But Mono is rarely ever sick and I love him.
That’s fine, there are plenty of problems you should consider before hiring the squad.
- Cost — Mono may be 10x better than each member of your squad, but he’s probably not paid like it.
- More Resources — Mono needs one visual studio subscription. The squad needs 10.
- Difficult reporting — “Hey Mono, what did you accomplish today?”, is a little more straightforward than asking the squad.
- Speed — The squad has to communicate with each other to hand off tasks. Unfortunately, Neuro-Net isn’t functional yet.
- They’re bad sharers — “Hey squad-mate #2, I saw you built a nifty tool to help us all report to the boss, can I use it?”. “Well, reportings not really my job, but we can hire a new squad-mate to manage and share it with the both of us”.
- Dependencies — The squad had some digging to do today, but you only gave squad-mate #1 a shovel. Squad-mate #1 had an unfortunate bout of alcohol sickness and won’t make it in today. Probably should’ve given Squad-mate #2 a shovel too, eh?
Now, of course, all of this should be taken with a grain of salt. Most of these are solvable problems. The question is whether your organization is large enough and has the resources to manage the squad. They’re a bit rowdier than Mono.