There’s a blog post out about Disasters I’ve Seen in the Microservices World, and the OP is right, those are disasters. It seems easy to avoid the disasters, right? You can look at all those situations and think “whew, that won’t happen to me”, and they may not — if you have a plan.
How many times in tech have you been in a ready-fire-aim situation?
Let me help your recollection.
How many times in tech have you heard the phrase, “We thought it would be easy?”
That phrase is basically its own punchline.
The majority of programmers have never dealt with a distributed system, and the majority of those that have have treated it like it’s RPC. Couple that with a lack of planning and you have a recipe for…well… disaster.
The root cause of microservices disasters is not understanding what problems microservices solve and not planning for your move to microservices.
- What will Microservices mean for my team structure? What will my team structure mean for microservices?
- Do we even need microservices?
- How should our microservices communicate?
- How should our services be broken up?
- What organizational changes do I need to make to support moving to microservices?
There’s a lot you need to know before deciding to move to Microservices, so I came up with a Free email course to help you answer these questions. Just enter your email and subscribe below.