Introduction to Micro-Services

Not your usual introduction to micro-services.

Diving into a checklist of things/tasks you need to
consider before you introduce micr-services in your organization.

Transcript

1. INTRO TO MICRO-SERVICES NOT YOUR USUAL
2. @KensoDev avi.io AVI (T)ZUREL 㮡ᔰ
3. FAIR WARNING
4. I AM VERY PASSIONATE ABOUT MICRO-SERVICES
5. MICRO-SERVICES **ARE** THE FUTURE
6. IN COMPUTING, MICROSERVICES IS A SOFTWARE ARCHITECTURE STYLE IN WHICH COMPLEX APPLICATIONS ARE COMPOSED OF SMALL, INDEPENDENT PROCESSES COMMUNICATING WITH EACH OTHER USING LANGUAGE-AGNOSTIC APIS.[1] THESE SERVICES ARE SMALL, HIGHLY DECOUPLED AND FOCUS ON DOING A SMALL TASK,[2][3] FACILITATING A MODULAR APPROACH TO SYSTEM-BUILDING.[4] Wikipedia DEFINITION OF MICRO-SERVICES
7. SMART PEOPLE ▸ Sam Newman - “Building Micro-Services” ▸ Adrian Cockcroft - Netflix (Just read every thing this man said) ▸ Bounded Context ▸ Martin Fowler - blog
8. SCALING AND EXPANDING (THROUGH MESSAGING) (LESS) SMART PEOPLE
9. RE::INVENT 2014 / 2015 AWS
10. HOW WE ENDED UP WITH MICROSERVICES @PCALCADO
11. MICRO-SERVICES ARE GOING VIRAL GOOGLE TRENDS
12. MICRO-SERVICES VS SOA ROUND 12 BY A SPLIT DECISION
13. WHAT HAPPENED BEFORE ~2014?
14. GETTING RID OF “THE USUAL” ▸ Amazon ▸ API or fired ▸ Netflix ▸ Every open source solution you can think of ▸ Soundcloud ▸ Thought leaders ▸ Google ▸ Unimaginable scale
15. THIS ALL SAYS NOTHING ABOUT YOU REALLY (TRUST ME, I’M AN ENGINEER)
16. DIVING IN
19. FIX THAT!
20. DO YOU NEED TO?
21. COST OF CHANGE ▸ Development coordination vs Development time ▸ Component imbalance ▸ Technology decay ▸ Upgrades
22. I’M SURE YOU WANT TO
23. MONITORING
24. MONITORING SYSTEMS NEED TO BE MORE AVAILABLE AND SCALABLE THAN THE SYSTEMS (AND SERVICES) BEING MONITORED Adrian Cockcroft
25. MONITORING ▸ Machine CPU/Memory ▸ Service up/down ▸ Service messages sent/received ▸ Data frequency (How many X do we get a minute normally vs what is the threshold for being down)
26. LOGGING
27. LOGGING ACCESS LOGS / MESSAGE LOGS ▸ Nginx in front of ALL THE THINGS ▸ Make sure you log the X-Request-Id of the source in all of the following interactions ▸ Logging SQL with /* service_name.filename.method_name /* in order to make sure which service is making which SQL calls ▸ Composing all logs to a central location to make sure you have the pipeline in place. ▸ Logging of messages received in order to follow faults: Service X sent the message, Service Y got it but failed to act on it etc…
28. SERVIES COMMUNICATION
29. HTTP
31. WHAT ABOUT THE CLIENT?
32. MESSAGING
34. DATA STORE
36. DATA STORE
37. CENTRAL DATABASE
38. DATABASE PER CONTEXT
39. DISCOVERY
40. SERVICE DISCOVERY WHERE ARE YOUR SERVICES? SERVICE DISCOVERY IS A KEY COMPONENT OF MOST DISTRIBUTED SYSTEMS AND SERVICE ORIENTED ARCHITECTURES. THE PROBLEM SEEMS SIMPLE AT FIRST: HOW DO CLIENTS DETERMINE THE IP AND PORT FOR A SERVICE THAT EXIST ON MULTIPLE HOSTS? OPEN-SOURCE SERVICE DISCOVERY · - JASON WILDER'S BLOG
41. HARDWARE UTILIZATION
42. CONFIGURATION MANAGEMENT
43. DEFINITION OF A SERVICE
44. CI
45. DEVELOPMENT ENVIRONMENT
46. CULTURE
47. A CULTURE IS A WAY OF LIFE OF A GROUP OF PEOPLE--THE BEHAVIORS, BELIEFS, VALUES, AND SYMBOLS THAT THEY ACCEPT, GENERALLY WITHOUT THINKING ABOUT THEM, AND THAT ARE PASSED ALONG BY COMMUNICATION AND IMITATION FROM ONE GENERATION TO THE NEXT. tamu.edu CULTURE
48. ALL TEAMS WILL HENCEFORTH EXPOSE THEIR DATA AND FUNCTIONALITY THROUGH SERVICE INTERFACES. TEAMS MUST COMMUNICATE WITH EACH OTHER THROUGH THESE INTERFACES. THERE WILL BE NO OTHER FORM OF INTER-PROCESS COMMUNICATION ALLOWED: NO DIRECT LINKING, NO DIRECT READS OF ANOTHER TEAM’S DATA STORE, NO SHARED-MEMORY MODEL, NO BACK-DOORS WHATSOEVER. THE ONLY COMMUNICATION ALLOWED IS VIA SERVICE INTERFACE CALLS OVER THE NETWORK. IT DOESN’T MATTER WHAT TECHNOLOGY THEY USE. ALL SERVICE INTERFACES, WITHOUT EXCEPTION, MUST BE DESIGNED FROM THE GROUND UP TO BE EXTERNALIZABLE. THAT IS TO SAY, THE TEAM MUST PLAN AND DESIGN TO BE ABLE TO EXPOSE THE INTERFACE TO DEVELOPERS IN THE OUTSIDE WORLD. NO EXCEPTIONS. Anyone who doesn’t do this will be fired. Thank you; have a nice day!
49. UNLESS YOU ARE BEZOS, IT’S DIFFICULT
50. THANK YOU! QUESTIONS?
51. @KensoDev (Twitter, Github) avi.io