Introduction to Microservices

1. Microservices
TECH9810 - System Architectures

2. Microservices
● Microservices are small-scale, stateless, services
that have a single responsibility. They are
combined to create applications.
● They are completely independent with their own
database and UI management code.

3. Microservices
● Software products that use micro services have a
microservices architecture.
● If you need to create cloud-based software
products that are adaptable, scaleable and
resilient then design them around a microservices
architecture.

4. Microservices (Example)
● Let’s look at an example:
● TU Dublin registration, where users provide
information about their identity, security
information, mobile phone number and email
address.

5. Microservices (Example)
● 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.

6. Microservices (Example)
● Each of these features could be implemented as
a separate service that uses a central shared
database to hold authentication information.

7. Microservices (Example)
● However, these features are too large to be
microservices. To identify the microservices that
might be used in the authentication system, you
need to break down the coarse-grain features into
more detailed functions.

8. Microservices (Example)

9. Microservices Characteristics

10. Microservices Characteristics
● Self-Contained
● Microservices do not have external dependencies.
They manage their own data and implement their own
user interface.

11. Microservices Characteristics
● Lightweight
● Microservices communicate using lightweight
protocols, so that service communication overheads
are low.

12. Microservices Characteristics
● Implementation Independent
● Microservices may be implemented using different
programming languages and may use different
technologies (e.g., different types of database) in their
implementation.

13. Microservices Characteristics
● Independently Deployable
● Each microservice runs in its own process and is
independently deployable, using automated systems.

14. Microservices Characteristics
● Business-oriented
● Microservices should implement business capabilities
and needs, rather than simply provide a technical
service.

15. Microservices Guidelines

16. Microservices Guidelines
● Balance fine-grain functionality and system
performance
○ Single-function services mean that changes are limited
to fewer services but require service communications
to implement user functionality. This slows down a
system because of the need for each service to bundle
and unbundle messages sent from other services.

17. Microservices Guidelines
● Follow the ‘common closure principle’
○ Elements of a system that are likely to be
changed at the same time should be located
within the same service. Most new and
changed requirements should therefore only
affect a single service.

18. Microservices Guidelines
● Associate services with business capabilities
○ A business capability is a discrete area of
business functionality that is the responsibility
of an individual or a group. You should identify
the services that are required to support each
business capability.

19. Microservices Guidelines
● Design services so that they only have access to
the data that they need
○ If there is an overlap between the data used by
different services, you need a mechanism to
propagate data changes to all services using
the same data.

20. The Good, the Bad, and
the Interesting of
Microservices

21. THE GOOD

22. Microservices: Benefits
● Self-Contained
● Microservices are self-contained and run
in separate processes.
22

23. Microservices: Benefits
● Independence
● In cloud-based systems, each
microservice may be deployed in its own
container. This means a microservice
can be stopped and restarted without
affecting other parts of the system.
23

24. Microservices: Benefits
● Scalable
● If the demand on a service increases,
service replicas can be quickly created
and deployed. These do not require a
more powerful server so ‘scaling-out’ is,
typically, cheaper than ‘scaling up’.
24

25. Microservices: Benefits
● Non-monolithic
● It is possible to change or upgrade each
service individually rather than
upgrading in the entire application.
25

26. Microservices: Benefits
● Organic Development
● Microservices allows us to develop an
application which is organic (an
application which latterly upgrades by
adding more functions or modules) in
nature.
26

27. THE BAD

28. Microservices: Weaknesses
● Complexity
● Microservices has all the associated
complexities of the distributed system.
28

29. Microservices: Weaknesses
● Communication Issues
● There is a higher chance of failure
during communication between different
services.
29

30. Microservices: Weaknesses
● Management
● Difficult to manage a large number of
services.
30

31. Microservices: Weaknesses
● Network Issues
● The developer needs to solve the
problem, such as network latency and
load balancing.
31

32. Microservices: Weaknesses
● Distributed Testing
● Complex testing over a distributed
environment.
32

33. THE INTERESTING

34. Microservices: Interesting
● How small is too small?
● It's received wisdom that if you are an enterprise, then
microservices means breaking up your large, monolithic
applications into smaller, discrete functions and technical
services. How small? A microservice should have been
architected to focus on doing one task, and doing it well.
How long would it take to re-implement if you tore it
down? A few days or weeks? If the idea of starting again
scares you, then your microservice is too big.
34

35. Microservices: Interesting
● It’s a distributed architecture!
● Microservices are a distributed architecture and, as such,
must be able to communicate over a larger area—across
data centers, servers, clusters, and meshes. They must
run across networks of varying quality and across
different hardware. This will inevitably mean challenges
in terms of performance, availability, concurrence,
latency, and reliability.
35

36. Microservices: Interesting
● “Bounded Context”
● Breaking up monolithic applications into smaller sets of
services will require communications between those
services to operate in a federated way. This will breed
increased network traffic and necessitate more detailed
management. You can reduce communications and
complexity by grouping services around a problem
domain.
36

37. Microservices: Interesting
● Autonomy
● Microservices should be architected to be autonomous,
able to operate and be maintained without relying on
other microservices. If they can operate independently of
each other, they will neither be derailed by problems or
performance issues in another microservice nor act as a
point of failure. All this adds up to performance,
scalability, and elasticity.
37