Download to read offline
Uploaded byOutlyer
Microservices: Why We Did It (and should you?)
Mason Jones shares insights on the decision to adopt microservices at Credit Karma, emphasizing that not all organizations need to transition from monolithic architectures. The advantages of microservices include smaller, understandable components and improved ownership, while also acknowledging increased operational complexity. He advises a cautious, pragmatic approach to implementation, advocating for gradual adoption of necessary tools and practices.
More Related Content
Similar to Microservices: Why We Did It (and should you?)
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 SoftwareEngineer, 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 aredoing microservices, so we should too, right?” Proprietary & confidential
- 6. “But UberAppleBookFlixGoogle aredoing microservices, so we should too, right?” NO. Their problems are not the same as yours. Proprietary & confidential
- 7. “We need toscale our app!” Proprietary & confidential
- 8. “We need toscale our app!” Why do you think microservices will help? Proprietary & confidential
- 9. “We need toscale our app!” Why do you think microservices will help? Proprietary & confidential
- 10. “Everyone says monolithsare evil, so we should kill ours.” Proprietary & confidential
- 11. “Everyone says monolithsare evil, so we should kill ours.” Everyone is not always right. Sometimes monoliths make perfect sense. Proprietary & confidential
- 12. “Everyone says monolithsare evil, so we should kill ours.” Everyone is not always right. Sometimes monoliths make perfect sense. Proprietary & confidential
- 13. “But we hateour monolith.” Proprietary & confidential
- 14. “But we hateour monolith.” So fix it. Does that really require microservices? Proprietary & confidential
- 15. “We no longercomprehend our monolith.” Proprietary & confidential
- 16. “We no longercomprehend our monolith.” Now we’re getting somewhere. Proprietary & confidential
- 17. “We have devsstepping on each other, and deployments take forever.” Proprietary & confidential
- 18. “We have devsstepping on each other, and deployments take forever.” Yep, now we’re talking. Proprietary & confidential
- 19. So…why microservices atCredit 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: • Smallercomponents, easy to understand • Clear ownership from dev to production • Independence faster evolution Proprietary & confidential
- 26. But microservices alsomean: • Greater operational complexity • System as a whole is harder to comprehend • Debugging a monolith is often easier Proprietary & confidential
- 27. Don’t wind upwith this. Proprietary & confidential
- 28. Our approach Started slow– low-risk, new, small service Proprietary & confidential
- 29. Our approach No orchestrationframework Proprietary & confidential
- 30. Our approach No orchestrationframework –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 weunderstand our needs –running Consul –running Linkerd as a service mesh –now setting up Kubernetes –setting up HashiCorp Vault Proprietary & confidential
- 32. You don’t needthe 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 andcarefully. Proprietary & confidential
- 34. We could alsotalk about: • Security • Backpressure, timeouts, failure handling… • Monitoring & Alerting • Distributed Tracing • …and much more! Proprietary & confidential
- 35. Thanks. Yes, we’re hiring. MasonJones Staff Software Engineer, Infrastructure Services @masonoise mason.jones@creditkarma.com engineering.creditkarma.com
Editor's Notes
- #5 - Then if they insist, we can talk about their reasons, if they have any!
- #22 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.
- #23 - The monolith had become too large and complex to reason about. Nobody understood it all, and there were parts nobody knew anymore.
- #24 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.
- #25 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.
- #29 Don’t try to chip off part of the monolith first – start with something that has no dependencies and doesn’t really matter much
- #30 We didn’t set up Kubernetes, Swarm, Mesos, Nomad Simple deployment tool: here’s a set of servers, here’s an image, run it
- #31 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
- #33 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)
- #34 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)
- #35 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)