Arsitektur Aplikasi Modern

Sebuah perjalanan dari tightly coupled ke microservices

Faisal susanto – Praktisi TI

Loosey Coupled
loosely coupled system is one in which each of its
components has, or makes use of, little or no knowledge of
the definitions of other separate components
https://en.wikipedia.org/wiki/Loose_coupling
Step 1: Tightly coupled to Loosely Coupled
Tighly Coupled System
6 steps, in 1 API CALL
Web Layer Business Layer DB Layer

make_purchase()

HTTP 200 (OK)

All these round trip in 1 API call is, make this a tightly coupled architecture. Disadvantage:
• Wait Time
• Prone to network disruption
• Unable to scale efficiently
Base Architecture
Web Layer Business Layer DB Layer
Server 1

https

Server 2
Step 1: Hairpin your architecture
Web Layer Business Layer DB Layer

http
https tcp

Introduce load balancer in web

and business layer to force it to
use TCP protocol
Tighly Coupled System – modernized(?)
This sample architecture is
designed to take advantage of
Public Cloud features
• Autoscaling
• CDN/Edge Caching
• Database Caching
• etc Web Layer
But pay attention on how user
transaction is processed

Business Layer

If user still needs to wait until the

data is stored in DB, then this
architecture, although scalable, is DB Layer
still tightly coupled
Analyze your architecture
Web Layer Business Layer DB Layer

http
https tcp
Step 2: Introduce buffering mechanism
Introduce a way to make your layers independent of each other

buffer Queue / file etc DB Layer

Web Layer Business Layer

make_purchase()

OK, we will inform once your

order is ready()

Real life example: Order food in café

Your order is complete() 1. Cashier take your order (and payment)
2. The cashier give the receipt and you can then join
your friend in the seating area
3. One the order is finished, you can pickup the order
Deconstructing Tightly coupled System
Holding facility / buffer example – AWS SQS
Web Layer Business Layer DB Layer

make_purchase()

OK, we will inform once your

order is ready()

Your order is ready()

Congratulations! Your architecture
is now loosely coupled

Now to Microservices
Step 3: Loosely Coupled to Microservices
What is Microservices

Services communicate with each other over the

network (via API)

You can update the services independently;

updating one service
doesn’t require changing any other services.

Self-contained; you can update the code

without
knowing anything about the internals of other
microservices
From Loosely coupled to Microservices

Initial 3 layers architecture

Web Layer Business Layer DB Layer

Cart Orders
Web Front
End
Account
From Loosely coupled to Microservices
Start with (ideally) new service

Web Layer Business Layer DB Layer

Cart Orders
Web Front
End
Account

RegisteredUser

RegisteredUserDB
From Loosely coupled to Microservices
Then attack the low hanging fruits

Web Layer Business Layer DB Layer

Orders
Web Front
End
Account

RegisteredUser UserCart

RegisteredUserDB UserCartDB
From Loosely coupled to Microservices
Web Layer Business Layer

Orders

Account
Web Front
End
RegisteredUser

UserCart
Then again and again
Until all services are converted to
microservices
Microservices and Containers
Benefit of going containerized
Up in seconds

Containers are lighter than

VM Spin up in minutes Spin up in seconds

Since it does not have the

Guest OS
• Smaller package
• Faster to Execute

Spinning up container is
much faster than VM
Containers in Action
Web Layer Business Layer DB Layer

make_purchase()

OK, we will inform once

your order is ready()

Your order is ready()

Microservices – Pros and Cons
Pros
Smaller and faster deployments: Smaller codebases and scope =
quicker deployments, which also allow you to start to explore the
benefits of Continuous Deployment.
Scalability: Since your services are separate, you can more easily
scale the most needed ones at the appropriate times, as opposed to
the whole application.
Ease of understanding: With added simplicity, developers can better
understand the functionality of a service
Cons
Testing is difficult: Testing a microservices-based application can be
cumbersome.
Debugging problems can be harder: Each service has its own set of
logs to go through. Log, logs, and more logs.
Large vs small product companies: Microservices are great for large
companies, but can be slower to implement and too complicated for
small companies
 SUMMARY

1. Things to consider when you want to go microservices

• How do I remove dependencies between components / layers
• What are services/functions that are used the most in my
applications

2. Microservice is complex in nature, is it worth doing it NOW ?

• Testing
• Logging
• Time to market
About Serverless
Serverless Computing

Serverless computing is a cloud computing execution model in which the

cloud provider allocates machine resources on demand, taking care of
the servers on behalf of their customers. Serverless computing does not hold
resources in volatile memory; computing is rather done in short bursts with
the results persisted to storage. When an app is not in use, there are no
computing resources allocated to the app. Pricing is based on the actual
amount of resources consumed by an application
Serverless Use Cases
Serverless Example using Azure
Thanks :)