Reasons you should use Microservices to build your next application

You’re looking for a new architecture for your next software project, and you’ve heard about this thing called Microservices.  It sounds cool, but you’re not sure if it’s a fit for your next project.  Use this handy checklist to decide if using Microservices are right for you.

• It’s a dynamic new paradigm that drastically increases complexity; what’s not to love?
• Networks are fun to troubleshoot.
• You can now use Brainfuck in a production application!
• You missed the XML wave and the Actor model wave; you’re not missing this one.
• Scaling out is so much more fun than worrying about application server performance. Throw more hardware at it!
• You have a friend who works in the server sales business and you owe them some favors.
• How else are you going to get to put “Docker” on your resume?
• Event-driven, disconnected, asynchronous programming was way too easy in a monolith.
• You also have a friend in the server logging and metrics business (Is it New Relic or Spleunk?) and you own them favors (you owe a lot of people favors, don’t you).
• You’ve taken Spolsky‘s “Things you should never Do part 1” as a challenge.  After all, you’re not rewriting the app, you’re reimagining it.
• The Single Responsibility principle needs to go to its fanatical conclusion to finally become a reality: One line of code per service.
• Your DI container has pissed you off for the last time.
• Complex deployment processes mean job security.
• “DevOps experience” makes a great resume booster.
• 100 git repositories means never having merge issues.
• How else would you get around the Mythical Man Month? 9 women can have 9 babies in 9 months, and they don’t even need to talk!
• Contract testing sounds way cooler than “integration testing”.
• What’s better than 1 REST API? 100 of them.
• You can now force your teammates to learn Haskell (They’ll thank you).
• You can now use the best tool for the job, even if it requires you to go through a few months of training to learn that new tool, and did I mention they only do training on Cruise ships to Tahiti? (it’s not your money you’re spending, after all).
• Whenever someone asks how you’ll solve an architecture issue, you can always say, “That’s a future us problem”. TAKE THAT, MONOLITHS.
• The grand total of documentation is a README in the root of each git repository.
• Monoliths generally only have one codename; with Microservices you can have hundreds. Time to bust out that greek mythology.
• Of course your application needs to be able to support a distributed event queue; why is that even a question? You need to obviously scale out to billions of operations per speed.

Microservices don’t sound like your cup of tea? Try Reasons you should Build a Monolith.