Chapter 6:

Microservices
Architecture

CSC4307
What are Microservices?

Small independently deployable services that work

together modelled around a business domain
 Monolithic Architecture

• Server-side
systems based on
single
applications
• Easy to develop,
deploy and
manage
 Challenges of Monoliths

• Large and complex architecture

• Slow development
• Blocks continuous deployment (heroics)
• Inflexible & Support gets more complex
• Bugs & Tech stack becomes outdated
• Difficult to scale up and Unreliable
The 3 dimensions to scaling
From Monoliths to
Microservices
From Monoliths to
Microservices (cont.)
Composite UI application shaped by
back-end microservices
• Microservices are small-scale services
that have a single responsibility.
• They are combined to create
applications.
• They are completely independent with
their own database and UI
management code.

Microservices
9
 Microservices Example

• Consider a system that uses an authentication module that provides the

following features:
• User registration, where users provide information about their
identity, security information, mobile phone number and email.
• Authentication using UID/password.
• Two-factor authentication using code sent to mobile phone.
• User information management e.g. change password or mobile
phone number.
• Reset forgotten password.
• Each of these features could be implemented as a separate service that
uses a central shared database to hold authentication information. 10
Functional
breakdown of
authentication
features

11
Authentication
microservices

12
 What to choose ?

Monoliths Microservices

• New business domain, lack • Needs to scale

of knowledge • You understand business domain
• Proof of Concepts • Big budget/ Ready to invest into
• Lack of qualification infrastructure and CI/CD
• Fast or Throw-away solutions processes
• Low budget • Experienced and highly qualified
team

13
Characteristics of microservices

Self-contained
Do not have external Lightweight
dependencies. They manage their Communicate using lightweight
own data and implement their protocols
own user interface.

Implementation-independent Independently deployable

May be implemented using different Each runs in its own process and
programming languages and different is independently deployable,
technologies in their implementation. using automated systems.

Business-oriented
Should implement business capabilities
and needs, rather than simply provide
a technical service.
14
 • A well-designed microservice should
have high cohesion and low coupling.

• Cohesion
• High cohesion means that all the
parts that are needed to deliver the
Cohesion & component’s functionality are
Coupling included in the component.

• Coupling
• Low coupling means that
components do not have many
relationships with other
components.

15
 How big
should a
microservice
be?

“Rule of
twos”
 Range of functionality that might be
included in a password management
microservice.

Password
management
microservice
example

17
 Support code that is needed in all
microservices.

Microservice
support code
example

18
 Exercises

• Based on the functional breakdown of

the authentication features shown in
this figure, create a corresponding
breakdown for two-factor
authentication.

• Two-factor authentication using code sent

to mobile phone.
 Exercise

• List various feature offered by the payment service then for

each feature create its functional breakdown.

• List possible microservices along with their functionality

and supporting code.
 Solution

• Two-factor authentication • Password recovery using email

functionality • Get user login
• Setup user information • Get user email
• Retrieve user information • Generate temporary
• Generate code password
• Send code • Create temporary login page
• Receive code • Send user email
• Validate code • Validate user
• Reset password
Microservice Architecture

A microservices architecture is an architectural style – a tried

and tested way of implementing a logical software
architecture.
Microservices architecture - key
design questions

23
 • Associate services with business
capabilities
What are the
microservices
that makeup a • Design services so that they only have
system? access to the data that they need

Decomposition
Guidelines • Balance fine-grain functionality and
system performance

• Follow the ‘common closure principle’

24
 Imagine that you are developing a photo
printing service for mobile devices:
• Users can upload photos to your server from
their phone or specify photos from their
Instagram account that they would like to be
printed.
photo printing • Prints can be made at different sizes and on
different media. Users can choose print size
system for and print medium. For example, they may
decide to print a picture onto a mug or a T-
mobile devices shirt.
• The prints or other media are prepared and
then posted to their home.
• They pay for prints either using a payment
service such as Google or Apple Pay or by
registering a credit card with the printing
service provider.

25
Microservices architecture for a photo
printing system

Sits in front of your backend

services. It serves requests
from the client by routing it to
the right backend service.

26
Microservices architecture - key
design questions

