Microservices: Why We Did It (and should you?)
•Download as PPTX, PDF•
0 likes•402 views
Mason will present a skeptical, humorous, and practical look at whether companies should consider microservices, and why/not. The story includes the reasons why Credit Karma did make the move, the approach we took, and shares some of our learnings so far.
Recommended
More Related Content
What's hot
What's hot (13)
Similar to Microservices: Why We Did It (and should you?)
Similar to Microservices: Why We Did It (and should you?) (20)
More from Outlyer
More from Outlyer (20)
Recently uploaded
Recently uploaded (20)
Microservices: Why We Did It (and should you?)
- 1. Mason Jones June 2017 Microservices: Why We Did It (And Should You?)
- 2. Mason Jones Staff Software Engineer, Infrastructure Services @masonoise mason.jones@creditkarma.com INTRODUCTION Me: • 25+ years in Bay Area tech • Have seen architectures come & go • (Optimistic?) Skeptic Proprietary & confidential
- 3. “You’re doing microservices? Cool, we’re thinking about doing that, too. Do you think we should?” Proprietary & confidential
- 4. “You’re doing microservices? Cool, we’re thinking about doing that, too. Do you think we should?” NO. Proprietary & confidential
- 5. “But UberAppleBookFlixGoogle are doing microservices, so we should too, right?” Proprietary & confidential
- 6. “But UberAppleBookFlixGoogle are doing microservices, so we should too, right?” NO. Their problems are not the same as yours. Proprietary & confidential
- 7. “We need to scale our app!” Proprietary & confidential
- 8. “We need to scale our app!” Why do you think microservices will help? Proprietary & confidential
- 9. “We need to scale our app!” Why do you think microservices will help? Proprietary & confidential
- 10. “Everyone says monoliths are evil, so we should kill ours.” Proprietary & confidential
- 11. “Everyone says monoliths are evil, so we should kill ours.” Everyone is not always right. Sometimes monoliths make perfect sense. Proprietary & confidential
- 12. “Everyone says monoliths are evil, so we should kill ours.” Everyone is not always right. Sometimes monoliths make perfect sense. Proprietary & confidential
- 13. “But we hate our monolith.” Proprietary & confidential
- 14. “But we hate our monolith.” So fix it. Does that really require microservices? Proprietary & confidential
- 15. “We no longer comprehend our monolith.” Proprietary & confidential
- 16. “We no longer comprehend our monolith.” Now we’re getting somewhere. Proprietary & confidential
- 17. “We have devs stepping on each other, and deployments take forever.” Proprietary & confidential
- 18. “We have devs stepping on each other, and deployments take forever.” Yep, now we’re talking. Proprietary & confidential
- 19. So…why microservices at Credit Karma? Proprietary & confidential
- 20. Large PHP monolith, nearing 8 years old. Proprietary & confidential
- 21. Large PHP monolith, nearing 8 years old. Deployment was slowing, >200 developers Proprietary & confidential
- 22. Large PHP monolith, nearing 8 years old. Deployment was slowing, >200 developers Too large for anyone to hold in their head. Proprietary & confidential
- 23. Large PHP monolith, nearing 8 years old. Deployment was slowing, >200 developers Too large for anyone to hold in their head. Change was too slow. Proprietary & confidential
- 24. Large PHP monolith, nearing 8 years old. Deployment was slowing, >200 developers Too large for anyone to hold in their head. Change was too slow. Who owns a monolith? Proprietary & confidential
- 25. Microservices enabled: • Smaller components, easy to understand • Clear ownership from dev to production • Independence faster evolution Proprietary & confidential
- 26. But microservices also mean: • Greater operational complexity • System as a whole is harder to comprehend • Debugging a monolith is often easier Proprietary & confidential
- 27. Don’t wind up with this. Proprietary & confidential
- 28. Our approach Started slow – low-risk, new, small service Proprietary & confidential
- 29. Our approach No orchestration framework Proprietary & confidential
- 30. Our approach No orchestration framework –deployment tool uses Salt, Ansible –Supervisord runs the containers –VIP does load-balancing between instances –one instance per server, same port Proprietary & confidential
- 31. Our approach Now we understand our needs –running Consul –running Linkerd as a service mesh –now setting up Kubernetes –setting up HashiCorp Vault Proprietary & confidential
- 32. You don’t need the fancy tools on Day One • Use what you know • Be pragmatic • Keep your reasons in mind • Learn what you really need • Iterate Proprietary & confidential
- 33. Move slowly and carefully. Proprietary & confidential
- 34. We could also talk about: • Security • Backpressure, timeouts, failure handling… • Monitoring & Alerting • Distributed Tracing • …and much more! Proprietary & confidential
- 35. Thanks. Yes, we’re hiring. Mason Jones Staff Software Engineer, Infrastructure Services @masonoise mason.jones@creditkarma.com engineering.creditkarma.com
Editor's Notes
- - Then if they insist, we can talk about their reasons, if they have any!
- Every planned deployment contains hundreds of merges, testing is difficult. Frequent, small deployments is far better: problems are quicker to spot, changes are easier to understand.
- - The monolith had become too large and complex to reason about. Nobody understood it all, and there were parts nobody knew anymore.
- We wanted teams to be able to consider, decide, and execute quickly. Experiments were very difficult. Trying to understand the potential impact of changes became increasingly difficult.
- A monolith is owned by everybody, which means it’s owned by nobody. Teams should own their world in its entirety, which requires independence. Microservices make this possible.
- Don’t try to chip off part of the monolith first – start with something that has no dependencies and doesn’t really matter much
- We didn’t set up Kubernetes, Swarm, Mesos, Nomad Simple deployment tool: here’s a set of servers, here’s an image, run it
- Sounds terrible? No, it’s a stepping stone, an MVP not perfection We used the tools we already had and knew well – granted, we may be the only people in the world using supervisord to run Docker
- Keep in mind your reasons for microservices: we wanted to start making teams independent as quickly as possible Your direction might be different if your goals are different (scaling, integrating an acquisition, who knows)
- Keep in mind your reasons for microservices: we wanted to start making teams independent as quickly as possible Your direction might be different if your goals are different (scaling, integrating an acquisition, who knows)
- Keep in mind your reasons for microservices: we wanted to start making teams independent as quickly as possible Your direction might be different if your goals are different (scaling, integrating an acquisition, who knows)