MICROSERVICE

ARCHITECTURE
Integrasi Proses Bisnis dengan Microservice

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

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya

• Getting integration right is the single most important aspect of the
technology associated with microservices

✅ Do it well à your microservices retain their autonomy, allowing you to

change and release them independent of the whole.

❎ Do it wrong à disaster awaits.

• Avoid some of the biggest pitfalls that have plagued other attempts at
SOA!

Fakultas Ilmu Komputer Universitas Brawijaya

Looking for the Ideal Integration Technology
• SOAP (Simple Object Access Protocol)? ⚠ Avoid Breaking Changes
• XML-RPC? pick technology that ensures breaking change
happens as rarely as possible.
• REST?
⚠ Keep Your APIs Technology-Agnostic
• Protocol buffers?
avoiding integration technology that
dictates what technology stacks we can use
to implement our microservices.
⚠ Make Your Service Simple for Consumers
makes it easy for consumers to use our
wonderful new service. Ideally, we’d like to
allow our clients full freedom in their
technology choice
⚠ Hide Internal Implementation Detail
We don’t want our consumers to be bound
to our internal implementation à leads to
increased coupling.

Fakultas Ilmu Komputer Universitas Brawijaya

Interfacing with Customers
• Let’s look at some of the most common options of integration technology
and try to work out which one works best for us.
Let’s go back to MusicCorp example!

• Customer creation at first glance could be considered a simple set of CRUD

operations, but for most systems it is more complex than that.
• Enrolling a new customer may need to kick off additional processes,
• like setting up financial payments or sending out welcome emails.
• when we change or delete a customer, other business processes might get
triggered as well.

So, with that in mind, we should look at some different ways in which we might want to work with
customers in our MusicCorp system.

Fakultas Ilmu Komputer Universitas Brawijaya

The Shared Database
Figure shows our registration UI, which
1. creates customers by performing
SQL operations directly on the
database.
2. It also shows our call center
application that views and edits
customer data by running SQL on
the database.
3. And the warehouse updates
information about customer orders
by querying the database.

This is a common enough pattern, but

it’s one fraught with difficulties.

Fakultas Ilmu Komputer Universitas Brawijaya

Difficulties of Shared Database
First, we are allowing external parties to view and bind to internal
implementation details.
If we decide to change our schema to better represent data, or make system easier to
maintain, we can break our consumers.
Second, the consumer services are tied to a specific technology choice.
Perhaps right now it makes sense to store customers in a relational database, so the
consumers use an appropriate (potentially DB-specific) driver to talk to it. What if over time
we realize we would be better off storing data in a nonrelational database? Goodbye, loose
coupling 👋.
Finally, let’s think about behavior for a moment.
There is going to be logic associated with how a customer is changed. Where is that logic?
The logic to perform the same sorts of manipulation to a customer may now be spread
among multiple consumers. If there is bug, we need to fix it in different places. Goodbye,
cohesion 👋 👋.

Fakultas Ilmu Komputer Universitas Brawijaya

Synchronous Versus Asynchronous
• Before we start diving into the specifics of different technology choices,
we should discuss one of the most important decisions we can make in
terms of how services collaborate: Synchronous vs Asynchronous?
• Synchronous communication: a call is made to a remote server, which
blocks until the operation completes.
• easier to reason about.
• Asynchronous communication: the caller doesn’t wait for the operation to
complete before returning and may not even care whether the operation
completes at all.
• very useful for long-running jobs, where keeping a connection open for a long
period of time between the client and server is impractical.
• These two different modes of communication can enable two different
idiomatic styles of collaboration: request/response or event-based
Fakultas Ilmu Komputer Universitas Brawijaya
Orchestration Versus Choreography
• As we start to model more and an example from MusicCorp
more complex logic, we must deal
with the problem of managing
business processes that stretch
across the boundary of individual
services.
• Orchestration: we rely on a central
brain to guide and drive the
process, much like the conductor in
an orchestra.
• Choreography: we inform each part
of the system of its job, and let it
work out the details,

Fakultas Ilmu Komputer Universitas Brawijaya

Handling customer creation via Handling customer creation via
orchestration choreography

systems that tend more toward the choreographed approach

are more loosely coupled and are more flexible and amenable
to change.

Fakultas Ilmu Komputer Universitas Brawijaya

• Some technologies will fit more naturally into one style or another.
• We do, however, need to appreciate some of the different technical
implementation details that will further help us make the right call.
• Two technologies that fit well when we are considering request/response:
• remote procedure call (RPC)
• REpresentational State Transfer (REST)

