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
Slide 2
Slide 2 text
Hello!
ScalaMatsuri2018 CfP（落選）
2
Slide 3
Slide 3 text
Using Akka?
Akka is awesome & flexible.
However…
Systems in PRODUCTION
requires:
▸ Logging
▸ Monitoring
▸ Security
▸ etc...
3
Slide 4
Slide 4 text
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
Slide 5
Slide 5 text
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
Slide 6
Slide 6 text
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
Slide 7
Slide 7 text
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
Slide 8
Slide 8 text
“While squbs provides a
server infrastructure, it
does not define a
framework.”
- squbs Top page
8
Slide 9
Slide 9 text
5 Design
principles of
squbs
▸ Separation of
Concerns
▸ Loose Coupling
▸ DRY
▸ Minimize
Duplication of
Effort
▸ Thin Platform
Principles of squbs Design - squbs
9
Slide 10
Slide 10 text
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
Slide 11
Slide 11 text
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.
Slide 12
Slide 12 text
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.
Slide 13
Slide 13 text
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.
Slide 14
Slide 14 text
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.
Slide 15
Slide 15 text
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
Slide 16
Slide 16 text
THANKS!
Presented by Yoshitaka Okuda
Special Thanks @jooohn1234 !
You can find me at @yoskhdia
16
CREDITS
Special thanks to all the people who
made and released these awesome
resources for free:
▸ Presentation template by
SlidesCarnival
▸ Photographs by Unsplash
18