Software Architectures, Week 3 - Microservice-based Architectures

But it is not the only topic today
Also:
• Self-contained systems.
• Classical distributed systems.
• Hybrid microservice systems.

A modern classic on the subject

What is a microservice architecture?
• In short, the microservice architectural style is an approach to
developing a single application as a suite of small services, each
running in its own process and communicating with lightweight
mechanisms, often an HTTP resource API.
• These services are built around business capabilities and
independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these
services, which may be written in different programming languages
and use different data storage technologies.

The upside of monoliths
• With some care, you can run and test the application on a
developer's laptop, and use a deployment pipeline to ensure that
changes are properly tested and deployed into production.
• You can horizontally scale the
monolith by running many
instances behind a load-balancer.

And the downside
• Change cycles are tied together - a change made to a small part of the
application, requires the entire monolith to be rebuilt and deployed.
• Over time it's often hard to keep a good modular structure, making it
harder to keep changes that ought to only affect one module within that
module.
• Scaling requires scaling of the entire application rather than parts of it that
require greater resource.

Evolved paradigm
• These frustrations have led to the microservice architectural style:
building applications as suites of services.
• As well as the fact that services are independently deployable and
scalable, each service also provides a firm module boundary, even
allowing for different services to be written in different programming
languages.
• They can also be managed (=Operations as well?) by different teams .

Characteristics of a Microservice Architecture
Componentization via Services
• When talking about components we run into the difficult definition of what
makes a component. Our definition is that a component is a unit of
software that is independently replaceable and upgradeable.
• Microservice architectures will use libraries, but their primary way of
componentizing their own software is by breaking down into services.
• We define libraries as components that are linked into a program and
called using in-memory function calls, while services are out-of-process
components who communicate with a mechanism such as a web service
request, or remote procedure call.

Componentization via Services (cont.)
• One main reason for using services as components (rather than
libraries) is that services are independently deployable.
• Another consequence of using services as components is a more
explicit component interface.
• Remote calls are more expensive than in-process calls, and thus
remote APIs need to be coarser-grained, which is often more
awkward to use.

Componentization via Services (cont.)
• If you need to change the allocation of responsibilities between
components, such movements of behavior are harder to do when
you're crossing process boundaries.
• At a first approximation, we can observe that services map to runtime
processes, but that is only a first approximation. A service may consist
of multiple processes that will always be developed and deployed
together, such as an application process and a database that's only
used by that service.

Organized around Business Capabilities
Any organization that designs a system (defined broadly) will produce a
design whose structure is a copy of the organization's communication
structure.
-- Melvyn Conway, 1967

Division by business capability

Could we modularize monoliths by business capability?

Possibly yes, with some strings attached
• In the application is large enough to occupy multiple teams.
• If the teams are disciplined enough to stay within the defined
boundaries of their business concern.
• There may be excessively too many contexts involved for the
developers to keep in mind.
• The boundaries are implicit, making them more blurry and ambiguous
compared to the microservice approach.

Products not Projects
• Most application development efforts that we see use a project model.
• Microservice proponents tend to avoid this model, preferring instead the
notion that a team should own a product over its full lifetime.
• Amazon: "you build, you run it".
• The product mentality, ties in with the linkage to business capabilities, how
can software assist its users to enhance the business capability.

Smart endpoints and dumb pipes
• In many systems which require inter-process communication there
has been an emphasis on 'smart' communication mechanisms, that
enable message routing, applying business rules and advanced rules
and advanced rules and advanced queueing.
• Microservice depend on simple communication tools, like simple
REST protocols (usually over HTTP) and direct messaging (Erlang,
Akka,…) or via a lightweight message bus (like ØMQ and RabbitMQ –
Kafka?), which provides only a reliable, asynchronous messaging platf
orm.

Smart endpoints and dumb pipes (cont.)
• The smarts still live in the end points that are producing and
consuming messages; in the services.
• In a monolith, the components are executing in-process and
communication between them is via either method invocation or
function call.
• The biggest issue in changing a monolith into microservices lies in
changing the communication pattern (replacing fine-grained comms
with coarser ones).

