Don't build framework, Build platform

エムスリーさんのTech Talk #92で話したものです。
https://yoskhdia.hatenablog.com/entry/2018/05/11/212712

1. DON’T BUILD FRAMEWORK, BUILD PLATFORM - Empower high flexibility and scalability in the enterprise with good design principles - 2018/05/11 M3 Tech Talk #92 @yoskhdia
2. Hello! ScalaMatsuri2018 CfP（落選） 2
3. Using Akka? Akka is awesome & flexible. However… Systems in PRODUCTION requires: ▸ Logging ▸ Monitoring ▸ Security ▸ etc... 3
4. Flexibility brings us many choices but often means making chaos “High flexibility” has a trade-off. We DON’T want each team to implement their non-functional requirements. We want to focus on the business domain. 4
5. Don’t hide open knowledge Many people often choose to build their own framework for covering their requirements. However, it forces developers to learn the framework’s SPECIAL SHINY AWESOME PRIVATE API. This is a risk. 5 Any Good Toolkit (Akka, Spring, etc...) Your own Framework
6. One approach 6 Any Good Toolkit (Akka, Spring, etc...) Your own Framework Any Good Toolkit (Akka, Spring, etc...) Your Infrastructure Thin Platform ▸ Don’t build framework ▸ Build platform
7. I want to introduce squbs squbs is: ▸ Developed by PayPal ▸ NOT framework ▸ Suite of components enabling standardization and operationalization of Akka Overview Introduction - squbs 7
8. “While squbs provides a server infrastructure, it does not define a framework.” - squbs Top page 8
9. 5 Design principles of squbs ▸ Separation of Concerns ▸ Loose Coupling ▸ DRY ▸ Minimize Duplication of Effort ▸ Thin Platform Principles of squbs Design - squbs 9
10. Separation of Concerns “Allowing infrastructure to plug in infrastructure concerns without disturbing the application in any way.” ▸ Separate non-functional requirements from functional requirements. ▸ Make those “Concerns” pluggable components. 10
11. Loose Coupling 11 “Tangling of large systems comes from tight coupling of the type system.” ▸ Separate an application into (service) modules called “cube”. ▸ They communicate with each other only via messages, this brings isolation of the service.
12. DRY 12 “The drop-in design of squbs allows for at-most-once coupling.” ▸ Drop-in Modular System provides auto detection of each service modules. ▸ It is easy to add/remove them to/from the system.
13. Minimize Duplication of Effort 13 “Most of the low-level components of the application that deal with application lifecycle and monitoring are common across applications.” ▸ By dealing with lifecycle management will hide and abstract away such duplications, to be standardization & operationalization.
14. Thin Platform 14 “We realize the emergence of the thin platform and try to keep squbs as lightweight and non-imposing as possible.” ▸ Reduce dependencies and Do not impose further requirements. ▸ Developers can leverage general knowledge.
15. Conclusion 15 Any Good Toolkit (Akka, Spring, etc...) Your own Framework Any Good Toolkit (Akka, Spring, etc...) Your Infrastructure Thin Platform ▸ Don’t build framework ▸ Build platform
16. THANKS! Presented by Yoshitaka Okuda Special Thanks @jooohn1234 ! You can find me at @yoskhdia 16
17. Appendix ▸ Back-Pressure in Action: Handling High-Burst Workloads with Akka Streams & Kafka @PayPal ▸ squbs探訪 その1 ▸ squbs探訪 その2（簡単なWebアプリケーションをつ くってみる） 17
18. CREDITS Special thanks to all the people who made and released these awesome resources for free: ▸ Presentation template by SlidesCarnival ▸ Photographs by Unsplash 18