27
 • You must establish a standard for
communications that all microservices
should follow.

How should • Should service interaction be

Services synchronous or asynchronous?
communicate
with each other? • Should services communicate directly
or via message broker middleware?

• What protocol should be used for

messages exchanged between
services?

28
Synchronous and
asynchronous
microservice
interaction

29
Direct and
indirect service
communication

30
Examples of
Message
Brokers

31
 • A message protocol is an agreement between
services that sets out how messages between
these services should be structured.

• Protocols can be strictly defined, as in the

Advanced Message Queuing Protocol
(AMQP) that is supported by RabbitMQ and
Messaging other message brokers.
protocols
• The protocol definition sets out what data
must be included in a message and how they
must be organized.

• RESTful services follow the REST architectural

style with the message data represented
using JSON.

32
Microservices architecture - key
design questions

33
How should
data be • Isolate data within each system service
distributed with as little data sharing as possible.
and shared?
• If data sharing is unavoidable, design
Microservice microservices so that most sharing is
data design ‘read-only’, with a minimal number of
services responsible for data updates.

• If services are replicated, include a

mechanism to ensure consistency

34
 • Dependent data inconsistency
• The actions or failures of one service can
cause the data managed by another
service to become inconsistent. use
“compensating transactions”
• Replica inconsistency
Inconsistency
management • There are several replicas of the same
service that are executing concurrently.
These all have their own database copy
and each updates its own copy of the
service data. You need a way of making
these databases ‘eventually consistent’ so
that all replicas are working on the same
data.

35
 • Eventual consistency is a situation where
the system guarantees that the databases
will eventually become consistent.

Eventual
consistency

36
Microservices architecture - key
design questions

37
Orchestration and Choreography

A message broker that supports a

publish and subscribe mechanism.
38
 Authentication workflow example

• Most user sessions involve a series

of interactions in which operations
must be carried out in a specific
order.

• This is called a workflow.

• An authentication workflow for
UID/password authentication
shows the steps involved in
authenticating a user. 39
Microservices architecture - key
design questions

40
 • Internal service failure
Conditions that are detected by the service and
can be reported to the service client in an error
message.
Failure types
in a • External service failure
microservices These failures have an external cause, which
system affects the availability of a service.

• Service performance failure

The performance degradation due to a heavy
load or internal problem within the service.
External service monitoring to detect
performance failures and unresponsive services.

41
 • To report microservice failures use
HTTP status codes, which indicate
whether a request has succeeded.
microservice • Status code 200 means the request
failures has been successful,
Reporting • Codes from 300 to 500 indicate
service failure.
• 401 Unauthorized
• 404 Not Found
Timeouts and circuit breakers

• A timeout is a counter that is associated

with the service requests and starts
running when the request is made. Once
the counter reaches some predefined
value the calling service assumes that the
service request has failed and acts
accordingly.

• Circuit breaker: Immediately denies

access to a failed service without the
delays associated with timeouts.

43
Using a circuit breaker to cope with
service failure

44
 RESTful services

The REST (REpresentational State Transfer) architectural style is

based on the idea of transferring representations of digital
resources from a server to a client.
The website is just a framework of templates for the application. It
provides the physical header or the sidebars, the main content
area, and the skeleton for posts to be displayed, but no actual
content.
When you visit the site, this entire framework is downloaded and
starts running in your browser and it sends automated requests to the
REST API, for that service.
 https://developer.mozilla.org/en-US/docs/Glossary/REST

REST Definition
 USE HTTP VERBS STATELESS SERVICES
RESTful
service
principles

URI ADDRESSABLE USE XML OR JSON

49
 • Create: Implemented using HTTP POST,
which creates the resource with the given
URI.

• Read: Implemented using HTTP GET,

RESTful which reads the resource and returns its
value.
service
operations
• Update: Implemented using HTTP PUT,
which modifies an existing resource.

• Delete: Implemented using HTTP DELETE,

which makes the resource inaccessible
using the specified URI. 50
HTTP
request
and
response
processing

51
HTTP request and response
message organization

A tool to see REST API in action:

https://reqres.in

52
 • Accept specifies the content-types that
