6 microservice architecture
0 likes•209 views
Microservice architecture consists of independently deployable services that communicate through defined interfaces. It supports DevOps processes by reducing coordination needs and allowing independent technology choices. Microservices improve modifiability over performance and can achieve reuse through deep service hierarchies. Discovery services locate service instances by name, and communication occurs via RPC, REST, or protocol buffers with JSON or XML payloads. Microservices are packaged with dependencies as containers deployed in pods for scalability. Design considers forward/backward compatibility across versions.
![© Len Bass 2019 5
Amazon design rules - 2
• It doesn’t matter what technology they[services] use.
• All service interfaces, without exception, must be
designed from the ground up to be externalizable.
• Amazon is providing the specifications for the
“Microservice Architecture”.](https://image.slidesharecdn.com/6microservicearchitecture-200402152020/85/6-microservice-architecture-5-320.jpg)
6 microservice architecture
- 1. DOSE: Deployment and Operations for Software Engineers Microservice Architecture
- 2. © Len Bass 2019 2 Overview • Definition • Microservices and DevOps • Quality attributes
- 3. © Len Bass 2019 3 Definition • A microservice architecture is • A collection of independently deployable processes • Packaged as services • Communicating only via messages
- 4. © Len Bass 2019 4 ~2002 Amazon instituted the following design rules - 1 • All teams will henceforth expose their data and functionality through service interfaces. • Teams must communicate with each other through these interfaces. • There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- 5. © Len Bass 2019 5 Amazon design rules - 2 • It doesn’t matter what technology they[services] use. • All service interfaces, without exception, must be designed from the ground up to be externalizable. • Amazon is providing the specifications for the “Microservice Architecture”.
- 6. © Len Bass 2019 6 In Addition • Amazon has a “two pizza” rule. • No team should be larger than can be fed with two pizzas (~7 members). • Each (micro) service is the responsibility of one team • This means that microservices are small and intra team bandwidth is high • Large systems are made up of many microservices. • There may be as many as 140 in a typical Amazon page.
- 7. © Len Bass 2019 7 Services can have multiple instances • The elasticity of the cloud will adjust the number of instances of each service to reflect the workload. • Requests are routed through a load balancer for each service • This leads to • Lots of load balancers • Overhead for each request.
- 8. © Len Bass 2019 8 Digression into Service Oriented Architecture (SOA) • The definition of microservice architecture sounds a lot like SOA. • What is the difference? • Amazon did not use the term “microservice architecture” when they introduced their rules. They said “this is SOA done right”
- 9. © Len Bass 2019 9 SOA typically has but microservice architecture does not • Enterprise service bus • Elaborate protocols for sending messages to services (WDSL*) • Each service may be under the control of different organization • Brokers • etc
- 10. © Len Bass 2019 10 Micro service architecture Service • Each user request is satisfied by some sequence of services. • Most services are not externally available. • Each service communicates with other services through service interfaces. • Service depth may – Shallow (large fan out) – Deep (small fan out, more dependent services)
- 11. © Len Bass 2019 11 Microservice architecture supports DevOps processes • Reduces need for coordination • Reduces pipeline errors • Supports continuous deployment
- 12. © Len Bass 2019 12 How does microservice architecture reduce requirements for coordination? • Coordination decisions can be made • incrementally as system evolves or • be built into the architecture. • Microservice architecture builds most coordination decisions into architecture • Consequently they only need to be made once for a system, not once per release.
- 13. © Len Bass 2019 13 Seven Decision Categories • Architectures can be categorized by means of seven categories 1. Allocation of functionality 2. Coordination model 3. Data model 4. Management of resources 5. Mapping among architectural elements 6. Binding time decisions 7. Technology choices
- 14. © Len Bass 2019 14 Design decisions with microservicess • Microservice architecture either specifies or delegates to the development team five out of the seven categories of design decisions. 1. Allocation of responsibilities. 2. Coordination model. 3. Data model. 4. Management of resources. 5. Mapping among architectural elements. 6. Binding time decisions. 7. Choice of technology
- 15. © Len Bass 2019 15 How do microservices reduce pipeline errors? • Many integration errors are caused by incompatibilities. • Each team makes its own technology choices for their services. This reduces errors during integration • No problems with inconsistent versions of dependent software • No problems with language choices
- 16. © Len Bass 2019 16 How do microservices support continuous deployment? • Each team can deploy their service when it is ready without consultation with other teams. • Since services are small, this can happen frequently • New feature implementation in one service can be deployed without waiting for that feature to be implemented in other services. • Requires architectural support – discussed in lectures on deployment
- 17. © Len Bass 2019 17 Quality attributes • Availability • Modifiability • Performance • Reusability • Scalability
- 18. © Len Bass 2019 18 Availability • Availability is achieved using • Multiple instances • Timeouts to recognize failure • Stateless instances • If instances are stateless, when an instance failure occurs a new instance can be created and placed into service
- 19. © Len Bass 2019 19 Modifiability • Modifiability depends on the design of the various microservices. • Low coupling and high cohesion are design principles to achieve modifiability. • Also, a catalog of microservices must be maintained since there will be many microservices and developers must be able to understand how functionality is distributed among them.
- 20. © Len Bass 2019 20 Performance • Microservices are based on message passing. • Network communication takes time. • Important to measure and monitor microservices to determine where time is spent so that performance objectives can be met. • Pods are means for improving performance
- 21. © Len Bass 2019 21 Reusability Service • Each user request is satisfied by some sequence of services. • Most services are not externally available. • Each service communicates with other services through service interfaces. • Service depth may – Shallow (large fan out) – Deep (small fan out, more dependent services)
- 22. © Len Bass 2019 22 Distinguish between coarse grain and fine grain reuse • Large microservices (coarse grained) are built into architecture and reuse is achieved by using these microservices • Small microservices (fine grained) can be designed for reuse (deep service hierarchy) or reuse can be ignored at this level (shallow service hierarchy)
- 23. © Len Bass 2019 23 Scalability • Scaling out can be done by cloud infrastructure • Stateless microservices are easily scaled since new instances can automatically be placed into service.
- 24. © Len Bass 2019 24 Trade off • Shallow hierarchy • higher performance since fewer messages, • low reuse since each service is developed by independent team with little coordination • Deep hierarchy • Lower performance since more messages • Higher reuse since services can be designed for multiple different clients.
- 25. © Len Bass 2019 25 Summary • Microservice architecture consists of collection of independently deployable services • Microservices supports devops processes by reducing need for communication among teams and making technology choices independent • Microservice architecture favors modifiability over performance. • Reuse can be achieved, if desired, by having deep service hierarchy.
- 26. © Len Bass 2019 26 Overview • Discovery • Making requests in a distributed system • Microservices and Containers
- 27. © Len Bass 2019 27 Discovery • Discovery is the process of finding an IP address of an instance of a microservice. • Isn’t that what DNS and load balancers are for? • Yes, but …
- 28. © Len Bass 2019 28 Why not DNS + Load Balancer • DNS assumes static IP addresses. So IP addresses of load balancer is used • Load balancer does not know the name of the microservice it manages • DNS + Load Balancer adds overhead. • Recall that microservices inherently have overhead from messages. • Combining DNS and Load Balancer functions in one place will reduce overhead.
- 29. © Len Bass 2019 29 Mid tier discovery service • A mid tier discovery service is accessed with a microservice name and returns an IP address of an instance of that microservice • The discovery service can be made version aware to support deployment options (discussed later)
- 30. © Len Bass 2019 30 Overview • Discovery • Making requests in a distributed system • Microservices and Containers
- 31. © Len Bass 2019 31 Communication between two microservices • RPC (Remote Procedure Request). • REST (REpresentational State Transfer)
- 32. © Len Bass 2019 32 RPC • RPC is a remote analog to traditional procedure calls. • One procedure calls another with a set of typed arguments, control is transferred to called procedure, and called procedure may respond by returning control • Synchronous although multiple threads allow for multiple simultaneous RPCs • Assumes calling procedure knows address of called procedure (no discovery)
- 33. © Len Bass 2019 33 gRPC • gRPC is a binary version of RPC • Used in conjunction with protocol buffers (discussed shortly) • Builds on HTTP 2.0 • Typically asynchronous
- 34. © Len Bass 2019 34 REST • Can be used between arbitrary services on the internet • Designed for web services
- 35. © Len Bass 2019 35 REST Characteristics • The requests are stateless. Every request must contain all the information necessary to act on that operation, • The information exchanged is textual – services and methods are accessed by name. • REST restricts methods to PUT, GET, POST, and DELETE.
- 36. © Len Bass 2019 36 Structuring Data • XML • JSON • Protocol Buffers
- 37. © Len Bass 2019 37 XML (Extensible Markup Language) • XML = textual document + schema • The schema provides tags to describe how to interpret the document • Tags are used to enclose fields just as in HTML.
- 38. © Len Bass 2019 38 JSON (JavaScript Object Notation) • Textual • Each data item is designated by a name and a value. E.g. "addressCountry": "United States",
- 39. © Len Bass 2019 39 Protocol Buffers - 1 • Schema defines data types • Binary format • A protocol buffer specification is used to specify an interface • Language specific compilers used for each side of an interface • Allows different languages to communicate across a message based interface
- 40. © Len Bass 2019 40 Protocol Buffers – 2 • Service A written in Java calls Service B written in C • Interface specification written as .proto file • Java protocol buffer compiler producers Java procedure interface for Service A • C protocol buffer compiler produces procedure interface for Service B • Service A code calls Java procedure interface which sends binary data received by Service B procedure (written in C)
- 41. © Len Bass 2019 41 Overview • Discovery • Making requests in a distributed system • Microservices and Containers
- 42. © Len Bass 2019 42 Microservices and Containers • Although microservices and containers were developed independently, they are a natural fit and are evolving together. • A microservice will use a number of dependent services. Common ones are: • Metrics • Logging • Tracing • Messaging • gRPC • Protocol buffers • Discovery • Registration • Configuration management • Dashboards • Alerts
- 43. © Len Bass 2019 43 Packaging microservices • Each dependent service will be packaged in its own containers. • Containers can be grouped in pods • Also called service mesh • Allows for deploying and scaling together
- 44. © Len Bass 2019 44 Designing for Deployment • It is possible that different versions of a single microservice may simultaneously be in service • It is possible that new features may be supported in some microservices but not in others.
- 45. © Len Bass 2019 45 Forward and Backward Compatibility • Microservices must be forward and backward compatible to support interoperability • Forward compatibility means that unknown calls are treated gracefully since one service may be assuming dependent services have features that have not yet been deployed.
- 46. © Len Bass 2019 46 Achieving Backwards Compatibility • APIs can be extended but must always be backward compatible. • Leads to a translation layer External APIs (unchanging but with ability to extend or add new ones) Translation to internal APIs Client Client Internal APIs (changes require changes to translation layer but do not propagate further)
- 47. © Len Bass 2019 47 Summary • Mid tier discovery services combine functions of DNS and load balancer • RPC variants and REST are two methods for communicating between services • XML, JSON, Protocol Buffers are different ways of managing data sent between two services. • Microservices have a standard set of dependent services and pods allow packing these services together for deployment and scaling. • Deployment options introduce requirements to design microservices for deployment