Fakultas Ilmu Komputer Universitas Brawijaya

Remote Procedure Calls
• Remote procedure call refers to the technique of making a local call and
having it execute on a remote service somewhere.
Java server exposing a
• RPC technologies: SOAP interface, and a .NET
Relies on having an interface definition
• SOAP The use of a separate interface definition
client generated from the
Web Service Definition
• Apache Thrift can make it easier to generate client and à
Language (WSDL)
• Protocol buffers server stubs for different technology stacks definition of the interface.
• Java Remote Method Invocation (RMI) à calls for a tighter coupling between the
client and server, requiring that both use the same underlying technology but avoid
the need for a shared interface definition. Obsolete.
• Java RMI, Thrift, or protocol buffers uses Binary
• SOAP uses XML for its message formats.

Fakultas Ilmu Komputer Universitas Brawijaya

Technology Coupling
• Some RPC mechanisms, like Java RMI, are heavily tied to a specific
platform, which can limit which technology can be used in the client and
server.
• Thrift and protocol buffers have an impressive amount of support for
alternative languages à reduces coupling
• The technology coupling can be a form of exposing internal technical
implementation details.
• Example: the use of RMI ties not only the client to the JVM, but the server too.

Fakultas Ilmu Komputer Universitas Brawijaya

Local Calls Are Not Like Remote Calls
• The core idea of RPC is to hide the complexity of a remote call.
• RPC can hide the fact that local calls and remote calls are very different.
• We can make large numbers of local in-process calls without worrying overly about
the performance.
• But with RPC we need to worry the cost of marshalling and un-marshalling payload,
the network.
• You need to think differently about API design for remote interfaces versus
local interfaces.
• Famously, the first of the fallacies of distributed computing is “The
network is reliable”. In fact, networks aren’t reliable.

Fakultas Ilmu Komputer Universitas Brawijaya

Brittleness
• Some of the most popular implementations of RPC can lead to some nasty
forms of brittleness, Java’s RMI being a very good example.

Defining a service endpoint using Java RMI

What happens if we decide to allow the Customer object
to also be created with just an email address?

The problem is that now we need to regenerate the

client stubs too.

Fakultas Ilmu Komputer Universitas Brawijaya

Is RPC Terrible?
• Despite its shortcomings, we wouldn’t go so far as to call RPC terrible.
• Many operations fall quite nicely into the RPC-based model, and more
modern mechanisms like protocol buffers or Thrift mitigate some of RPC’s
problem
• Just be aware of some of the potential pitfalls associated with RPC if
you’re going to pick this model.
• Don’t abstract your remote calls to the point where the network is
completely hidden.
• ensure that you can evolve the server interface without having to insist on
lock-step upgrades for clients.

Fakultas Ilmu Komputer Universitas Brawijaya

REpresentational State Transfer (REST)
• REpresentational State Transfer (REST) is There are many different styles of REST.
an architectural style inspired by the
Web. Richardson Maturity Model
• The most important in REST is the
concept of resources.
• REST itself doesn’t really talk about
underlying protocols, although it is most
used over HTTP.
• REST can be implemented using very
different protocols, such as serial or USB,
although this can require a lot of work.
• Some of the features that HTTP gives us
as part of the specification, such as verbs,
make implementing REST over HTTP
easier

Fakultas Ilmu Komputer Universitas Brawijaya

REST and HTTP
• HTTP itself defines some useful capabilities that play very well with the REST
style. Example: HTTP verbs (e.g., GET, POST, and PUT)
• HTTP also brings a large ecosystem of supporting tools and technology.
• Caching proxies: varnish
• Load Balancers: mod_proxy
• many monitoring tools already have lots of support for HTTP out of the box.
• We also get to use all the available security controls with HTTP to secure our
communications.
• To get these benefits, you must use HTTP well.
• Use it badly, and it can be as insecure and hard to scale as any other technology
• Note: HTTP can be used to implement RPC too, but unfortunately uses very little
of the specification (like in SOAP).

Fakultas Ilmu Komputer Universitas Brawijaya

Hypermedia As the Engine of Application State
• abbreviated as HATEOAS
• Hypermedia is a concept whereby a piece of content contains links to various
other pieces of content in a variety of formats (e.g., text, images, sounds) à
that is what the average web page does!!
• The idea behind HATEOAS is that clients should perform interactions (potentially
leading to state transitions) with the server via these links to other resources.
• consider how people interact with a web page, which we’ve already established is rich with
hypermedia controls.
• Think of the e-commerce site: How the site present shopping cart has changed
overtime. But as humans we are smart enough to still see a shopping cart, know
what it is, and interact with it.
• With HATEOAS, we are trying to achieve the same level of smarts for our
electronic consumers.

