Lecture 11 - Microservices

Microservices
SWE 432, Fall 2017

Design and Implementation of Software for the Web
Today
• How is a being a microservice different than simply
being RESTful?
• What are the advantages of a microservice
backend architecture over a monolithic
architecture?
• Next time: what additional infrastructure is required

to realize these advantages?
LaToza GMU SWE 432 Fall 2017 2

The “good” old days of backends
HTTP Request
GET /myApplicationEndpoint HTTP/1.1
Host: cs.gmu.edu
Accept: text/html
web server
Runs a program
Give me /myApplicationEndpoint
Does whatever it wants My

Web Server
Application
Application
Here’s some text to send back Backend
HTTP Response
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
<html><head>...

History of Backend Development
• In the beginning, you wrote whatever you wanted
using whatever language you wanted and whatever
framework you wanted
• Then… PHP and ASP
• Languages “designed” for writing backends
• Encouraged spaghetti code
• A lot of the web was built on this
• A whole lot of other languages were also springing
up in the 90’s…
• Ruby, Python, JSP

Monolothic backend
Component presentation Component presentation Component presentation
Component logic Component logic Component logic

Browser
Front end framework
HTTP  
HTTP  
Response
Request
(JSON)
Presentation tier
Domain logic tier

Web Server
Persistence tier
Database

Microservices backend
Component presentation Component presentation Component presentation
Component logic Component logic Component logic

Browser
Front end framework
HTTP   HTTP  
HTTP   HTTP   Response
Response
Request Request (JSON)
(JSON)
HTTP   HTTP  
Request Request
HTTP   HTTP  
Microservice Response Microservice Response
Web Servers (JSON) (JSON)
Database

RESTful APIs
• Recall guidelines for RESTful APIs from Lecture 6:
Handling HTTP Requests
• Support 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 compatible
• Support reuse
• Design URIs around resources that are expressive
abstractions that support a range of client interactions
• Resources are nouns; use HTTP actions to signal verbs

Challenges building a RESTful monolith

Microservices vs. Monoliths
• Advantages 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 for
externally developed web service
• Support for separate team development
• Pick boundaries that match team responsibilities
• Support for failure

Support for scaling
Our Cool App
Frontend
Backend Server
Mod 1 Mod 2
Mod 3 Mod 4
Mod 5 Mod 6
Database

Now how do we scale it?
Our Cool App
Frontend
Backend Server Backend Server Backend Server

Mod 1 Mod 2 Mod 1 Mod 2 Mod 1 Mod 2
Database
We run multiple copies of the backend, each with each of

the modules
What's wrong with this picture?
Our Cool App
Frontend
• This is called the

“monolithic” app Mod 1 Mod 2 Mod 1 Mod 2 Mod 1 Mod 2
• If we need 100 servers… Mod 5 Mod 6 Mod 5 Mod 6 Mod 5 Mod 6
• Each server will have to Database
run EACH module

• What if we need more of
some modules than
others?

Microservices
NodeJS, Firebase Google Service Java, MySQL
Todos
Mod 1 Accounts
Mod 2 Mailer
Mod 3
REST REST REST

service service service
Our Cool App
Frontend
Database Database Database
“Dumb”
AJAX
Backend
Mod 4 Engine
Search Analytics
Mod 5 Facebook
Mod 6 Crawler
REST REST REST

Java, Neo4J C#, SQLServer Python, Firebase

Support for change: hot swapping
• In a large organization (e.g., Facebook, Amazon,
AirBnb), will constantly have new features being
finished and rolled out to production
• Traditional model: releases
• Finish next version of software, test, release as a
unit once every year or two
• Web enables frequent updates
• Could update every night or even every hour
• But.... if updating every hour, really do not want

website to be down

Support for change in a monolith
Our Cool App
Frontend

Database

Microservices
Todos
Mod 1 Accounts
Mod 2 Mailer
Mod 3
REST REST REST

Our Cool App
Frontend
“Dumb”
AJAX
Backend
Mod 4 Engine
Search Analytics
Mod 5 Facebook
Mod 6 Crawler
REST REST REST


Support for reuse
• In a large organization (e.g., Facebook, Amazon, AirBnb),
may have many internal products that all depend on a
similar core service (e.g., user account storage, serving
static assets)
• Would like to
• be able to build functionality once, reuse in many place
• swap out an old implementation for a new
implementation with a new technology or
implementation
• swap out an internal service for a similar external
service

Support for reuse in a monolith
Our Cool App
Frontend

Database

Microservices
Todos
Mod 1 Accounts
Mod 2 Mailer
Mod 3
REST REST REST

Our Cool App
Frontend
“Dumb”
AJAX
Backend
Mod 4 Engine
Search Analytics
Mod 5 Facebook
Mod 6 Crawler
REST REST REST


Conway's Law
• The structure of an organization mirrors the structure of a
product.
• Building a car.
• Have a team for tires
• Have a team for drivetrain
• Have a team for seating
• Have a team for paint
• Have a team for ...
• Could pick a product structure and design team around it.

• Or could pick a desired team structure and design product
around it.

Organization in a monolith
Frontend Classic teams:
Orders, shipping, catalog
1 team per “tier”
Backend
Database

Organization around business capabilities
in microservices
Orders Example: Amazon
Teams can focus on one

business task
Shipping And be responsible
directly to users
“Full Stack”
Catalog
“2 pizza teams”

How big is a microservice?
• Metaphor: Building a stereo system
• Components are independently replaceable
• Components are independently updatable
• This means that they can be also independently
developed, tested, etc
• Components can be built as:
• Library (e.g. module)
• Service (e.g. web service)

Goals of microservices
• Add them independently
• Upgrade the independently
• Reuse them independently
• Develop them independently
• ==> Have ZERO coupling between

