2. @Rafael_Casuso
2
A B O U T M E
•CEO @SnowStormIO
•Organizer @BotDevMad
•Software Engineer with +10 years
of experience leading teams and
developing.
•Software Architect looking for
revolutionary ways to change the
world.
•Specialties: JavaScript, NodeJS,
Conversational Intelligences.
4. WHICH ARE MY FUNCTIONAL REQUIREMENTS?_
‣ A SOFTWARE PLATFORM TO BUILD CHATBOTS ON
‣ MULTIPLE MESSAGING CHANNELS
‣ UNIFIED USER SYSTEM
‣ DATA PERSISTENCE
‣ DIALOG SYSTEM
‣ NATURAL LANGUAGE PROCESSING
‣ MULTI-LANGUAGE SUPPORT
‣ EVENT TRACKING
6. THE DARK TRUTH. A SMALL MONOLITH IS…_
‣ SIMPLE TO DEVELOP
‣ SIMPLE TO DEPLOY
‣ SIMPLE TO SCALE AS A WHOLE
‣ MORE APPROPRIATE FOR A SMALL PLATFORM OR APPLICATION
7. WHICH ARE THE DANGERS TO AVOID?_
‣ LARGE MONOLITH DIFFICULT TO UNDERSTAND AND MAINTAIN
‣ DEVELOPMENT SLOW DOWN, CODE BASE INTIMIDATION
‣ MODULARITY IS OPTIONAL, NO BOUNDARIES
‣ INFREQUENT, NOT CONTINUOUS DEPLOYMENT
‣ SCALING INDIVIDUAL COMPONENTS IS IMPOSSIBLE
‣ OBSTACLE TO SCALE DEVELOPMENT TEAMS
‣ TECHNOLOGY STACK LOCK-IN
8. HOW DOES IT LOOK LIKE?_
T
I
E
R
MESSAGING ADAPTER
USER SYSTEM DIALOG SYSTEM
CORE
ADMIN MULTILANGUAGE
CMS
PUBLIC API
DATABASE
INTEGRATION
INTEGRATION
INTEGRATIONTRACKING SYSTEM
CACHE OTHER SERVICES
DATA ACCESS LAYER
11. BENEFITS & DRAWBACKS_
‣ MEDIUM SIZE TIERS EASIER TO LEARN AND MAINTAIN
‣ BETTER DEVELOPMENT SCALING
‣ MORE DEPLOYMENT AND SCALING INDEPENDENCE
‣ STILL MANY COMPONENTS IN THE SAME TIER
‣ MORE COMPLEX DEPLOYMENT
‣ TESTING IS MORE DIFFICULT
‣ NETWORK SLOWS DOWN SYSTEM INTERACTIONS
12. HOW DOES IT LOOK LIKE?_
T
I
E
R
MESSAGING ADAPTER
DIALOG SYSTEM
INTEGRATION
PUBLIC API
ADMIN
CMS
T
I
E
R
T
I
E
R
T
I
E
R
INTEGRATION
INTEGRATION
MESSAGING ADAPTER
POST-NLP
USER SYSTEM MULTILANGUAGE
MESSAGES
A
P
I
DATABASEOTHER SERVICES AI SERVICES
TRACKING SYSTEM
BUSINESS INTEL
15. BENEFITS_
‣ EACH COMPONENT CAN BE A RELATIVELY SMALL MICROSERVICE
‣ COMPONENT INDEPENDENT DEPLOY
‣ EASIER TO SCALE DEVELOPMENT
‣ IMPROVED FAULT ISOLATION
‣ TECHNOLOGY STACK FREEDOM
‣ MODULARITY IS INHERENT TO THE ARCHITECTURE
16. DRAWBACKS_
‣ HIGH DEPLOYMENT COMPLEXITY
‣ HIGH INFRASTRUCTURE NEEDS
‣ INTER-COMMUNICATION MECANISM NEEDED
‣ IDES ARE NOT BUILT FOR MICROSERVICES
‣ NETWORK SLOWS DOWN SYSTEM INTERACTIONS
‣ INTEGRATION TESTING IS MORE DIFFICULT
17. DESIGN_
‣ WHICH IS MY STARTING POINT?
‣ IDEALLY MODULAR COMPONENTS
‣ IDENTIFY BOUNDED CONTEXTS
‣ DOES IT NEED DATA PERSISTANCE?
‣ WHICH ARE ITS DEPENDENCIES:
‣ OTHER MICROSERVICES (PROTECTION/COMMUNICATION/MONITORING)
‣ EXTERNAL SERVICES (PROTECTION)
‣ DEFINE PHASES
‣ BREAK THE CORE
‣ DECREASING COMPONENTS SIZE
19. DIALOG SYSTEM, INTENTS AND ACTIONS_
‣ DIALOG SYSTEM IS THE MOST IMPORTANT COMPONENT
‣ IT USES BOUNDED CONTEXTS
‣ INTENTS: ENTITIES PARSED FROM USER’S MESSAGE FOR A NLP SERVICE
‣ ACTIONS: CROSS-COMPONENT’S VERBS TRIGGERED BY MESSAGES OR FLOW
ELECTIONS WITHIN A CONVERSATION
‣ INTENTS CAN MATCH ACTIONS WITH 1-TO-1, N-TO-1 AND EVEN N-TO-N
RELATIONS, WHERE MULTIPLE INTENTS COMBINATION IS CHALLENGE
‣ RECOMMENDED IMPLEMENTATION: FP, Functions
20. TESTING, LOGGING AND MONITORING_
‣ UNIT TESTING
‣ FINE-GRAINED LOGGING
‣ MICROSECS TIME TRACKING
‣ UPSTREAM TRACKING
‣ DOWNSTREAM TRACKING
‣ MONITORING
‣ HEALTH CHECKING
‣ SCALING
‣ GUI ADMIN
23. WHAT IS SENECA?_
‣ IT IS A NODEJS TOOLKIT TO DEVELOP MICROSERVICES SYSTEMS
‣ IT OFFERS THREE CORE FEATURES:
‣ PATTERN MATCHING
‣ UNIQUE PATTERNS
‣ TRANSPORT INDEPENDENCE
‣ HTTP, TCP, AMQP, REDIS, etc
‣ COMPONENTIZATION
24. PATTERN MATCHING_
‣ CAN BE USED WITHOUT SERVICE DISCOVERY (CONSUL, ZOOKEEPER, ETC)
‣ IT IS BASED ON ASYNCHRONOUS MESSAGING OF JSON OBJECTS
‣ ACTIONS ARE DEFINED BY A PATTERN AND A CALLBACK:
‣ PATTERN like ‘role:math,cmd:sum’
‣ CALLBACK gets message and executes a reply
25. PATTERN MATCHING_
‣ EXECUTIONS SEND A MESSAGE AND RECEIVE A RESPONSE
seneca.act({role: 'math', cmd: 'sum', left: 1, right: 2}, function (err,
result) {
if (err) return console.error(err)
‣ MORE SPECIFIC PATTERN PREVAILS
‣ ACTIONS CAN EXECUTE ANOTHER ACTION FOR CODE RE-USE
‣ ACTIONS CAN BE ENHANCED BY OVERRIDE
26. PLUGINS_
‣ FUNCTION THAT CONTAINS A SET OF RELATED ACTIONS
‣ IT HAS AN INIT FUNCTION THAT IS CALLED SYNCHRONOUSLY
‣ EACH PLUGIN IS DEFINED IN A MODULE
‣ PLUGINS ARE TRANSPORT-AGNOSTIC
‣ YOU LOAD A PLUGIN WITH .USE
28. MICROSERVICES_
‣ YOU RUN A MICROSERVICE IN ITS OWN PROCESS WITH .LISTEN
‣ YOU DEFINE:
‣ ITS MESSAGING TRANSPORT (HTTP - HOST, PORT… -, TCP, ETC)
‣ ITS SPECIFIC PATTERN MATCHING FOR PATTERNS (PIN)
‣ YOU INVOKE A MICROSERVICE WITH .CLIENT
‣ ALL EXECUTIONS MATCHING ITS PIN WILL BE EXECUTED REMOTELY
30. EXPOSING MICROSERVICES THROUGH WEB SERVER_
‣ YOU USE AN ADAPTER, FOR EXAMPLE, FOR EXPRESS
‣ IN THE PLUGIN INIT YOU DEFINE ROUTES WITH:
‣ PREFIX, like “/API”
‣ PIN, like ‘role:api,path:*’ (you only expose that matching actions)
‣ MAP, list of paths, like “calculate: { GET:true, suffix:'/:operation' }”
‣ MATCHING ACTION CAN EXECUTE OTHER INTERNAL ACTIONS
‣ FINAL ENDPOINT EXAMPLE “/api/calculate/:operation"
33. DATA STORAGE_
‣ YOU CAN USE ANY PERSISTENCE YOU LIKE
‣ BUT YOU CAN DECIDE LATER
‣ USE PATTERN MATCHING AS ORM WITH SENECA-ENTITY:
‣ LOAD: load an entity by identifier
‣ SAVE: create or update (if you provide an identifier) an entity
‣ LIST: list entities matching a simple query
‣ REMOVE: delete an entity by identifier
‣ FINALLY USE A PLUGIN TO IMPLEMENT THIS ACTIONS
34. GENERAL TIPS_
‣ ONLY IF YOU MASTER THE DOMAIN
‣ DON’T MIGRATE A MONOLITH TO MICROSERVICES AT ONCE
‣ EACH PARTITION IS A BUSINESS CAPABILITY
‣ AUTONOMY OVER COORDINATION, MINIMIZE DEPENDENCIES
‣ NOT SUITABLE FOR SMALL APPLICATIONS OR PLATFORMS
‣ BE READY TO DEAL WITH INFRASTRUCTURE COMPLEXITY
