Don't build framework, Build platform

Transcript

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