Decentralized Governance
• Centralized Governance -> Standarization on single technology
platforms.
• Works 'okay', but does not let us tap the full extend of different
technologies which match different concerns the best.
• It doesn't mean that you need to use a different language for every
service.

Decentralized Governance (cont.)

• Teams building microservices prefer a different approach to standards
too. Rather than use a set of defined standards written down
somewhere on paper they prefer the idea of producing useful tools
that other developers can use to solve similar problems to the ones
they are facing.
• Excellent example: https://github.com/Netflix

• Define the contracts for your service.
• Contracts can help to automate the build process, irrespective of the
resource's implementation.
• The service can be build to the point it satisfies the contract, no need
for building unecessary artifacts (YAGNI) and specifications.
• Most extreme case: Amazon, devs build and run it 24/7.

Decentralized Data Management
• The conceptual model of the world will differ between systems.
• Sales have a different view from Devs, Devs from Ops and Ops from
PMs. They will need access to different subsets of the data or with a
different presentation logic and semantics.

Decentralized Data Management (cont.)

• A useful tool to tame the complexity is Domain-Driven Design (DDD).
• It can break down a complex problem domain
into multiple bounded contexts and to map the
relationships between them.
• Applicable to monoliths and μservices.

• How does a bounded context looks like?

• As well as decentralizing decisions about conceptual models,
microservices also decentralize data storage decisions.
• While monolithic applications prefer a single logical database for
persistant data.
• Microservices prefer letting each service manage its own database,
either different instances of the same database technology, or
entirely different database systems.

• This concept is named Polyglot Persistence.

Implications of Decentralized Data Management:
• How do we manage data updates?
• How do we ensure atomicity?
• How do we ensure consistency?

Implications of Decentralized Data Management:
• Transactionless coordination between services
• Accept eventual consistency.
• Evaluate: Cost of sporadic inconsistency vs Cost
of lost business under greater consistency.

Infrastructure Automation
• A must for μservice based architectures.
• It has evolved tremendously with the advent of public cloud
providers.
• Relevant buzzwords: Continuous Integration and Continuoud Delivery.

Infrastructure Automation (cont.)

Prerequisites for CD and CI:
• Thorough test coverage of the codebase.
• Lots of automated tests (not only unit tests).
• Every stage of the pipeline is actually an automated deployment to a
new environment.

• CD and CI for monoliths and μservices is not differing much.
• Do it first for your system before you break it and then it will be easy
:-)
• Make deployments boring and there wont be a difference between 1
or 10 services.

• Operating the architecturally different systems in production can be
very different.

• Monitoring for μservices requires significant more automation and
orchestration.
• There are many more moving parts and interfaces to look after.
• Employ a modern monitoring system which allows the collection of diverse
metrics from many different log sources in dispersed locations, trend
analysis and large actionable data size.
• Monitor services, not only machines; you are operating systems not apps.

Tools to look into, the ELK stack:

Tools to look into, the Prometheus + fluentd combo:

Design for Failure
• A consequence of using services as components, is that applications
need to be designed so that they can tolerate the failure of services
• Any service call could fail due to unavailability of the supplier, the
client has to respond to this as gracefully as possible.
• Since services can fail at any time, it's important to be able to detect
the failures quickly and, if possible, automatically restore service.

Design for Failure (cont.)
• Microservice applications put a lot of emphasis on real-time monitoring of
the application, checking both architectural elements (how many requests
per second is the database getting) and business relevant metrics (such as
how many orders per minute are received).
• Semantic monitoring can provide an early warning system of something
going wrong that triggers development teams to follow up and investigate.
• Microservice teams would expect to see sophisticated monitoring and
logging setups for each individual service such as dashboards showing
up/down status and a variety of operational and business relevant metrics.
Details on circuit breaker status, current throughput and latency are other
examples we often encounter in the wild.

Learning from the Pros:

Erlang's design principles:
• Let it crash.
• Shift the failure management one level up, where it can be managed
intelligently by your orchestration or monitoring software.
• Fail fast and recover fast and automatically.
• Keep as many things as possible immutable.