can be processed by the requesting
service and that are therefore acceptable
in the service response. Commonly used
types are text/plain and text/json.

Header • Content-Type specifies the content-type

Important of the request or response body. For
Elements example, text/json specifies that the
request body includes structured JSON
text.

• Content-Length specifies the length of the

text in the response body. If this is zero, it
means there is no text in the
request/response body.
 Road information system
• Imagine a system that maintains information about incidents, such as
traffic delays, roadworks and accidents on a national road network. This
system can be accessed via a browser using the URL:
• https://trafficinfo.net/incidents/

• Users can query the system to discover incidents on the roads on which
they are planning to travel.
• When implemented as a RESTful web service, you need to design the
resource structure so that incidents are organized hierarchically.
• For example, incidents may be recorded according to the road
identifier (e.g. A90), the location (e.g. stonehaven), the carriageway
direction (e.g. north) and an incident number (e.g. 1). Therefore,
each incident can be accessed using its URI:
• https://trafficinfo.net/incidents/A90/stonehaven/north/1
54
 • Incident ID: A90N17061714391
• Date: 17 June 2017
• Time reported: 1439
Incident
• Severity: Significant
description • Description: Broken-down bus on north
carriageway. One lane closed. Expect
delays of up to 30 minutes

55
 • Retrieve
• Returns information about a reported
incident or incidents. Accessed using
the GET verb.
• Add
• Adds information about a new
incident. Accessed using the POST
Service verb.
operations • Update
• Updates the information about a
reported incident. Accessed using the
PUT verb.
• Delete
• Deletes an incident. The DELETE verb
is used when an incident has been
cleared.

56
 Practice

Consider the Upload service for photographs

to be printed as shown in this figure. Suggest
how this might be implemented and design a
RESTful interface for this service, explaining
the function of each of the HTTP verbs. For
each operation, identify its input and output.
 • When a system is composed of multiple
microservices, deployment of the system is more
complex than for monolithic systems.

Service
deployment

58
 • Continuous deployment means that as soon
as a change to a service has been made and
validated, the modified service is redeployed.

Service
deployment

59
 • CD depends on automation → when a change is
committed, a series of automated tests is
triggered.→ test passes, software automatically
packaged and deployed.

Deployment
automation

60
A continuous deployment
pipeline

61
Versioned services

62
Topic presentations
1. Define and Describe Orchestration list all existing orchestration tools and
provide a complete description of Kubernetes.
2. What is Advanced Message Queuing Protocol (AMQP) and how it is used and
supported by RabbitMQ ?
3. Explain what is description and discovery of RESTful services and how it is
implemented?
4. Docker uses a technology called namespaces describe what is it and what it is
used for?
5. Describe and identify all CI/CD pipeline tools provided by the following cloud
service provider: Google
6. Describe and identify all CI/CD pipeline tools provided by the following cloud
service provider Amazon
7. Describe and identify all CI/CD pipeline tools provided by the following cloud
service provider IBM
8. Describe and identify all CI/CD pipeline tools provided by the following cloud
service provider Alibaba
9. Describe and identify all CI/CD pipeline tools provided by the following cloud
service provider Microsoft Azure
10. Describe and identify all CI/CD pipeline tools provided by the following cloud
service provider Heroku
11. Define and explain authentication and authorization and how they differ?
Topic presentations (cont.)
1. Describe and identify all CI/CD pipeline tools provided by the following cloud
service provider Oracle Cloud
2. Describe and identify all CI/CD pipeline tools provided by the following cloud
service provider RedHat
3. What is refactoring and why is it useful, explain with example?
4. Describe various types of software failures and how can we deals/prevent
them?
5. Defines and describe serverless and microservices and how they are different?
6. Explain what are design patterns and why using them in your code contributes
to fault avoidance.
7. Identify and describe the main types of threat that have to be considered when
planning how to secure a software product against cyberattacks.
8. Define Conway law and describe how can it applies to software development?
9. Define and describe Version control systems and source code management and
what is the difference between them?
10. Describe Gitlab and GitHub and Bitbucket and What is difference between
them?
11. What is the difference between symmetric and asymmetric encryption? Why
do we need both encryption methods?