Introduction to Micro-Services

Slide 1

Slide 1 text

INTRO TO MICRO-SERVICES NOT YOUR USUAL

Slide 2

Slide 2 text

@KensoDev avi.io AVI (T)ZUREL 㮡ᔰ

Slide 3

Slide 3 text

FAIR WARNING

Slide 4

Slide 4 text

I AM VERY PASSIONATE ABOUT MICRO-SERVICES

Slide 5

Slide 5 text

MICRO-SERVICES **ARE** THE FUTURE

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

SMART PEOPLE ▸ Sam Newman - “Building Micro-Services” ▸ Adrian Cockcroft - Netﬂix (Just read every thing this man said) ▸ Bounded Context ▸ Martin Fowler - blog

Slide 8

Slide 8 text

SCALING AND EXPANDING (THROUGH MESSAGING) (LESS) SMART PEOPLE

Slide 9

Slide 9 text

RE::INVENT 2014 / 2015 AWS

Slide 10

Slide 10 text

HOW WE ENDED UP WITH MICROSERVICES @PCALCADO

Slide 11

Slide 11 text

MICRO-SERVICES ARE GOING VIRAL GOOGLE TRENDS

Slide 12

Slide 12 text

MICRO-SERVICES VS SOA ROUND 12 BY A SPLIT DECISION

Slide 13

Slide 13 text

WHAT HAPPENED BEFORE ~2014?

Slide 14

Slide 14 text

GETTING RID OF “THE USUAL” ▸ Amazon ▸ API or ﬁred ▸ Netﬂix ▸ Every open source solution you can think of ▸ Soundcloud ▸ Thought leaders ▸ Google ▸ Unimaginable scale

Slide 15

Slide 15 text

THIS ALL SAYS NOTHING ABOUT YOU REALLY (TRUST ME, I’M AN ENGINEER)

Slide 16

Slide 16 text

DIVING IN

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

FIX THAT!

Slide 20

Slide 20 text

DO YOU NEED TO?

Slide 21

Slide 21 text

COST OF CHANGE ▸ Development coordination vs Development time ▸ Component imbalance ▸ Technology decay ▸ Upgrades

Slide 22

Slide 22 text

I’M SURE YOU WANT TO

Slide 23

Slide 23 text

MONITORING

Slide 24

Slide 24 text

MONITORING SYSTEMS NEED TO BE MORE AVAILABLE AND SCALABLE THAN THE SYSTEMS (AND SERVICES) BEING MONITORED Adrian Cockcroft

Slide 25

Slide 25 text

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)

Slide 26

Slide 26 text

LOGGING

Slide 27

Slide 27 text

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.ﬁlename.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…

Slide 28

Slide 28 text

SERVIES COMMUNICATION

Slide 29

Slide 29 text

HTTP

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

WHAT ABOUT THE CLIENT?

Slide 32

Slide 32 text

MESSAGING

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

DATA STORE

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

DATA STORE

Slide 37

Slide 37 text

CENTRAL DATABASE

Slide 38

Slide 38 text

DATABASE PER CONTEXT

Slide 39

Slide 39 text

DISCOVERY

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

HARDWARE UTILIZATION

Slide 42

Slide 42 text

CONFIGURATION MANAGEMENT

Slide 43

Slide 43 text

DEFINITION OF A SERVICE

Slide 44

Slide 44 text

Slide 45

Slide 45 text

DEVELOPMENT ENVIRONMENT

Slide 46

Slide 46 text

CULTURE

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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!