MICROSERVICE

ARCHITECTURE
Goal, benefit, best practices

Andri Santoso, S.Kom., M.Sc.

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya

When Microservices Architecture is done right…
1. You should be able to develop a
microservice in a language of your
choice, release it independently at your
own pace, and scale it independently.

2. Since different teams in an organization

can independently own certain
microservices, time to market should
be faster as there is parallel
development with more reuse.

3. You get better fault isolation, as errors

in one microservice can be contained,
so the rest of the ecosystem would not
be impacted.

Fakultas Ilmu Komputer Universitas Brawijaya

Impact of Microservices
• Cost to maintain improves because smaller/simpler services are easier to evolve and maintain
and because the quality of these services is better
• Productivity improves due to decentralization/decoupling, development teams closely
collaborating with business, and automation
• Quality improves due to simpler code, smaller scope of changes, technical excellence
practices, automation of software delivery and operations, resilient and scalable architecture
• Time to market improves due to decentralized execution and automation of software delivery
• Employee morale improves as people spend more time on meaningful, value-producing work
and from working on small stable teams with a sense of ownership and purpose
• Customer satisfaction improves due to improved quality and improved flow of valuable
features stemming from development teams collaborating closely with business

Fakultas Ilmu Komputer Universitas Brawijaya

BEST
PRACTICES

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya

1. Avoid the Anti-patterns❕
Failures are not due to the microservices architectural model itself. The problems are typically due to
mistakes and compromises made during design and implementation of microservices

Anti-Patterns:
1. Using microservices where the problem doesn’t justify the complexity
2. Attempting to solve the problem with tools
3. Not architecting for scalability
4. Not architecting for resiliency
5. Not encapsulating data
6. Not designing for inter-service communications
• excessive communication between services could be a sign that services were not
decoupled properly

Fakultas Ilmu Komputer Universitas Brawijaya

More anti-patterns
• Making microservices too big
• make sure to scope the services well.
• Making microservices too small
• make sure the cohesion is maintained
• Not automating software delivery, testing, operations
• Not automating resource provisioning (VMs, containers, etc.)
• Not addressing quality at the development stage (Unit testing, TDD, BDD)
• Keeping development teams and business separated
• Not managing security

Fakultas Ilmu Komputer Universitas Brawijaya

2. Single Responsibility Principle
• Microservice should have only single responsibility, like a class in a code
• It should have only a single reason to change
• Bad Practice: building bloated services which are subject to change for
more than one business context
Let’s say you are building microservices for ordering a pizza.
You can consider building the following components based on
the functionality each supports like InventoryService,
OrderService, PaymentsService, UserProfileService,
DeliveryNotificationService, etc. InventoryService would only
have APIs that fetch or update the inventory of pizza types or
toppings, and likewise others would carry the APIs for their
functionality.

Fakultas Ilmu Komputer Universitas Brawijaya

3. Database per Service
• Don’t use a
monolithic database
that all your
microservices share
• Any other
microservice that
needs access to that
data would only
access it through
the APIs that the
microservice with
write access has
exposed

Fakultas Ilmu Komputer Universitas Brawijaya

4. Use asynchronous communication
Make calls to your dependencies
asynchronously
Let’s say you have a Service A that calls
Service B. Once Service B returns a
response, Service A returns success to the
caller. If the caller is not interested in
Service B’s output, then Service A can
asynchronously invoke Service B and
instantly respond with a success to the
caller.
Fakultas Ilmu Komputer Universitas Brawijaya
Use events for communicating
between microservices
For example, in the pizza order system,
sending a notification to the customer once
their order is captured, or status messages
as the order gets fulfilled and delivered, can
happen using asynchronous
communication. A notification service can
listen to an event that an order has been
submitted and process the notification to
the customer.
Your microservice would publish an event to a message bus
either indicating a state change or a failure and whichever
microservice is interested in that event, would pick it up and
process it.
5. Use a circuit breaker
• Fail fast by using a circuit breaker
to achieve fault tolerance

• If your microservice is dependent

on another system to provide a
response, and that system takes
forever to respond, your overall
response SLAs will be impacted

• Use a circuit breaker to timeout the external call and return a default response
or an error.

• You can choose to use popular products like Hystrix that Netflix developed

Fakultas Ilmu Komputer Universitas Brawijaya

6. Use API Gateway
• Proxy your microservice requests
through an API Gateway
• Problem with exposing microservices
directly to public:
• All services are publicly accessible
• Every microservice in the system
performing the functions of API
authentication, request / response
logging, and throttling
• Data breach • Nginx
• Clients calling your microservices will • Kong
connect to the API Gateway instead • Apache HTTPD
of directly calling your service • Netflix Zuul
• Spring Cloud
• The internal URLs of your service Gateway
would be hidden, giving you the
flexibility to redirect the traffic from
the API Gateway to a newer version more necessary when a third party is accessing your
of your service service, as you can throttle the incoming traffic and
reject unauthorized requests from the API gateway

Fakultas Ilmu Komputer Universitas Brawijaya

7. API changes are backwards compatible
• You can safely introduce changes to your API and release them fast if they
don’t break existing callers
• One option: perform integration testing It’s expensive
• All the dependencies need to line up in an environment and it will slow you down with a lot of
coordination
• A better option: contract testing for your APIs
• The consumers of your APIs provide contracts on their expected response from your API
• You as a provider would integrate those contract tests as part of your builds and these will
safeguard against breaking changes.

Fakultas Ilmu Komputer Universitas Brawijaya

8. Version your microservices for breaking changes

• It's not always possible to make backwards compatible changes.

• If you make a breaking change → expose a new version of your endpoint
while continuing to support older versions
• Consumers can choose to use the new version at their convenience
⚠ Having too many versions of API can create Nightmare!!
• Develop a disciplined approach to deprecate older versions by working
with consuming service

Fakultas Ilmu Komputer Universitas Brawijaya

9. Dedicated infrastructure for microservice
• Have dedicated infrastructure hosting your microservice
• A bad design of the hosting platform, can make best designed
microservice to behave poorly
• Isolate your microservice infrastructure from other components
• Isolate the infrastructure of the components that your microservice
depends on

In the pizza order example, let's say the inventory microservice

uses an inventory database. It is not only important for the
Inventory Service to have dedicated host machines, but also the
inventory database needs to have dedicated host machines.

Fakultas Ilmu Komputer Universitas Brawijaya

10. Create a separate release train
• Each service should have its repository for ease of access
• Have separate release train which is not tied to other components within your
organization.
• Reduce or even remove wasting time coordinating with multiple teams.

Fakultas Ilmu Komputer Universitas Brawijaya

11. Create Organizational Efficiencies
• Microservices give you the freedom to develop and release independently
→ Do it wrong, cause a lot headaches
• Certain standards need to be followed for cross cutting concerns
→every team doesn’t spend time creating unique solutions for these
• Need to be able to connect all the pieces of the puzzle to see a holistic
picture

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya