Microservices - Please, don't
•
4 likes•3,368 views
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.
Report
Share
Microservices - Please, don't
- 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