March 2019 YOUR MICRO-SERVICES

RicMarch 2019HOW CONTAINER ORCHESTRATIONCAN STRENGTHENYOUR MICRO-SERVICESTHE APPROACH OF KUBERNETESRiccardo Poggi

RicHOW CONTAINER ORCHESTRATIONCAN STRENGTHENYOUR MICRO-SERVICESMarch 2019THE APPROACH OF KUBERNETESRiccardo Poggi1MICRO-SERVICESARCHITECTUREmarch 20192CONTAINERISEDMICRO-SERVICESRiccardo Poggi - iCSC 20193CONTAINERORCHESTRATION2

RicHOW CONTAINER ORCHESTRATIONCAN STRENGTHENYOUR MICRO-SERVICESMarch 2019THE APPROACH OF KUBERNETESRiccardo Poggi1MICRO-SERVICESARCHITECTUREmarch 20192CONTAINERISEDMICRO-SERVICESRiccardo Poggi - iCSC 20193CONTAINERORCHESTRATION3

MONOLITH APPLICATIONAPPLICATIONUSER INTERFACE Key aspects–Single code-base–Single build system–Single executablemarch ORYDATABASERiccardo Poggi - iCSC 20194

MICRO-SERVICESMICRO-SERVICESUSER INTERFACESHIPMENTPOSTORDERGETDATABASE INVENTORYKey aspects–Loosely coupled–Independently deployable–API service communicationmarch 2019ACCOUNTDATABASERiccardo Poggi - iCSC 2019GETDATABASE5

MICRO-SERVICESMICRO-SERVICESUSER INTERFACESHIPMENTPOSTORDERGETDATABASE INVENTORYKey aspects–Loosely coupled–Independently deployable–API service communicationmarch 2019ACCOUNTDATABASERiccardo Poggi - iCSC 2019GETDATABASE6

FROM SOA TO MICRO-SERVICESCLOUD SERVICECONSUMERC#USER INTERFACEJavaENTERPRISE SERVICE BUSC ORDERSERVICEUSER INTERFACESHIPMENTJavamarch TDATABASEPOSTDATABASEDATABASERiccardo Poggi - iCSC 2019GETDATABASE7

MICRO-SERVICES ARCHITECTURE march 2019BENEFITS CHALLENGES–Highly scalable–Building–Resilient–Testing–Easy to deploy–Deployment–Accessible–Logging–More open–Monitoring–ConnectivityRiccardo Poggi - iCSC 20198

UNEXPECTED FAILUREwith“ Dealingunexpected failuresis one of the hardestproblems to solveespecially in adistributed systemmarch 2019”Riccardo Poggi - iCSC 20199

FAULT-TOLERANCE Fault-tolerance– USER INTERFACESystem able to continue properoperation in the event of failure ofone or more of its componentsResilienceSHIPMENTGraceful degradation–The ability of maintainingfunctionality when portions of asystem break downORDERGETDATABASEINVENTORYACCOUNTDATABASEmarch 2019POSTRiccardo Poggi - iCSC 2019GETDATABASE10

FAULT-TOLERANCE Fault-tolerance– USER INTERFACESystem able to continue properoperation in the event of failure ofone or more of its componentsResilienceSHIPMENTGraceful degradation–The ability of maintainingfunctionality when portions of asystem break downORDERGETDATABASEINVENTORYACCOUNTDATABASEmarch 2019POSTRiccardo Poggi - iCSC 2019GETDATABASE11

HIGH-AVAILABILITY Redundancy–Eliminate single points of failure–Failure of a component does notmean failure of the entire systemReliable crossover– Not to have crossover be a singlepoint of failureMonitoring–Detection of failures as they occur–A user may never see a failure,but the maintenance activity mustUSER ATABASEmarch 2019POSTRiccardo Poggi - iCSC 2019GETDATABASE12

HIGH-AVAILABILITY Redundancy–Eliminate single points of failure–Failure of a component does notmean failure of the entire systemReliable crossover– Not to have crossover be a singlepoint of failureMonitoring–Detection of failures as they occur–A user may never see a failure,but the maintenance activity mustUSER ATABASEmarch 2019POSTRiccardo Poggi - iCSC 2019GETDBreplicationDB13

FAIL-OVER POLICY Fail-over policy–Failure as an unrecoverable criticalissue–Implementing the behaviour a servicefollows in case of its own failureLast action before failing–Does the service holds important datawhich needs to be saved?–Does the service has a configurationor status which needs to be saved?SIGKILLSIGTERMTermination–“Failure” can also be externallyinduced–Graceful kill (close)march 2019Riccardo Poggi - iCSC 201914

Requirement as a function of time– Resource allocation and server instantiationScalability–Increasing the capacity–The available resources match the currentand future usage plans–Scaling up: increasing the ability of anindividual server–Scale out: adding multiple serversREQUIREMENTSCALABILITY & ELASTICITYSCALABILITYResource allocationElasticity–Increasing or reducing the capacity basedon the load–The available resources match the currentdemands as closely as possiblemarch 2019Riccardo Poggi - iCSC 2019TIME15

Requirement as a function of time– Resource allocation and server instantiationScalability–Increasing the capacity–The available resources match the currentand future usage plans–Scaling up: increasing the ability of anindividual server–Scale out: adding multiple serversREQUIREMENTSCALABILITY & ELASTICITYELASTICITYResource allocationElasticity–Increasing or reducing the capacity basedon the load–The available resources match the currentdemands as closely as possiblemarch 2019Riccardo Poggi - iCSC 2019TIME16

CONTINUOUS DELIVERY Independent deployWithout service interruption– USER INTERFACENo downtime!Rebuild and redeploy–only one or a small numberof servicesSHIPMENTPOSTGETDATABASENew Versionmarch iccardo Poggi - iCSC 2019GETDATABASE17

CONTINUOUS DELIVERY Independent deployWithout service interruption– USER INTERFACENo downtime!New VersionRebuild and redeploy–only one or a small numberof NTDATABASEmarch 2019Riccardo Poggi - iCSC 2019GETDATABASE18

STATEFUL VS. STATELESS Stateful–Possess saved data in a database thatthey read from and write to directly–If it shares DB with other micro-servicesless decoupled–When it terminates it has to save itsstate (fail-over policy)SHIPMENTPOSTORDERGETStateless–Handle request and return responses–All necessary information supplied onthe request and can be forgot after theresponse–No permanent data–Nothing to save when it terminatesmarch 2019USER INTERFACEDATABASEINVENTORYACCOUNTDATABASERiccardo Poggi - iCSC 2019GETDATABASE19

RicHOW CONTAINER ORCHESTRATIONCAN STRENGTHENYOUR MICRO-SERVICESMarch 2019THE APPROACH OF KUBERNETESRiccardo Poggi1MICRO-SERVICESARCHITECTUREmarch 20192CONTAINERISEDMICRO-SERVICESRiccardo Poggi - iCSC 20193CONTAINERORCHESTRATION20

CONTAINERVIRTUAL PAPPRUNTIMEAPPRUNTIMEHYPERVISORHOST OPERATING SYSTEMHOST OPERATING SYSTEMVMs have their own OS kernel, while containers share it with the host OSmarch 2019Riccardo Poggi - iCSC 201921

CGROUPS & NAMESPACESCGROUPCpu, memory, I/O, .march 2019NAMESPACESCgroup, IPC, network, mount, PID, User, .Riccardo Poggi - iCSC 201922

CONTAINER RUNTIME Container Runtime–In a OCI/CNI compatibleversion is a daemon process–Creates and executes acontainerTo fully create a container:1.Creates the rootfs filesystem.2.Creates the container Set process namespaces andcgroups3.Connects the container to anetwork4.Starts the user processmarch 2019Riccardo Poggi - iCSC 201923

ENTERS DOCKER The most widely knowncontainer runtime isDockerBut there are alsoothers–rkt, containerd, lxd,singularity, etc.march 2019Riccardo Poggi - iCSC 201924

DOCKER IMAGE Docker images are builtfrom a base imageReference toparent imageBase images are built upusing instructions–Run a command–Add a file or directory–Create an environmentvariable–What process to runwhen launching acontainer from this imagemarch 2019DOCKER CONTAINERwritableIMAGEread-onlyBASE IMAGE : UBUNTUread-onlyHOST KERNELread-onlyADD/COPYRiccardo Poggi - iCSC 201925

DOCKERFILE# DockerfileFROM ubuntu:latestRUN apt-get updateRUN apt-get install -y python python-pipRUN pip install FlaskCOPY . /appCMD python /app/order service.py docker build -t my-image . docker run my-imageORDERmarch 2019Riccardo Poggi - iCSC 201926

CONTAINERISED MICRO-SERVICES Apply containers to microservices architectureUSER INTERFACE–One-to-one map for singleindependent services container–Decoupling inside/outsidecontainerSHIPMENTQuestions still to be solvedDATABASE–ORDERGETTightly coupled processesinside one container?INVENTORY–Everything running on onesingle nodeACCOUNT–Redundancy and scalabilityDATABASEmarch 2019POSTRiccardo Poggi - iCSC 2019GETDATABASE27

CONTAINERISED MICRO-SERVICES Apply containers to microservices architectureUSER INTERFACE–One-to-one map for singleindependent services container–Decoupling inside/outsidecontainerSHIPMENTQuestions still to be solvedDATABASE–ORDERGETTightly coupled processesinside one container?INVENTORY–Everything running on onesingle nodeACCOUNT–Redundancy and scalabilityDATABASEmarch 2019POSTRiccardo Poggi - iCSC 2019GETDATABASE28

CONTAINERISED MICRO-SERVICES Apply containers to microservices architectureUSER INTERFACE–One-to-one map for singleindependent services container–Decoupling inside/outsidecontainerSHIPMENTQuestions still to be solvedDATABASE–NODEORDERGETTightly coupled processesinside one container?INVENTORY–Everything running on onesingle nodeACCOUNT–Redundancy and scalabilityDATABASEmarch 2019POSTRiccardo Poggi - iCSC 2019GETDATABASE29

RicHOW CONTAINER ORCHESTRATIONCAN STRENGTHENYOUR MICRO-SERVICESMarch 2019THE APPROACH OF KUBERNETESRiccardo Poggi1MICRO-SERVICESARCHITECTUREmarch 20192CONTAINERISEDMICRO-SERVICESRiccardo Poggi - iCSC 20193CONTAINERORCHESTRATION30

ORCHESTRATION Orchestration–Automated arrangement–Coordination–ManagementUseful tool for–Service Discovery–Load Balancing–Health checks–Auto-scaling–Zero-downtime deploys–(And much more.)march 2019Riccardo Poggi - iCSC 201931

PLATFORM OVERVIEWUser workloadsAPPSDistributed container managementLocal container managementContainer agnostic infrastructuremarch 2019Riccardo Poggi - iCSC 2019JOBSSERVICESORCHESTRATORCONTAINER RUNTIMEINFRASTRUCTURE32

KUBERNETES Master– Node– The machines thatperform the requestedand assigned tasksDEVOPSkubectlPod– The machine that controlsKubernetes nodesA group of one or morecontainers deployed to asingle DOCKERHOST OSHOSTkubectl–Command lineconfiguration tool forKubernetesmarch 2019Riccardo Poggi - iCSC 201933

POD A Pod is the basic building block ofKubernetes– The smallest and simplest unit“one-container-per-Pod”–Most common Kubernetes use case–Pod as a wrapper around a singlecontainerEncapsulate multiple co-locatedcontainers–Tightly coupled–Need to share resourcesmarch 2019Riccardo Poggi - iCSC 201934

REPLICASET Kubernetes Controller– Changes the system to move itfrom the current to the desired stateReplicaSet–Ensures that a specified number ofpod replicas are running at anygiven timemarch 2019Riccardo Poggi - iCSC 201935

DEPLOYMENT Deployment controller– Declarative update for Pods and ReplicaSetRollout–Ensure max unavailable/surge–e.g. at least 75% are up (25% max unavailable)Roll backmarch 2019Riccardo Poggi - iCSC 201936

SERVICE Service–Abstraction to functionally groupPods–e.g. Front-end Pods, back-end PodsConsistent front for a set of Podsto offer a given servicePossible to scale up and downPodsmarch 2019Riccardo Poggi - iCSC 201937

ORCHESTRATED MICRO-SERVICESSERVICE - SHIPNODE-APODSERVICE - CE - D.NODE-CDBSERVICE - INVNODE-BPODINV.PODINV.NODE-Bmarch 2019Riccardo Poggi - iCSC 201938

SUMMARY OF OUR JOURNEYmarch 2019Riccardo Poggi - iCSC 201939

SUMMARY OF OUR JOURNEYMONOLITHAPPLICATIONmarch 2019Riccardo Poggi - iCSC 201940

SUMMARY OF OUR JOURNEYMONOLITHAPPLICATIONmarch 2019MICRO-SERVICESARCHITECTURERiccardo Poggi - iCSC 201941

SUMMARY OF OUR RECONTAINERmarch 2019Riccardo Poggi - iCSC 201942

SUMMARY OF OUR JOURNEYmarch ONTAINERORCHESTRATIONRiccardo Poggi - iCSC 201943

THE ENDExercise sessionToday @16:00513-1-024 (CERN)Thank You!march 2019Riccardo Poggi - iCSC 201944

ACKNOWLEDGEMENTSMany thanks to all those who helped shaping this lecture and exercises! iCSC Mentors:–Sebastian Lopienski–Enric Tejedor SaavedraCERN IT Support– Ricardo Brito Da RochaBeta tester:–Luca Gardi–Marco Valentemarch 2019Riccardo Poggi - iCSC 201945

how container orchestration can strengthen your micro-services the approach of kubernetes riccardo poggi march 2019 micro-services architecture containerised micro-services container orchestration 1 2 3