Introduction to Microservices
Download as PPTX, PDF1 like797 views
The document provides an overview of microservices architecture including: - Definitions and characteristics of microservices such as componentization via services, decentralized governance, and infrastructure automation. - Common drivers for adopting microservices like agility, safety, and scalability. - Guidelines for decomposing monolithic applications into microservices based on business capabilities and domain-driven design. - Discussion of differences between microservices and service-oriented architecture (SOA). - Ecosystem of tools involved in microservices including development frameworks, APIs, databases, containers, and service meshes. - Common design patterns and anti-patterns when developing microservices.
Ad
More Related Content
What's hot (20)
Similar to Introduction to Microservices (20)
Ad
Recently uploaded (20)
Ad
Introduction to Microservices
- 1. Microservices The next step in architecture? mei ’18
- 2. Agenda • 16:00 – 16:30 Walk-in • 16:30 – 17:15 Microservices: Roger • 17:15 – 18:30 Vision and patterns MuleSoft • 18:30 – 19:30 Dinner • 19:30 – 20:30 Handson MuleSoft mei ’18 2
- 3. Microservices • Definition • Drivers • Sizing • MS vs SOA • MS Ecosystem • Decomposition • Patterns and Anti-Patterns • Frameworks and tooling • Reference Architecture • Microservices Conference Berlin 2018 • Takeaways mei ’18 3
- 4. What is a Microservice ? mei ’18 4 Resilient Business Capability Container DevOps Loose Coupling Strong Cohesion Polyglot Bounded Context Scaling EDA API Cloud
- 5. History • A group of architects cam together in Venice 2011 to discuss the common architectural styles recently exploring • In May 2012, the same group decided on “Microservices” as the most appropriate name. mei ’18 5
- 6. Wat is a Microservice Architecture? 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. -- James Lewis and Martin Fowler mei ’18 6
- 7. “Microservices are small autonomous services that work together” – Sam Newman “Loosely coupled service-oriented architecture with bounded contexts” – Adrian Cockcroft “A microservice is an independently deployable component of bounded scope that supports interoperability through message- based communication. Microservice architecture is a style of engineering highly automated, evolvable software systems made up of capability- aligned microservices.” mei ’18 7
- 8. Characteristics • Componentization via Services • Organized around Business Capabilities • Products not Projects • Smart endpoints and dumb pipes • Decentralized Governance • Decentralized Data Management • Infrastructure Automation • Design for failure • Evolutionary Design Martin Fowler mei ’18 8
- 9. Bounded Context / scope mei ’18 9 Microservice Framework / Language Database REST REST API Bounded Context / scope Microservice Framework / Language Database API Bounded Context / scope Microservice Framework / Language Database API Domain Model Domain Model Domain Model
- 11. mei ’18 11 Agility Safety Release Speed ScalabilityExperimenting Flexibility Replaceability Microservices Drivers Decentralized Governance
- 12. What makes a good size? mei ’18 12
- 13. “Size” of a Microservice • LOC? • One “entity”? • Team size? • API size? • Deployment time? • Sam Newman “small enough and no smaller” mei ’18 13
- 14. Decomposition mei ’18 14 Business Capability DDD Bounded Context Ubiquitous Language Event Storming
- 15. Example (DDD) mei ’18 15 Entities Aggregates Object Values Business Capabilities Ubiquitous language
- 16. Interesting DDD methods • Event storming (See https://www.infoq.com/news/2014/06/dddx-brandolini- eventstorming) • Domain Story telling (See https://www.infoq.com/news/2018/02/storytelling-domain- contexts) mei ’18 16
- 17. Data • What is the data representing in a particular domain context? Boundaries: DDD Entities, Value objects and Aggregates. i.e. Book in seach context is Title and in Order is titles+copies, so entities mean different things ! • Transaction boundaries: smallest unit of atomicity that you need mei ’18 17
- 18. Microservices “vs” SOA mei ’18 18
- 19. Microservices “vs” SOA mei ’18 19 SOA Microservices Layering (utility, entity, task layers) No layering (on service level) CDM Domain Models http/soap, XML, WSDL , XSD REST/http, JSON, Polyglot Composite orchestrations Event driven architectures ESB Service Mesh Value chain and business model is changing the entire business process Value chain and business model is about efficiencies, small teams and DevOps practices while eliminating cilos. Focus on reusability Focus on usability and speed Loose Coupling Loose Coupling Dividing problem domain into services Dividing problem domain into services
- 21. mei ’18 21 Microservice Ecosystem Service (micro) Process Tools CultureOrganisation Solution (macro)
- 22. Microservices Platform SOA • “Small” services • Domain Drive Design • Webservices • CQRS DevOps • CI / CD • Monitoring • Automatic testing • Deployments Agile / Organisation • Small teams • Small increments • Fast delivery • Culture Cloud • Containerization • Horizontal scaling • Deployments Event Driven Architecture • Loose coupling • Event sourcing API Management • REST API • Routing • API Gateway • Orchestration • Transformation mei ’18 22
- 23. Design Patterns mei ’18 23
- 24. Patterns and Anti-Patterns Anti-Patterns • Distributed Monolith (hype driven architecture) • Decoupling Illusion (technical- does not match business separation) • Micro Platform (standardization internal runtime aspects) • Entity Service (too wide business entities) • Anemic Service (solely data encapsulation) • Unjustifed re-use (extremely generic utility functions) • Domain-last approach (org structure around technical capabilities, not business domain) mei ’18 24
- 25. mei ’18 25 Source: http://microservices.io/patterns Chris Richardson
- 26. Anti patterns mei ’18 26
- 27. Distributed Monolith • Microservices gone bad • System made up of arbitrarily sized, tightly coupled modules communicating over network interfaces (i.e. everything is DCOM object) mei ’18 27
- 28. Decoupling Illusion mei ’18 28 • Functional changes required by different stakeholders require changes to overlapping services • Too much focus on re-use
- 29. Micro platform • Standardization of service internal runtime aspects • (Perceived ) increased efficiency, but practically shared dependencies on details, which increases the need for communication mei ’18 29
- 30. Entity Service • Service boundaries are chosen to encapsulate “wide” business entities • Perceived benefit of canonical models mei ’18 30
- 31. Anemic Service • Services designed solely encapsulate data, with logic in other layer mei ’18 31
- 32. Unjustified re-use • Extremely generic utility functions to reduce logic redundancy • Leads to more complexity mei ’18 32
- 33. Domain-last approach • Major driver for organisational structure is roles and technical capabilities, not business domain mei ’18 33
- 34. Patterns • Decentralized domain focused cells with maximum authority over all aspects of a set of capabilities • Cross functional teams mei ’18 34
- 35. Sizing Patterns (small -> large) • FaaS (Function as a Service, small, async, serverless) • microSOA (small, self hosted containerized services, close) • Distributed Domain-Driven Design (bounded context) • Self-contained Systems (UI+DB) • Monolith (1 application is ok) mei ’18 35
- 37. mei ’18 37
- 38. Type of tools • Development (KumuluzEE , Springboot, NodeJs, Scala, Akka, Play framework, Lagom, Eventuate) • API (OpenAPI, WADL, Blueprint, RAML) • Database (Cassandra, Datomic, Mongo, Neo4J) • Gateways (Netflix Zuul, Jboss Netty, Twitter Finagle) • Monitoring (Twitter Zipkin, Netflix Hystrix) • Container management(Docker, Kubernetes, Mesos) • Communication (http, Kafka) • Service Mesh (HAProxy, traefik, NGINX, Istio, Linkerd) mei ’18 38
- 39. Service Mesh mei ’18 39 No centralized integration/ESB layer but a set of (composite and atomic) microservices. Service-to-service communication at the microservices level.
- 40. Microservices toolsheet • Sheet with reference architecture concepts and the tools/frameworks/products available to fill in those concepts • Feel free to contribute ! • https://docs.google.com/spreadsheets/d/1BAR2pZlaqNGAEAW q7qDyKM7xYlt3uhoHAmlnsau0gdw mei ’18 40
- 41. mei ’18 41
- 43. mei ’18 43
- 44. Pace Layer Model mei ’18 44
- 45. Microservices Conference Berlin 2018 mei ’18 45
- 46. mei ’18 46
- 47. • Architecture /design / tools&framework sessions • Workshops • Service Mesh • Micro frontends • Patterns (i.e. Sagas) • Kubernetes mei ’18 47
- 48. What’s next mei ’18 48
- 49. • Microservices Maturity Model • Consumer Driven Contracts • Frontend modularisation needs innovation • Organisational structures (team sizes) • Event Sourcing • Handling data (sharing / transactions (Sagas)) • Security (OpenID, OAuth2, JWT) • Serverless (AWSLambda, functions, deployment model) mei ’18 49
- 51. • Microservices is (still) not the holy grail ! • Don’t fall into trap of the anti-patterns • Don’t fall into the trap of hype and available tools and frameworks • Microservices is no mainstream and commodity. Tools are not always production ready • Microservices architecture is NOT easy • Define what you try to achieve • Add it to your bag of architecture tools mei ’18 51
- 52. Backup slides mei ’18 52
- 53. Resources • https://martinfowler.com/microservices/ • http://microservices.io/patterns/microservices.html • http://api.co/msabook mei ’18 53
- 54. Books mei ’18 54
- 55. Componentization via Services A component is a unit of software that is independently replaceable and upgradeable. libraries are components that are linked into a program and called using in-memory function calls services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call. One main reason for using services as components (rather than libraries) is that services are independently deployable. mei ’18 55
- 56. Organized around Business Capabilities Conway’s Law: 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 mei ’18 56
- 57. Organized around Business Capabilities (2) The microservice approach to division is different, splitting up into services organized around business capability. (including user-interface, persistant storage, and any external collaborations) mei ’18 57
- 58. Products not Projects • A team should own a product over its full lifetime • “You build, you run it” mei ’18 58
- 59. Smart endpoints and dumb pipes • NO smart within communication mechanism (i.e. ESB) • The smarts live in the end points that are producing and consuming messages; in the services. mei ’18 59
- 60. Decentralized Governance • So less standardization on platforms and technology ( costs !) • Use right tool for the job mei ’18 60
- 61. Decentralized Data Management • Conceptual model of the world will differ between systems -> Bounded Context • Polyglot Persistence mei ’18 61
- 62. Infrastructure automation • CD/CI • Automated test • Automated deployments mei ’18 62
- 63. Design for Failure • Applications must be able to tolerate failures of services • Real-time monitoring (latency, throughput) mei ’18 63
- 64. Evolutionary Design • Service decomposition as tool for flexibility and change • The key property of a component is the notion of independent replacement and upgradeability • If you find yourself repeatedly changing two services together, that's a sign that they should be merged. • Avoid versioning (be tolerant) mei ’18 64
- 65. API Gateway vs Service Mesh mei ’18 65
- 66. Monolith sv Microservices mei ’18 66
- 67. 1. Hardware Bare metal, AWS EC2, Google Cloud Platform, Azure. Resource abstraction: Docker, Apache Mesos Configuration management, Provisioning, monitoring and logging 2. Communication Network, DNS, service discovery, service load balancing, messaging 3. Application platform Development tools, test/package/build/release, deployment pipeline, logging and monitoring 4. Microservices Microservice itself and corresponding configurations mei ’18 67 Layer 4: Microservices Layer 3: Application platform Layer 2: Communication Layer 1: Hardware
- 68. mei ’18 68
- 69. mei ’18 69
- 70. mei ’18 70
- 71. How to decompose? • Business Capabilities Guides the decomposition according to the way the business is structured (Conway’s law) • Domain-Driven Design (DDD) subdomain Provides a suite of tools and methodologies to reason about the underlying domain at hand. DDD Strategic Patterns guide the creation of a context map which forms the foundation of the decomposition mei ’18 71