StackDive: Yesware
Download as PPTX, PDF0 likes670 views
The document outlines Yesware's identity as a sales toolkit for data-driven organizations, detailing the company's engineering culture and architecture evolution. Justin Mills, an engineer at Yesware, discusses the transition from a single application to a more complex architecture with smaller apps and the accompanying challenges. Key takeaways include the importance of closing repositories and the benefits of using RESTful services and queues for communication.
StackDive: Yesware
- 1. StackDive – February 12, 2015
- 2. Who am I? 2
- 3. Who am I? 3 • Justin Mills • Engineer at Yesware (2 years) • Work many layers of the stack • Currently working on our data team
- 5. Yesware is an all-in-one sales toolkit for data-driven sales organizations. We help you connect with prospects, track customer engagement, and close more deals, right from Gmail, Outlook, or your iPhone.
- 7. Culture 7
- 9. Culture Full stack T-shaped people 9
- 10. Culture Firmly established internal open source model 10
- 11. Culture No QA, ops or tooling teams 11
- 13. Architecture Evolution from a single app… 13
- 15. Architecture …into a big app and many smaller ones. 15
- 17. Evolution 17
- 20. Architecture Evolution Some general goodness 20
- 22. Architecture Evolution Some by closing the repository! 22
- 24. Architecture Evolution Lessons learned ● Closing repo works! ● 2+ gets easier. ● Everything is faster with smaller apps. ● We need more tooling! 24
- 25. Patterns 25
- 26. Architecture Patterns RESTful services (mostly) 26
- 27. Architecture Patterns Queues for asynchronous communication 27
- 28. Architecture Patterns What a typical app looks like? 28
- 29. Architecture Patterns Sample system pattern we repeat a lot 29
- 30. Architecture Patterns Did I mention queues? ● Delayed Job (PostreSQL) ● Resque (Redis) ● Sidekiq (Redis) ● Sneakers (RabbitMQ) 30
- 31. Architecture Patterns Client libraries as our API’s 31
- 32. Production 32
- 34. Production Providers for nearly all of our systems 34
- 35. Production Leverage AWS where we need to 35
- 36. Challenges 36
- 37. Challenges Culture ● Who owns what? ● Operations responsibility. ● Case for non-feature work. 37
- 38. Challenges Architecture ● Bad patterns still exist ● Interdependencies ● Complexity ● Technology baggage 38
- 39. Challenges Production ● Long road to happiness on Heroku ● Containerized ● Freedom is limited 39
- 40. Thanks! 40