Fakultas Ilmu Komputer Universitas Brawijaya

JSON, XML, or Something Else?
• REST over HTTP lets us use a variety of standard textual formats, such as: JSON,
XML
• This gives clients a lot of flexibility as to how they consume resources.
• JSON is a much simpler format means that consumption is also easier.
• JSON does have some downsides:
• XML defines the link control we used earlier as a hypermedia control. The JSON standard
doesn’t define anything similar à might be fixed using Hypertext Application Language
(HAL)
• We aren’t limited to these two formats, we even can send Binary over HTTP
• Kind of odd that people pick JSON because it is nice and lightweight, then try
and push concepts into it like hypermedia controls that already exist in XML.

Fakultas Ilmu Komputer Universitas Brawijaya

Beware Too Much
Convenience

• As REST has become more popular, so too have the

frameworks that help us create RESTFul web services.
⚠ Some of these tools trade off too much in terms
of short-term gain for long-term pain; in trying
to get you going fast, they can encourage some
bad behaviors.
Example: some frameworks make it very easy
to simply take database representations of
objects, deserialize them into in-process
objects, and then directly expose these
externally.
Fakultas Ilmu Komputer Universitas Brawijaya
Downsides to REST Over HTTP
• In terms of ease of consumption, you cannot easily generate a client stub
for your REST over HTTP application protocol like you can with RPC.
• The overhead of HTTP for each request may also be a concern for low-
latency requirements.
• HTTP isn’t great for low-latency communications
when compared to alternative protocols that are
built on top of Transmission Control Protocol (TCP) or
other networking technology.
• Despite these disadvantages, REST over HTTP is a
sensible default choice for service-to-service
interactions.

Fakultas Ilmu Komputer Universitas Brawijaya

Asynchronous Event-Based Collaboration
• Technology Choices
• There are two main parts we need to consider:
1. a way for our microservices to emit events,
2. a way for our consumers to find out those events have happened.
• Message brokers like RabbitMQ try to handle both problems.
• These systems are normally designed to be scalable and resilient, but that
doesn’t come for free.
• It can add complexity to the development process, because it is another
system you may need to run to develop and test your services.
• Another approach is to try to use HTTP as a way of propagating events.
• ATOM is a REST-compliant specification that defines semantics (among
other things) for publishing feeds of resources.

Fakultas Ilmu Komputer Universitas Brawijaya

Complexities of Asynchronous Architectures
• Event-driven architectures seem to lead to significantly more decoupled,
scalable systems.
• But these programming styles do lead to an increase in complexity:
• complexity required to manage publishing and subscribing to messages
• other problems: when considering long-running async request/response, we have to think
about what to do when the response comes back. Does it come back to the same node that
initiated the request? If so, what if that node is down?
• The associated complexity with event-driven architectures and
asynchronous programming makes you should be cautious in how eagerly
you start adopting these ideas.
• Ensure you have good monitoring in place, and strongly consider the use
of correlation IDs, which allow you to trace requests across process
boundaries.

Fakultas Ilmu Komputer Universitas Brawijaya

Services as State Machines
• Whether you choose to become a REST ninja or stick with an RPC-based
mechanism like SOAP, the core concept of the service as a state machine is
powerful.
• For example:
• Our customer microservice owns all logic associated with behavior in its context.
• When a consumer wants to change a customer data, it sends an appropriate
request to the customer service.
• The customer service, based on its logic, gets to decide if it accepts that request or
not.
• We want to avoid dumb, anemic services that are little more than CRUD
wrappers.
• If the decision about what changes are allowed to be made to a customer
leak out of the customer service itself, we are losing cohesion.
Fakultas Ilmu Komputer Universitas Brawijaya
DRY: don’t repeat yourself
and the Perils of Code Reuse in a Microservice World

• Having lots of lines of code that do the same thing makes your codebase
larger than needed, and therefore harder to reason about.
• DRY is what leads us to create code that can be reused.
• Perhaps we go as far as making a shared library that we can use
everywhere!
• This approach, however, can be deceptively dangerous in a microservice
architecture.
• Sometimes, however, the use of shared code can create coupling system.
• Rule of thumb: don’t violate DRY within a microservice but be relaxed
about violating DRY across all services.

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya