MICROSERVICE

ARCHITECTURE
EVOLUSI ARSITEKTUR MICROSERVICE

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

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya

microservices
give us a lot of
choice
accordingly, a lot of decisions to
make.

• how many different

technologies should we use?
• should we let different
teams use different
programming idioms?
• should we split or merge a
service?

With the faster pace of change,

the role of the architect also
must change.

Fakultas Ilmu Komputer Universitas Brawijaya

Inaccurate Comparisons
• Architects have an important job. They are in charge of making sure we have a joined-
up technical vision, one that should help us deliver the system our customers need.
• More than any other role, architects can have a direct impact on the quality of the
systems built, on the working conditions of their colleagues, and on their organization’s
ability to respond to change.

Our industry is a young one (around 70 years)

• we borrow names from other professions that already have the recognition.
We call ourselves software “engineers,” or “architects.” But we aren’t, are
we?
• Borrowing name from other professions can be doubly harmful.
1. It implies we know what we are doing, when we plainly don’t → ex.
Bridge fall vs Code Crash
2. the analogies break down very quickly when given even a cursory glance
→ ex. How if Bridge is like source code?
1950’s
Fakultas Ilmu Komputer Universitas Brawijaya
Core responsibilities of the evolutionary architect:
Vision
• Ensure there is a clearly communicated technical vision for the system that will help your
system meet the requirements of your customers and organization
Empathy
• Understand the impact of your decisions on your customers and colleagues
Collaboration
• Engage with as many of your peers and colleagues as possible to help define, refine, and
execute the vision
Adaptability
• Make sure that the technical vision changes as your customers or organization requires it
Autonomy
• Find the right balance between standardizing and enabling autonomy for your teams
Governance
• Ensure that the system being implemented fits the technical vision

Fakultas Ilmu Komputer Universitas Brawijaya

• The term architect has done the most harm
• That is the idea of someone who draws up detailed plans for others to interpret
and expects this to be carried out.
• In our industry, this view of the architect leads to some terrible practices.
• Diagram after diagram, page after page of documentation, created with a
view to inform the construction of the perfect system, without considering
the fundamentally unknowable future.
• Unfortunately, we are stuck with the word architect for now. So, the best
we can do is context.

Fakultas Ilmu Komputer Universitas Brawijaya

The evolutionary
architect is the one
who understands
that pulling off this
feat is a constant
balancing act.

Fakultas Ilmu Komputer Universitas Brawijaya

An Evolutionary Vision for the Architect
• Our requirements shift more rapidly than they do for people who design
and build buildings
• Once the software gets into the hands of our customers we will have to
react and adapt, rather than it being a never-changing artifact.
• Our architects need to shift their thinking away from creating the perfect
end-product, and instead focus on helping create a framework in which
the right systems can emerge

Fakultas Ilmu Komputer Universitas Brawijaya

Think of our role more as town
planners than architects for the
built environment.

• Look at a multitude of sources of

information
• Attempt to optimize the layout of a
city to best suit the needs of the
citizens
• The planner does not say “build this
specific building there”; instead, he
zones a city
• Spend far more time working out
how people and utilities move from
one zone to another, rather than
worrying too much about what
happens in one zone

Fakultas Ilmu Komputer Universitas Brawijaya

Zoning
• These are our service boundaries, or perhaps coarse-grained groups of
services.
• Worry much less about what happens inside the zone than what happens
between the zones.
• It may be OK with the team who owns that zone picking a different
technology stack or data store.
• Other Concerns:
1. harder to hire people or move them between teams
2. lacking enough experience to run any of them at scale.
• Between services is where things can get messy!
• If one service decides to expose REST over HTTP, another makes use of protocol
buffers, and a third uses Java RMI, then integration can become a nightmare

Fakultas Ilmu Komputer Universitas Brawijaya

A Principled Approach
• Making decisions in system design is all about trade-offs
• microservice architectures give us lots of trade-offs to make!
• Some decisions can be made completely on the spot with information
available.
• How if the information is incomplete?
• Framing can help!
• How to frame? → define a set of principles and practices that guide it, based on
goals that we are trying to achieve.

Fakultas Ilmu Komputer Universitas Brawijaya

Strategic Goals
• Luckily, architect usually doesn’t have to also define strategic goals!
• Strategic goals should speak to where the company is going
“Expand into Southeast Asia to unlock new markets.”
“Let the customer achieve as much as possible using self-service.”
“Organize the world’s information and make it universally accessible and useful”
• We need to make sure the technology is aligned to the goal.

Fakultas Ilmu Komputer Universitas Brawijaya

Principles
• Principles: rules to align what we are doing to some larger goal
• Rules will sometimes change.
• Fewer than 10 is a good number — small enough that people can
remember them Real world example: Heroku’s 12
Factors → Some of the
Strategic Goal Principles principles are constraints
decrease the time to market for new delivery teams have full control over the
features, lifecycle of their software to ship
whenever they are ready, independently
of any other team.
🎯
There can be some value in keeping
moving to aggressively grow its offering entire system must be portable to allow principles and constraints in the
in other countries, for it to be deployed locally in order to same list to encourage challenging
respect sovereignty of data. constraints every now and then and
see if they really are immovable!

Fakultas Ilmu Komputer Universitas Brawijaya

Practices
• Practices: how we ensure our principles are being carried out.
• a set of detailed, practical guidance for performing tasks
• often be technology-specific
• low level enough that any developer can understand them
• Practices could include:
• coding guidelines
• the fact that all log data needs to be captured centrally
• HTTP/REST is the standard integration style.
• Practices will often change more often than principles.
• Practices sometimes reflect constraints in the organization.
• Practices should underpin our principles.
Fakultas Ilmu Komputer Universitas Brawijaya
Combining Principles and Practices
• One person’s principles are another’s practices.
• One might decide to call the use of HTTP/REST a principle rather than a practice
• Key Point: there is value in having overarching ideas that guide how the
system evolves, and in having enough detail so that people know how to
implement those ideas.
• For a small enough group → it’s OK to combine principles and practices
• For larger organizations → there might be a different set of practices in
(with various technology and different places, as long as they both map to a
working practices)
common set of principles.

Fakultas Ilmu Komputer Universitas Brawijaya

A Real-World Example

• The figure shows the interplay of

goals, principles, and practices
• Over the course of a couple years:
• the practices on the far right will
change regularly
• the principles remain static.
• Each idea is simple enough for the
average developer to remember.
• There is more detail behind each
point

Fakultas Ilmu Komputer Universitas Brawijaya

The Required Standard
• One of the core balances to find when thinking about trade-offs is how
much variability to allow in your system.
• Keyways:
• What is a “good citizen” service in your system?
• “good citizen” service: a well-behaved, good service in our system
• What capabilities does it need to have to ensure that your system is manageable,
and that one bad service doesn’t bring down the whole system?
• A good citizen in one context does not reflect what it looks like somewhere else →
Just like the people
• There are some common characteristics of well-behaved services that are
important to observe.
• Allowing too much divergence on these key areas can result in a time with
full of difficulty.

Fakultas Ilmu Komputer Universitas Brawijaya

Monitoring
• Coherent, cross-service views of our system health are essential
• This must be a system-wide view, not a service-specific view.
• Ensure that all services emit health and general monitoring-related
metrics in the same way!
• Mechanism:
• push mechanism: each service needs to push this data into a central location.
• polling mechanism: scrape data from the nodes
• Whatever you pick, try to keep it standardized!
• Logging falls into the same category here: we need it in one place.

Fakultas Ilmu Komputer Universitas Brawijaya

Interfaces
The connection between services

• Picking a small number of defined interface technologies helps integrate

new consumers.
• Having one standard is a good number.
• Having two isn’t too bad.
• Having 20 different styles of integration is bad.
• This is more than just picking the technology and the protocol.
• Example:
• If you pick HTTP/REST, you might need to consider:
• will you use verbs or nouns?
• how will you handle pagination of resources?
• how will you handle versioning of end points?

Fakultas Ilmu Komputer Universitas Brawijaya

Architectural Safety
• One badly behaved service SHOULD NOT
ruin the party for everyone.
• We must ensure that our services shield
themselves accordingly from unhealthy,
downstream calls.
• The more services that do not properly
handle the potential failure of
downstream calls, the more fragile our
systems will be.
• Playing by the rules is important when it
comes to response codes, too.
• If the service communication rely on HTTP
codes, and one service decides to send back
2XX codes for errors, or confuses 4XX codes
with 5XX codes, then these safety measures
can fall apart.

Fakultas Ilmu Komputer Universitas Brawijaya

Governance Through Code
• Getting together and agreeing on how things can be done is a good idea.
• Spending time making sure people are following these guidelines is less
fun → Make it Easy to do the right thing!
• use exemplars
• provide service templates.

Fakultas Ilmu Komputer Universitas Brawijaya

Exemplars
• Written documentation is good, and useful
• But developers also like code, and code they can run and explore.
• Having exemplars that you can point people to is useful.
• The idea is that people can’t go far wrong just by imitating some of the
better parts of your system.
• Should be the exemplars that are being used
• We can ensure that all the principles we have make sense.

Fakultas Ilmu Komputer Universitas Brawijaya

Tailored Service Template
• It would be great if you could make it easy for all developers to follow
most of the guidelines you have with very little work.
• What if, out of the box, the developers had most of the code in place to implement
the core attributes that each service needs?
• Example:
Using Dropwizard and Karyon (open source JVM-based microcontainers) to pull
together a set of libraries to provide features like health checking, serving HTTP, or
exposing metrics.
Furthermore, you might want to mandate the use of circuit breakers. In that case,
you might integrate a circuit breaker library like Hystrix.

⚠
You do have to be careful that creating the service template doesn’t become the job of a central tools or architecture
team who dictates how things should be done, albeit via code → it should be a collective activity!

Fakultas Ilmu Komputer Universitas Brawijaya

Technical Debt
• Often, we need to make a choice to cut a few corners to get some urgent
features out.
• If we deviate from technical vision, it might have a short-term benefit but
a long-term cost → we’ve created a new source of technical Debt
• Just like debt in the real world it has an ongoing cost and is something we
want to pay down.
• Sometimes technical debt isn’t just something we cause by taking
shortcuts.
• What happens if our vision for the system changes, but not all our system
matches? → we’ve created a new source of technical Debt
• The architect’s job is to look at the bigger picture and understand this
balance.

Fakultas Ilmu Komputer Universitas Brawijaya

Exception Handling
• Our principles and practices guide how our systems should be built.
• what happens when our system deviates from this?
• Sometimes we make a decision that is just an exception to the rule.
• It might be worth capturing such a decision in a log somewhere for future reference.
• If enough exceptions are found, it may eventually make sense to change the principle
or practice to reflect a new understanding of the world.
• Example:

Practice: We will always we see compelling reasons New Practice: “Use MySQL for most storage
use MySQL for data to use Cassandra for highly requirements, unless you expect large growth in
storage. scalable storage volumes, in which case use Cassandra.”
Fakultas Ilmu Komputer Universitas Brawijaya
Governance and Leading from the Center
• If one of the architect’s jobs is ensuring there is a technical vision, then
governance is about ensuring what we are building matches this vision and
evolving the vision if needed.
• Make sure that the principles don’t require working practices that make
developers miserable.
• They need to keep up to date with new technology and know when to make the
right trade-offs.
• they also need to ensure that the colleagues they are working with understand the
decisions being made
• They shouldn’t do this alone. A properly functioning governance group can work
together to share the work and shape the vision.
• The architect chair the group but having the bulk of the group drawn from the
technologists of each delivery team — the leads of each team at a minimum.
• Sometimes, the group may make decisions with which the architect disagrees.
At this point, what is the architect to do?

Fakultas Ilmu Komputer Universitas Brawijaya

Building a Team
• Being system architecht who responsible for technical vision isn’t just
about making technology decisions.
• It’s the people you work with who will be doing the work!
• Help people step up by having them take ownership of individual services
before accepting more responsibility!
• Great software comes from great people.
• If we worry only about the technology side of the equation, we’re missing way
more than half of the picture.

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya