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.

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