Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Microservices Architecture For Conversational Intelligence Platform

1.232 visualizaciones

Publicado el

A journey from Monolithic Platforms to Microservices Architecture in the context of Conversational Intelligence Platform

Publicado en: Software
  • Sé el primero en comentar

Microservices Architecture For Conversational Intelligence Platform

  1. 1. MICROSERVICES ARCHITECTURE FOR CONVERSATIONAL INTELLIGENCE PLATFORM_
  2. 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.
  3. 3. CONVERSATIONAL INTELLIGENCE PLATFORM + BASIC STRUCTURE
  4. 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
  5. 5. THE KRAKEN: MONOLITH ARCHITECTURE + THE PROBLEM
  6. 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. 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. 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
  9. 9. THE WHALES: SPLITTED ARCHITECTURE + THE EVOLUTION
  10. 10. 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
  11. 11. 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
  12. 12. THE DOLPHINS: MICROSERVICES ARCHITECTURE + THE SOLUTION
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. BOUNDED CONTEXTS AND OPERATIONS_ ‣ OPERATIONS ARE BASIC COMMANDS WITHIN A BOUNDED CONTEXT ‣ BOTS: Create, Get, Modify, Delete ‣ USERS: Create, Get, Modify, Delete, Login, External login, etc ‣ MESSAGES: Create, Get, Delete ‣ SEARCH: Search services, search categories, search detail, etc ‣ BOOKINGS: Create, Get detail, Get list, Modify, Delete ‣ NOTIFICATIONS: Push, schedule ‣ STATISTICS: Create, Get, Delete ‣ RECOMMENDED IMPLEMENTATION: OOP, Classes
  17. 17. 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
  18. 18. TESTING, LOGGING AND MONITORING_ ‣ UNIT TESTING ‣ FINE-GRAINED LOGGING ‣ MICROSECS TIME TRACKING ‣ UPSTREAM TRACKING ‣ DOWNSTREAM TRACKING ‣ MONITORING ‣ HEALTH CHECKING ‣ SCALING ‣ GUI ADMIN
  19. 19. NODEJS MICROSERVICES WITH SENECA + THE IMPLEMENTATION
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. PLUGIN EXAMPLE_
  25. 25. 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
  26. 26. MICROSERVICE EXAMPLE_ LISTENER CLIENT
  27. 27. 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"
  28. 28. MICROSERVICES WEB SERVER EXAMPLE_
  29. 29. MICROSERVICES WEB SERVER EXAMPLE_ /api/calculate/:operation
  30. 30. 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
  31. 31. 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
  32. 32. THANK YOU

×