This Month's Dive: The Yesware server architecture is an evolving thing, beginning with a single monolithic app, it is now augmented with a series of various sized services. All of these services are written in Ruby and run on Heroku. We will present the technologies we leverage, some patterns we use and hoops we have to jump through to achieve this. We will also discuss the process of evolution our system has taken and the lesson's learned. About Yesware: 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. Presenting From Yesware Justin Mills - Justin is an Engineer at Yesware and has worked on various aspects of the Yesware stack from monitoring systems to features such as click-to-call. Interested in hosting the next Stack Dive? Let us know! jim@smarterer.com | @jfmyers01 joe@smarterer.com | @jiqtoo www.stackdive.com

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

4. What is Yesware?
4

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.

6. What is Yesware?
6

7. Culture
7

8. Culture
Small autonomous teams
8

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

12. Boxes and Lines
12

13. Architecture
Evolution from a single app…
13

14. Architecture
Before
14

15. Architecture
…into a big app and many smaller ones.
15

16. Architecture
Now
16

17. Evolution
17

18. Architecture Evolution
Some necessity
18

19. Architecture
Some refactoring
19

20. Architecture Evolution
Some general goodness
20

21. Architecture
Some new apps
21

22. Architecture Evolution
Some by closing the repository!
22

23. Architecture
Ongoing evolution
23

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

33. Production
Hosted on Heroku
33

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