microservices, aside from their shared interface

Exercise: Design a restaurant review site
• In groups of 2 or 3, build diagram depicting a set of

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 restaurant, see
reviews they've written, comment on other reviews.
• All users can search for a restaurant based on its food
keywords and address.
• Users have accounts, with profile information and settings.

Design for Failure
• Each of the many microservices might fail
• Services might have bugs
• Services might be slow to respond
• Entire servers might go down
• If I have 60,000 hard disks, 3 fail a day
• The more microservices there are, the higher the
likelihood at least one is currently failing
• Key: design every service assuming that at some
point, everything it depends on might disappear -
must fail “gracefully”
• Netflix simulates this constantly with “ChaosMonkey”

Support for failure
• Goal: Support graceful degradation with service
failures
• Design for idempotency

• Should be able to retry requests without
introducing bad data
• Design for data locality
• Transactions across microservices are hard to
manage
• Design for eventual consistency

Design for idempotency
• Want to design APIs so that executing an action
multiple times leads to same resulting state
• Prefer state changes on existing entity rather than

creating new entities

Design for data locality
• If datastore server fails or is slow, do not want
entire site to go down.
• Decentralizes implementation decisions.
• Allows each service to manage data in the way that
makes the most sense for that service
• Also performance benefit: caching data locally in
microservices enables faster response
• Rule: Services exchange data ONLY through their

exposed APIs - NO shared databases

Consistency NodeJS, Firebase Google Service Java, MySQL
Mod 1 Mod 2 Mod 3

Todos Accounts Mailer
One of our rules was “no shared

REST service REST service REST service
• Our Cool App
Frontend
database”
“Dumb”
Backend AJAX
But surely some state will be

Mod 4 Mod 5 Mod 6
Facebook Crawler
• Search Engine
REST service
Analytics
REST service REST service
shared Database Database Database
• Updates are sent via HTTP Java, Neo4J C#, SQLServer Python, Firebase
request
• No guarantee that those updates
occur immediately
• Instead, guarantee that they occur
eventually
• Can force some ordering, but
that’s expensive

Maintaining Consistency
Mod 1 Mod 2 Mod 3

Todos Accounts Mailer
Our Cool App
Frontend
“Dumb”
Backend AJAX
Mod 4 Mod 5 Mod 6

Search Engine Facebook Crawler
Analytics
• Core problem: different services may respond to requests at different

times.
• What if a request results in change to resource in one service, but
other 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.
Eventual Consistency: Example

Reading for next time
• Fundamentals of DevOps:
• https://blogs.oracle.com/developers/getting-
started-with-microservices-part-four

Lecture 11 - Microservices

Uploaded by

Copyright:

Available Formats

Lecture 11 - Microservices

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 11 - Microservices

Uploaded by

Copyright:

Available Formats

What are the advantages of a microservice backend architecture over a monolithic architecture?

What are the advantages of a microservice backend architecture over a monolithic architecture?

What challenges does building a RESTful monolith present?

What challenges does building a RESTful monolith present?

Microservices

SWE 432, Fall 2017

• Next time: what additional infrastructure is required

LaToza GMU SWE 432 Fall 2017 2

Does whatever it wants My

LaToza GMU SWE 432 Fall 2017 3

LaToza GMU SWE 432 Fall 2017 4

Component logic Component logic Component logic

Domain logic tier

LaToza GMU SWE 432 Fall 2017 5

Component logic Component logic Component logic

LaToza GMU SWE 432 Fall 2017 6

LaToza GMU SWE 432 Fall 2017 7

LaToza GMU SWE 432 Fall 2017 8

LaToza GMU SWE 432 Fall 2017 9

LaToza GMU SWE 432 Fall 2017 10

Backend Server Backend Server Backend Server

Mod 3 Mod 4 Mod 3 Mod 4 Mod 3 Mod 4

Mod 5 Mod 6 Mod 5 Mod 6 Mod 5 Mod 6

We run multiple copies of the backend, each with each of

• This is called the

“monolithic” app Mod 1 Mod 2 Mod 1 Mod 2 Mod 1 Mod 2

Mod 3 Mod 4 Mod 3 Mod 4 Mod 3 Mod 4

• If we need 100 servers… Mod 5 Mod 6 Mod 5 Mod 6 Mod 5 Mod 6

• Each server will have to Database

run EACH module

LaToza GMU SWE 432 Fall 2017 12

REST REST REST

REST REST REST

Database Database Database

Java, Neo4J C#, SQLServer Python, Firebase

• But.... if updating every hour, really do not want

LaToza GMU SWE 432 Fall 2017 14

Backend Server Backend Server Backend Server

Mod 3 Mod 4 Mod 3 Mod 4 Mod 3 Mod 4

Mod 5 Mod 6 Mod 5 Mod 6 Mod 5 Mod 6

LaToza GMU SWE 432 Fall 2017 15

REST REST REST

REST REST REST

Database Database Database

Java, Neo4J C#, SQLServer Python, Firebase

LaToza GMU SWE 432 Fall 2017 17

Backend Server Backend Server Backend Server

Mod 3 Mod 4 Mod 3 Mod 4 Mod 3 Mod 4

Mod 5 Mod 6 Mod 5 Mod 6 Mod 5 Mod 6

LaToza GMU SWE 432 Fall 2017 18

REST REST REST

REST REST REST

Database Database Database

Java, Neo4J C#, SQLServer Python, Firebase

• Could pick a product structure and design team around it.

LaToza GMU SWE 432 Fall 2017 20

LaToza GMU SWE 432 Fall 2017 21

Teams can focus on one

LaToza GMU SWE 432 Fall 2017 22