WIXLIB

MicroservicesSWE 432, Fall 2017Design and Implementation of Software for the Web

Today LaTozaHow is a being a microservice different than simplybeing RESTful?What are the advantages of a microservicebackend architecture over a monolithicarchitecture?Next time: what additional infrastructure is requiredto realize these advantages?GMU SWE 432 Fall 20172

The “good” old days of backendsHTTP RequestGET /myApplicationEndpoint HTTP/1.1Host: cs.gmu.eduAccept: text/htmlweb serverRuns a programGive me /myApplicationEndpointDoes whatever it wantsWeb ServerApplicationHere’s some text to send backMyApplicationBackendHTTP ResponseHTTP/1.1 200 OKContent-Type: text/html; charset UTF-8 html head .LaTozaGMU SWE 432 Fall 20173

History of Backend Development LaTozaIn the beginning, you wrote whatever you wantedusing whatever language you wanted and whateverframework you wantedThen PHP and ASP Languages “designed” for writing backends Encouraged spaghetti code A lot of the web was built on thisA whole lot of other languages were also springingup in the 90’s Ruby, Python, JSPGMU SWE 432 Fall 20174

Monolothic backendComponent presentationBrowserComponent logicComponent presentationComponent presentationComponent logicComponent logicFront end frameworkHTTPRequestHTTPResponse(JSON)Presentation tierDomain logic tierWeb ServerPersistence tierDatabaseLaTozaGMU SWE 432 Fall 20175

Microservices backendComponent presentationComponent logicBrowserComponent presentationComponent presentationComponent logicComponent logicFront end frameworkHTTPRequestWeb GMU SWE 432 Fall 20176

RESTful APIs LaTozaRecall guidelines for RESTful APIs from Lecture 6:Handling HTTP RequestsSupport scaling Use HTTP actions to support intermediaries (e.g.,caches)Support change Leave anything out of URI that might change Ensure any URI changes are backwards compatibleSupport reuse Design URIs around resources that are expressiveabstractions that support a range of client interactions Resources are nouns; use HTTP actions to signal verbsGMU SWE 432 Fall 20177

Challenges building a RESTful monolithLaTozaGMU SWE 432 Fall 20178

Microservices vs. Monoliths LaTozaAdvantages of microservices over monoliths include Support for scaling Scale vertically rather than horizontally Support for change Support hot deployment of updates Support for reuse Use same web service in multiple apps Swap out internally developed web service forexternally developed web service Support for separate team development Pick boundaries that match team responsibilities Support for failureGMU SWE 432 Fall 20179

Support for scalingOur Cool AppFrontendBackend ServerMod 1Mod 2Mod 3Mod 4Mod 5Mod 6DatabaseLaTozaGMU SWE 432 Fall 201710

Now how do we scale it?Our Cool AppFrontendBackend ServerBackend ServerBackend ServerMod 1Mod 2Mod 1Mod 2Mod 1Mod 2Mod 3Mod 4Mod 3Mod 4Mod 3Mod 4Mod 5Mod 6Mod 5Mod 6Mod 5Mod 6DatabaseWe run multiple copies of the backend, each with each ofthe modulesLaTozaGMU SWE 432 Fall 201711

What's wrong with this picture?Our Cool App LaTozaThis is called the“monolithic” appIf we need 100 servers Each server will have torun EACH moduleWhat if we need more ofsome modules thanothers?FrontendBackend ServerBackend ServerBackend ServerMod 1Mod 2Mod 1Mod 2Mod 1Mod 2Mod 3Mod 4Mod 3Mod 4Mod 3Mod 4Mod 5Mod 6Mod 5Mod 6Mod 5Mod 6GMU SWE 432 Fall 2017Database12

MicroservicesNodeJS, FirebaseMod1TodosOur Cool AppFrontend“Dumb”BackendMod2AccountsJava, tabaseDatabaseDatabaseAJAXMod4 EngineSearchLaTozaGoogle ServiceMod5AnalyticsFacebookMod6 tabaseDatabaseJava, Neo4JC#, SQLServerPython, FirebaseGMU SWE 432 Fall 201713

Support for change: hot swapping LaTozaIn a large organization (e.g., Facebook, Amazon,AirBnb), will constantly have new features beingfinished and rolled out to productionTraditional model: releases Finish next version of software, test, release as aunit once every year or twoWeb enables frequent updates Could update every night or even every hourBut. if updating every hour, really do not wantwebsite to be downGMU SWE 432 Fall 201714

Support for change in a monolithOur Cool AppFrontendBackend ServerBackend ServerBackend ServerMod 1Mod 2Mod 1Mod 2Mod 1Mod 2Mod 3Mod 4Mod 3Mod 4Mod 3Mod 4Mod 5Mod 6Mod 5Mod 6Mod 5Mod 6DatabaseLaTozaGMU SWE 432 Fall 201715

MicroservicesNodeJS, FirebaseMod1TodosOur Cool AppFrontend“Dumb”BackendMod2AccountsJava, tabaseDatabaseDatabaseAJAXMod4 EngineSearchLaTozaGoogle ServiceMod5AnalyticsFacebookMod6 tabaseDatabaseJava, Neo4JC#, SQLServerPython, FirebaseGMU SWE 432 Fall 201716

Support for reuse LaTozaIn a large organization (e.g., Facebook, Amazon, AirBnb),may have many internal products that all depend on asimilar core service (e.g., user account storage, servingstatic assets)Would like to be able to build functionality once, reuse in many place swap out an old implementation for a newimplementation with a new technology orimplementation swap out an internal service for a similar externalserviceGMU SWE 432 Fall 201717

Support for reuse in a monolithOur Cool AppFrontendBackend ServerBackend ServerBackend ServerMod 1Mod 2Mod 1Mod 2Mod 1Mod 2Mod 3Mod 4Mod 3Mod 4Mod 3Mod 4Mod 5Mod 6Mod 5Mod 6Mod 5Mod 6DatabaseLaTozaGMU SWE 432 Fall 201718

MicroservicesNodeJS, FirebaseMod1TodosOur Cool AppFrontend“Dumb”BackendMod2AccountsJava, tabaseDatabaseDatabaseAJAXMod4 EngineSearchLaTozaGoogle ServiceMod5AnalyticsFacebookMod6 tabaseDatabaseJava, Neo4JC#, SQLServerPython, FirebaseGMU SWE 432 Fall 201719

Conway's Law The structure of an organization mirrors the structure of aproduct. Building a car. Have a team for tiresHave a team for drivetrain Have a team for seating Have a team for paint Have a team for . LaToza Could pick a product structure and design team around it. Or could pick a desired team structure and design productaround it.GMU SWE 432 Fall 201720

Organization in a monolithFrontendOrders, shipping, catalogClassic teams:1 team per “tier”BackendOrders, shipping, catalogDatabaseOrders, shipping, catalogLaTozaGMU SWE 432 Fall 201721

Organization around business capabilitiesin microservicesOrdersShippingExample: AmazonTeams can focus on onebusiness taskAnd be responsibledirectly to users“Full Stack”CatalogLaToza“2 pizza teams”GMU SWE 432 Fall 201722

How big is a microservice? LaTozaMetaphor: Building a stereo systemComponents are independently replaceableComponents are independently updatableThis means that they can be also independentlydeveloped, tested, etcComponents can be built as: Library (e.g. module) Service (e.g. web service)GMU SWE 432 Fall 201723

Goals of microservices LaTozaAdd them independentlyUpgrade the independentlyReuse them independentlyDevelop them independently Have ZERO coupling betweenmicroservices, aside from their shared interfaceGMU SWE 432 Fall 201724

Exercise: Design a restaurant review site In groups of 2 or 3, build diagram depicting a set ofmicroservices, their connections, and a list of importantendpoints Requirements Restaurant owners can create restaurant pages, add linksto website, add food keywords, update address andbusiness info LaTozaRestaurant reviewers can post reviews of a restaurant, seereviews they've written, comment on other reviews.All users can search for a restaurant based on its foodkeywords and address.Users have accounts, with profile information and settings.GMU SWE 432 Fall 201725

Design for Failure Each of the many microservices might fail Services might have bugs Services might be slow to respond Entire servers might go downIf I have 60,000 hard disks, 3 fail a dayThe more microservices there are, the higher thelikelihood at least one is currently failing LaToza Key: design every service assuming that at somepoint, everything it depends on might disappear must fail “gracefully” Netflix simulates this constantly with “ChaosMonkey”GMU SWE 432 Fall 201726

Support for failure Goal: Support graceful degradation with servicefailures Design for idempotency Should be able to retry requests withoutintroducing bad dataDesign for data locality Transactions across microservices are hard tomanageDesign for eventual consistency LaTozaGMU SWE 432 Fall 201727

Design for idempotencyLaToza Want to design APIs so that executing an actionmultiple times leads to same resulting state Prefer state changes on existing entity rather thancreating new entitiesGMU SWE 432 Fall 201728

Design for data locality LaTozaIf datastore server fails or is slow, do not wantentire site to go down.Decentralizes implementation decisions.Allows each service to manage data in the way thatmakes the most sense for that serviceAlso performance benefit: caching data locally inmicroservices enables faster responseRule: Services exchange data ONLY through theirexposed APIs - NO shared databasesGMU SWE 432 Fall 201729

ConsistencyNodeJS, FirebaseMod 1Todos LaTozaOne of our rules was “no shareddatabase”But surely some state will besharedUpdates are sent via HTTPrequestNo guarantee that those updatesoccur immediatelyInstead, guarantee that they occureventuallyGoogle ServiceMod 2AccountsJava, MySQLMod 3MailerREST serviceREST serviceREST serviceDatabaseDatabaseDatabaseOur Cool AppFrontend“Dumb”BackendAJAXMod 4Search EngineMod 5AnalyticsMod6FacebookCrawlerREST serviceREST serviceREST serviceDatabaseDatabaseDatabaseJava, Neo4JC#, SQLServerPython, FirebaseCan force some ordering, butthat’s expensiveGMU SWE 432 Fall 201730

Maintaining ConsistencyGoogle ServiceNodeJS, FirebaseMod 1Mod 2TodosJava, MySQLMod 3AccountsMailerREST serviceREST serviceREST serviceDatabaseDatabaseDatabaseOur Cool AppFrontend“Dumb”BackendAJAXMod 4Mod 5Search Engine LaTozaMod 6AnalyticsFacebook CrawlerREST serviceREST serviceREST serviceDatabaseDatabaseDatabaseJava, Neo4JC#, SQLServerPython, FirebaseCore problem: different services may respond to requests at differenttimes. What if a request results in change to resource in one service, butother service has not yet processed corresponding request? May end up with different states in different resources. Logic needs to be written to correctly handle such situations.GMU SWE 432 Fall 201731

Eventual Consistency: ExampleLaTozaGMU SWE 432 Fall 201732

Reading for next time LaTozaFundamentals of DevOps: -with-microservices-part-fourGMU SWE 432 Fall 201733

microservices, their connections, and a list of important endpoints Requirements Restaurant owners can create restaurant pages, add links to website, add food keywords, update address and business info Restaurant reviewers can post reviews of a restauran