software architectures, week 3 - microservice-based architectures

59
μservices Week 3

Upload: angelos-kapsimanis

Post on 12-Apr-2017

141 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Software Architectures, Week 3 - Microservice-based Architectures

μservices 

Week 3 

Page 2: 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.

Page 3: Software Architectures, Week 3 - Microservice-based Architectures

A modern classic on the subject

Page 4: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 5: Software Architectures, Week 3 - Microservice-based Architectures

Monoliths vs μservices

Page 6: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 7: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 8: Software Architectures, Week 3 - Microservice-based Architectures

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 .

Page 9: Software Architectures, Week 3 - Microservice-based Architectures

μservices are not novel

Page 10: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 11: Software Architectures, Week 3 - Microservice-based Architectures

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. 

Page 12: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 13: Software Architectures, Week 3 - Microservice-based Architectures

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

Page 14: Software Architectures, Week 3 - Microservice-based Architectures

Division by technology

Page 15: Software Architectures, Week 3 - Microservice-based Architectures

Division by business capability

Page 16: Software Architectures, Week 3 - Microservice-based Architectures

Could we modularize monoliths by business capability?

Page 17: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 18: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 19: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 20: Software Architectures, Week 3 - Microservice-based Architectures

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

Page 21: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 22: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice ArchitectureDecentralized Governance (cont.)

Page 23: Software Architectures, Week 3 - Microservice-based Architectures

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

Page 24: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 25: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 26: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture Decentralized Data Management (cont.)

Page 27: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 28: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture Decentralized Data Management (cont.)

• How does a bounded context looks like?

Page 29: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture Decentralized Data Management (cont.)

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

Page 30: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Decentralized Data Management (cont.) 

• This concept is named Polyglot Persistence.

Page 31: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture   Decentralized Data Management (cont.)  

Page 32: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture   Decentralized Data Management (cont.)  

Implications of Decentralized Data Management:

• How do we manage data updates?

• How do we ensure atomicity?

• How do we ensure consistency?

Page 33: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture   Decentralized Data Management (cont.)  

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. 

Page 34: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 35: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Infrastructure Automation (cont.) 

Page 36: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 37: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Infrastructure Automation (cont.) 

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

Page 38: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Infrastructure Automation (cont.) 

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

Page 39: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Infrastructure Automation (cont.) 

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

Page 40: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Infrastructure Automation (cont.) 

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

Page 41: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Infrastructure Automation (cont.) 

Tools to look into, the ELK stack:

Page 42: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Infrastructure Automation (cont.) 

Tools to look into, the Prometheus + fluentd combo:

Page 43: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 44: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 45: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Design for Failure (cont.)

Learning from the Pros:

Page 46: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Design for Failure (cont.)

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.

Page 47: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Design for Failure (cont.)

• Results into running in the wild with 9 nines uptime. 

• 9,99999999% uptime equals to 27ms/year downtime.

Page 48: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 49: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 50: Software Architectures, Week 3 - Microservice-based Architectures

Characteristics of a Microservice Architecture  Evolutionary Design (cont.)

Page 51: Software Architectures, Week 3 - Microservice-based Architectures

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

Page 52: Software Architectures, Week 3 - Microservice-based Architectures

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

Page 53: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 54: Software Architectures, Week 3 - Microservice-based Architectures

Another path – Self-Contained Systems (SCS)

Page 55: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 56: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 57: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 58: Software Architectures, Week 3 - Microservice-based Architectures

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.

Page 59: Software Architectures, Week 3 - Microservice-based Architectures

Thank you very much! Have a nice weekend!