• Results into running in the wild with 9
nines uptime.
• 9,99999999% uptime equals to
27ms/year downtime.

Erlang is a classical distributed processing
environment, not a microservices-based one.
• Code can be reloaded to each 'service' node, they don't have a
dedicated functionality like in a microservice application.
• The overall architecture is more 'fluid' in terms of semantics.
• A microservices-based system is a distributed system, but the other
way around may not always hold true.

Evolutionary Design
• Service decomposition is yet a further tool to enable application developers to
control changes in their application without slowing down change.
• Change control doesn't necessarily mean change reduction - with the right
attitudes and tools you can make frequent, fast, and well-controlled changes to
software.
• The key property of a component is the notion of independent replacement and
upgradeability - which implies we look for points where we can imagine rewriting
a component without affecting its collaborators.
• Indeed many microservice groups take this further by explicitly expecting many
services to be scrapped rather than evolved in the longer term.

Evolutionary Design (cont.)

Evolutionary Design
• The Guardian started their website as a monolith.
• They evolve it towards a μservice architecture.
• The monolith is the system's core.
• New features are added as microservices that use the monolith's API.
• Approach that works very well with transient features like thematic pages
covering special events, polls or special issues with special UI elements and
visualization.

Evolutionary Design
• So evolving your design or using disposable services can be used for aims
that are beyond pure engineering. For instance:
• Enhanced user experience.
• Easier A/B testing.
• Agility in feature delivery.
• Easier transition from a monolithic application.

Another path – Self-Contained Systems (SCS)
• Main concept: Instead of decomposing a monolith in microservices,
you break it down to autonomous, replaceable web applications.
• SCS are larger than microservices and they will be considerably less
SCS than microservices originating from a monolithic application.
• SCS have also separate UI, business logic and data persistence.
• The preferred integration point is on the UI level and sometimes on
API.

Another path – Self-Contained Systems (SCS)

Show Case: Kühne + Nagel FreightNet
• An initially monolithic application which evolved to a 1,5 million LOCs Godzilla,
with 200+ developers working on it.
• It is written in an internally developed Java Web Framework. Later Spring, JSP,
JQuery, Swing/ ULC, GWT/GXT where thrown in the mix.
• It became extremely difficult to evolve it.
• It is K+N's most valuable product, evaluated to billions of Euros.
• It was a make-or-break situation for the company to keep the product
manageable.

Show Case: Kühne + Nagel FreightNet (cont.)
The migration process followed was:
• They stopped adding even more stuff to the monolith.
• They found the seams of the monolith.
• They realized that most of the seams are wishful thinking, way to
complicated and inter-dependent to split.
• They “desiccate” the monolith over time in spite of #3 through new
projects that cover parts of some of the monolith’s functionality.
• Moving to Microservices might be too much of a drastic step,
especially when you have such complex monolithic software.

Show Case: Kühne + Nagel FreightNet (cont.)
• In the end, FreightNet was broken to 10 SCS, each one with ist one UI.
• Mode of transport or modules offering very special functionality were
the seams which became the boundaries of the SCSs.
• It took them 4 years only to split the functionality from the monolith,
but they see it as the only way possible to decompose a project of
this order of complexity.

Interesting resources
• https://dev.otto.de/2015/09/30/on-monoliths-and-microservices/
• https://www.elastic.io/breaking-down-monolith-microservices-and-self-contained-systems/
• https://dev.otto.de/2016/03/20/why-microservices/
• http://ryanjbaxter.com/2015/07/15/using-microservices-to-build-cloud-native-applications-part-
1/
• Building Microservics, Buch 2013, O'Reilly.
• The Tao of Microservices, Rodger 2016, Manning.

Thank you very much! Have a nice weekend!

Software Architectures, Week 3 - Microservice-based Architectures

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Software Architectures, Week 3 - Microservice-based Architectures

Similar to Software Architectures, Week 3 - Microservice-based Architectures (20)

Software Architectures, Week 3 - Microservice-based Architectures

Editor's Notes