Software Architectures, Week 3 - Microservice-based Architectures

μservices

Week 3

But it is not the only topic today

• 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.

Monoliths vs μservices

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 .

μservices are not novel

Characteristics of a Microservice ArchitectureComponentization 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.

Characteristics of a Microservice ArchitectureComponentization 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.

Characteristics of a Microservice ArchitectureComponentization 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.

Characteristics of a Microservice ArchitectureOrganized 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 technology

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.

Characteristics of a Microservice ArchitectureProducts 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.

Characteristics of a Microservice ArchitectureSmart 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 platform.

Characteristics of a Microservice ArchitectureSmart 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).

Characteristics of a Microservice ArchitectureDecentralized 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.

Characteristics of a Microservice ArchitectureDecentralized 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

Characteristics of a Microservice Architecture Decentralized Governance (cont.)

• 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.

Characteristics of a Microservice Architecture 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.

Characteristics of a Microservice Architecture 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 therelationships 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.

Characteristics of a Microservice Architecture 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.

Characteristics of a Microservice Architecture 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.

• 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:

Characteristics of a Microservice Architecture 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.

Characteristics of a Microservice Architecture 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.

Characteristics of a Microservice Architecture 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.

Characteristics of a Microservice Architecture Evolutionary Design (cont.)

• 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.

• 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

Documents

Transcript of Software Architectures, Week 3 - Microservice-based Architectures

Week 15 - organic-electronics.engin.umich.edu

Unit 10 - Week 9

Business Week 2012 - Vasilaras

Alternative bridging architectures in organic nonlinear ...

Week 5 – September 30, 2003

Formally Modeling Software Architectures with the UML 2.0 Profile for π -ADL

Week 4: Asthma and COPD

Business Week 2012 - Raptopoulos

African Film Week Programme

European Robotics week 2015 - Cyprus

Optical Network Architectures - · PDF fileOptical Network Architectures . 2 Overview of Optical Networks The network as a cloud of information flows connecting different participants:

Lab Week 1 – Module α2

Get online week

Great Singapore Sale 8 week

Week 4 - 1 slides

Επιλυση Συγκρούσεων Week 1

Europe Code Week Presentation

ΧΡΗΜΑ Week #560,15/06/2015

[AIESEC] Welcome Week Presentation

Operating System Architectures