Rapid Development with Microservices

Microservices is not a buzzword anymore, it influences our development process as well as our organizational structure. But still, when we start a new service, we want to move fast. Can we move fast while architecture our system correctly?

After developing a number of services in Wix, I want to share some of my experience with developing and architecting systems while keeping a high velocity.

Transcript

1. Rapid Development Noam Almog, Tech Lead github.com/noam-almog @NoamSon noama@wix.com with microservices
2. Hi. I am Noam Almog Tech lead at Wix.com Lithuania Ukraine Vilnius Kiev Dnipro Wix Engineering Locations Israel Tel-Aviv Be’er Sheva
3. No dream is too big.
4. I wanted to climb a mountain.
5. I want to be a developer.
6. I want to be a GREAT developer.
7. Great developers have... Ownership
8. Great developers cares about... Craftsmanship
9. Great developers are... Customer-oriented
10. Great developers are... Effective
11. How do you start a new service ? Monolith Microservice
12. My Project When our project is new and small, it’s easier to work with a Monolith. New
13. My Project New stable Once it gets more stable, however, it’s easier to work with Microservices.
14. 1. How to build a ‘detachable’ monolith 2. When and how to Split Today: How to develop with a ‘breakup’ in mind My Project New stable 3. What happens after we split
15. How to build a ‘detachable’ monolith New stable
16. What does our current server contains ? Web handlers (controllers) Business logic (services) Persistency (DAO’s) Domain objects Tests
17. New feature request? Think where to add it Core service e.g., notifications (email, sms, push) System feature e.g., backoffice User feature e.g., landing pages stores
18. Think what the new module will contain Web handlers (controllers) Business logic (services) Persistency (DAO’s) Domain objects Tests
19. Put it all in a new, separate module stores-bo stores Web support (controllers) Business logic (services) Persistency (DAO’s) Domain objects Tests
20. Pitfall #1 Dependencies New stable
21. If it depends on something, it will never stand alone. backoffice class is using stores class stores bo
22. server wiring ITs for the system stores stores-core stores-server business logic Step 1 Split your existing service to core & web
23. Step 2 ‘Break’ the dependency core bo api server 1. Extract interface to api module 2. Wire them together on server module 3. Remove dependencies
24. What about Domain Objects? Should we extract them too? bo core api server User
25. Yes! They’re APIs too. bo core api server User ▪ Don’t overshare ▪ Share only what’s needed
26. “Good fences make good neighbors” - Robert Frost
27. Pitfall #2 Persistency New stable
28. The problem with one big database is... 1. Dual read/writes to the same table 2. Developers encouraged to add joins between tables core bo
29. Start with communicating indirectly core bo Core Client 1. Extract a client (API) 2. Move references from DB to client 3. Split to different DB’s
30. But I already joined tables! What can I do? Join is now a server concern.
31. What about performance ? ▪ Synchronous joins over IO - Pull ▪ Local Copy - Pull ▪ Event sourcing - Push
32. Final tip Try to postpone persistency as much as possible. 1. Write and test persistency in-memory 2. Load memory with some data 3. Persist to global location if needed 4. When domain is stable enough, create a DB
33. Our monolith is detachable. Great! When & how to Split? New stable
34. Triggers for a Split Scale one service needs more resources Stability extract for stability for critical service Core external usages Reorganization move service responsibility
35. Triggers for a Split Scale one service needs more resources Stability extract for stability for critical service Core external usages Reorganization move service responsibility Do we really need to? Not always...
36. How to Split ? stores-api stores-core stores-bo stores-server
37. How to Split ? Step 1 Copy the module to another repository Wrap it with a new service backoffice-core backoffice-server (new server harness, IT’s) stores-bo
38. How to Split ? Step 2 Make new service communicate with the remote one backoffice-core backoffice-remote-store backoffice-server stores-api stores-core stores-server (new server harness, IT’s)
39. How to Split ? Step 3 Define I/O operations as functions. backoffice-remote-stores stores-api stores-core stores-server (new server harness, IT’s) backoffice-core backoffice-server
40. You’re as fast as your slowest team... So make it easy for others to work with your service! New stable
41. To do Make your service easy to work with ❏ Provide some documentation: how to use your service ✔
42. To do Make your service easy to work with ❏ Provide some documentation: how to use your service ❏ List all tests for the contract that you provide ❏ Create a testkit for integrating with your service ✔ ✔ ✔
43. To do Make your service easy to work with ❏ Provide some documentation: how to use your service ❏ List all tests for the contract that you provide ❏ Create a testkit for integrating with your service ❏ Reduce your integration code ✔ ✔ ✔ ✔
44. Final tip Notice common patterns ▪ Common patterns generate a viable framework ▪ Extract libraries and core services
45. Takeaways New stable Build a ‘detachable’ monolith (beware dependency & persistency pitfalls) A split is triggered by a need (when it does, extract to a remote service) You are fast as your slowest team Common patterns are backbone
46. Q&A github.com/noam-almog @NoamSon noama@wix.com