MANAGINGMICROSERVICEINFRASTRUCTURE

MurthyMalapaka(MLN)notesfromwhitepapersbyChris

Richardson@NGiNX

MicroservicesarchitecturepaAern•  Eachmicroserviceisamini–applicaDonwithHexagonalarchitecture

–  Businesslogicwithvariousadapters–  RESTAPI

•  SomemicroservicesarewebUI–  Splitintosimplerwebapps

•  Appsdonothavedirectaccesstobackend–  APIgateway

•  Loadbalancing,caching,accesscontrol,APImeteringandmonitoring

•  UIservicesinvoketheotherservicesinordertorenderwebpages•  Servicesmightalsouseasynchronous,messagebasedcommunicaDon,inter-

servicecommunicaDon–  InterprocesscommunicaDon

•  Eachservicehasitsowndatabaseschema–  Loosecoupling

•  Eachservicecanuseatypeofdatabasethatisbestsuitedtoitsneed–  Polygotpersistencearchitecture

•  AtrunDmeeacheachinstanceisoQenacloudVMorDockercontainer

SoAvsMicroservices•  MicroserviceisSOAwithoutthecommercializaDonandperceivedbaggageof

webservicespecificaDon(WS-*)•  Noenterpriseservicebus(ESB)•  Microservice-basedapplicaDonsfavorsimplerlightweightprotocolslikeREST•  Rejectsconceptofcanonicalschema

Benefitsofmicroservices•  Manageablechunksofserviceswitheachonehavingadefinedboundaryinheformof

RPC-ormessage–drivenAPI•  Individualservicesaremuchfactortodevelopandmucheasiertounderstandand

maintain•  Servicedevelopmentcanbeindependentteamsandcanuseindependenttechnologies•  Eachmicroservicecanbedeployedindependently,nocoordinaDonneededfor

deploymentofchangeslocaltotheirservice•  ConDnuesdeploymentmadeverypracDcal•  IsolaDonandparDDoningwithportlevelcontrol•  Servicescanbescaledindependently

–  EC2computeopDmizedservices–  EC2memoryopDmizedservices

Complexitywithmicroservices•  TrulyDistributedatbusinesslogic,UI,DatabaselevelincludingmulDpleAPI

gatewaysinsomecomplexenvironments•  IPCwithmessagingsystemslikeMQorRPC•  CodeneedstobewriAenforparDalfailure•  ParDDoneddatabasearchitecture•  TesDngcomplexwithinter-dependencyofotherservices•  ImplemenDngchangesspanningmulDpleservices•  Deploymentiscomplex

–  Hailohas160differentservicesandNe`lixhas600–  Successfuldeploymentrequiresgreatercontrolofdeploymentmethodsbydevelopersand

ahighlevelofautomaDon•  Management

–  TradiDonaltroubleDcketbasedandmanualapproachestooperaDonscannotscaletothislevelofcomplexity

–  Thereareseveralmovingpartsthatneedtobeconfigured,deployedandmonitored–  Servicediscoverymechanismhastobedifferentthatenablesaservicetodiscoverthe

locaDons(hostsandports)ofanyotherservicesitneedstocommunicatewith

ServicediscoveryandregistraDon•  NottradiDonalstaDcdiscovery•  Clientsidediscovery

–  RegistryawareHTTPclientqueriesaserviceregistry–  Clientthenusesaloadbalancingalgorithmtoselectoneftheavailableserviceinstances

•  Ne`lixOSS,Eureka,Ribbon(IPCclientworkswithEurekatoloadbalance)

•  Serversidediscovery–  Loadbalancerqueriesserviceregistry–  Loadbalancerthenroutesservicerequests–  Serversidediscoveryloadbalancer

•  AWSELB,NGINXPlus,Cabernets,Marathonproxies

•  Serviceregistry–  DatabasecontainingnetworklocaDonsofserviceinstances–  Ne`lixEureka

•  RESTAPIforregistering•  ServiceinstanceregistersusingaPOSTrequest•  every30secondsitshouldrefreshusingaPUTrequest•  RegistraDonisremovedusingaHTTPdeleteoraDmeout

–  Etcd,consul,ApacheZookeeper

•  ServiceregistraDon–  SelfregistraDon

•  Ne`lixOSSEurekaclient

–  ThirdpartyregistraDon•  Registrar(Docker)•  Ne`lixOSSPrana

DistributedDatamanagement•  Complexsinceeverymicroservicehasitsowndatabase

anddatabasetechnology–  Privatetothatmicroservice

•  OnemicroservicecanuseNOSQL,otherElasDcsearch,Neo4j–  MixtureofSQLandNOSQL(Polygotapproach)

•  EventdrivenarchitectureforACIDstyleconsistency–  Microservicepublishesaneventwhensomethingnotablehappens

–  Othermicroservicessubscribetothoseevents•  LinkedlnDatabus•  StreamsmechanisminAWSDynamoDB

–  Eventsourcing

InterprocesscommunicaDon

•  NoEnterpriseserviceBus•  DefiningServiceAPI’s–  InterfacedefiniDonlanguage

OnetoOne Onetomany

Synchronous Request/Response ----

Asynchronous No<fica<onRequest/asyncresponse

Publish/subscribePublish/asyncresponse

Technologypla`orms

Cloudfoundry

Mesos

Cabernets

Appdynamicsmicroservicemonitors

Ne`lixHysDrix

RESTAdapters

ThriQ

AMQPSTOMP

JSON/XML

AvroorProtocolBuffers

RabbitMQ

ApacheAcDveMQApacheKaia

NSQ

Swagger

Ne`lixEureka EtcdApacheZookeeper

Consul

NotablepointsforManagedserviceproviders•  ClearlyverydifferentfromatroubleDcketbasedapproach•  Enterpriseshavestartedthejourney

–  SeveralimplemenDngparDalmicroservicearchitectures•  APIgateways•  Buildingserviceswithadapterapproach•  IPCmechanismandavoidingaBusarchitecture•  Chefwithseveralreleasemanagementsystems

•  AcompletemovementtothisarchitecturelikeindividualWebUI’s,mulDpleAPIgw’s,individualdatabases,DockerimplementaDon,ServiceregistrymethodsarenotimmediatelyconsideredduetoconcernsontheoperaDonsandperformance–  ThisiskindofstoppingthemaAWSlikereleases–  IsthisisanopportunityfortheMSP’stocreateservices

•  Performanceguarantee•  Bimodal,HybridITmanagementduringtransiDon

–  MovingfirsttocloudnaDvemodethenmicroservicemodels–  Newmanagementmodelsneedtobecreated

•  OperaDonalanalyDcs•  RealDmemanagement•  Autonomics,roboDcinnature•  Serviceregistrymanagement