A talk about why not to build Microservices right off the bat, and some of the problems you have when jumping into them too early.

1. Microservices
Please, don’t
Sean Kelly
@StabbyCutyou

2. What we’ll cover in the next 10 minutes
● Microservices
● The problems people seem to use them to solve
● Why you shouldn’t rush to use them

3. Microservices
● “Tiny” composable services
● Own a single domain or distinct set of behaviors
● Communicate over a network protocol

4. Why people use them
● “It keeps the code much cleaner”
● “It’s easy to write services that just do one thing”
● “They’re faster than monoliths”
● “It’s easier for engineers to not all work in the same codebase”
● “We just autoscale them in clusters and also maybe Docker is in there
somewhere”

5. Cleaner Code?
● Microservices are not a prerequisite for writing good code
● You don’t need a network boundary to implement a Service Oriented
Architecture in your applications.
● Keeping logic out of models and controllers and into domain-driven services will
give you
○ A clean set of objects to use which control all important behaviors
○ A proper chain of dependencies, cleanly represented by the services interface
○ An easy injection point for mocking and stubbing
● Service Oriented Architecture starts in the code itself

6. Easier?
● Writing services that only own distinct pieces of the domain isn’t always “easy”
● Crossing multiple service boundaries adds a lot of complexity
● If multiple services are involved in reading/writing data for a single logical
“request”, you now have distributed transactions
● Distributed Transactions are never easy
● What happens if Service 3 of 5 fails? Does that matter?
● What happens if you make multiple concurrent service calls, and half fail?
● Each interaction needs a custom approach for handling it’s unique failure cases

7. Faster?
● This is anecdotal
● “We took a really old codebase and re-wrote it, now things are faster!”
● In general, you can more easily keep microservices free of bloat
○ But you can do that in Monolithic applications as well
○ It takes discipline, but this is true of any proper practice in engineering
● Often, much of the performance gains are inherent to a new language or
technology being chosen
○ Not because a microservice in general was a better idea

8. Easier for Engineers?
● You have to run lots of different services to make even the smallest change
● Testing to prevent breaking changes between services can be complicated, time
consuming
● Individual teams owning individual projects breeds “Not my problem” syndrome
● Larger, collaborative codebases can help engineers share knowledge and effort

9. Microservices + Docker == scalable clusters
● True fact
● But you can do it with a monolithic codebase as well
● You can direct traffic at the edge of your system to various clusters
○ You can even design “internal” and “public” facing versions of each cluster
● This lets you respond to particular surges in traffic across individual parts of your
ecosystem
● As well as tune the clusters for their specific workloads
● Microservices work well for this
○ But so can Monoliths

10. When to use Microservices?
● When you truly understand the domain you’re building around
● When you can reason about what distributed transactions mean to your apps and
services
● When you have the right monitoring to know how the larger number of
distributed services are behaving
● When you can demonstrate that there is a real benefit to the organization by
implementing the pattern over your current codebase

11. Thanks!
Microservices: Please, don’t
Sean Kelly
@StabbyCutyou