APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes All? by Rod Cope, Akana by Perforce
•Transferir como PPTX, PDF•
0 gostou•78 visualizações
Microservices vs Miniservices vs Monoliths: Winner Takes All? Rod Cope, CTO at Akana by Perforce
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes All? by Rod Cope, Akana by Perforce
Semelhante a APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes All? by Rod Cope, Akana by Perforce (20)
Mais de apidays
Mais de apidays (20)
Último
Último (20)
APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes All? by Rod Cope, Akana by Perforce
- 1. JRebel by Perforce © 2019 Perforce Software, Inc. Microservices vs. Miniservices vs. Monoliths: Winner Takes All? ROD COPE, CTO
- 2. akana.com2 | Akana by Perforce © 2019 Perforce Software, Inc. Rod Cope Bio: • Perforce CTO • Rogue Wave Software CTO • Founder and CTO of OpenLogic • 25+ year software career includes IBM, IBM Global Services, General Electric, and Anthem Blue Cross/Blue Shield. • Worldwide event speaker, including: DeveloperWeek, OSCON, Embedded World, ApacheCon, Strata/Big Data, LinuxCon, and APIdays.
- 4. akana.com4 | Akana by Perforce © 2019 Perforce Software, Inc. Option A: Monolith
- 5. akana.com5 | Akana by Perforce © 2019 Perforce Software, Inc. Option B: Microservices
- 6. akana.com6 | Akana by Perforce © 2019 Perforce Software, Inc. Option C: Miniservices
- 13. Monolith
- 14. akana.com14 | Akana by Perforce © 2019 Perforce Software, Inc.
- 15. akana.com15 | Akana by Perforce © 2019 Perforce Software, Inc. Component Interaction http://serena-yeoh.blogspot.com/2014/01/layered-architecture-components.html
- 16. akana.com16 | Akana by Perforce © 2019 Perforce Software, Inc. Three-Tier Architecture www.SoftwareTestingMaterial.com
- 17. akana.com17 | Akana by Perforce © 2019 Perforce Software, Inc. martinfowler.com
- 18. akana.com18 | Akana by Perforce © 2019 Perforce Software, Inc. Monolith: culture 1 Traditional command and control One big team (or devs vs DBAs) Waterfall-ish Big design up front, integration testing Slow deployment cadence Vertical scalability
- 19. akana.com19 | Akana by Perforce © 2019 Perforce Software, Inc. Monolith: culture 2 Agile or scaled agile Feature teams Frequent, automated integration testing Horizontal scalability
- 20. akana.com20 | Akana by Perforce © 2019 Perforce Software, Inc. Versioning issues Latency Monolith: Advantages
- 21. akana.com21 | Akana by Perforce © 2019 Perforce Software, Inc. Monolith: Advantages 2
- 22. akana.com22 | Akana by Perforce © 2019 Perforce Software, Inc. Monolith: Advantages 3 One Code base Set of artifacts Build process Language Platform Toolchain
- 23. akana.com23 | Akana by Perforce © 2019 Perforce Software, Inc. Monolith: challenges • No small changes • Technology lock-in • Scale all or nothing • Heavyweight deployment • Version coordination • Bug affects entire app • Container concerns
- 24. akana.com24 | Akana by Perforce © 2019 Perforce Software, Inc. Monolith: Best Practices • Agile • DevOps • Layers and modules • Horizontal scaling • Development accelerators
- 25. Services
- 26. akana.com26 | Akana by Perforce © 2019 Perforce Software, Inc. SOA: Service- Oriented Architecture • Service: • Logical business activity • Self-contained • Black box for its consumers • Distributed, separately-maintained and deployed • Not SOAP, ESB, WS-*, heavy process, central control, vendor lock-in
- 27. Microservices
- 28. akana.com28 | Akana by Perforce © 2019 Perforce Software, Inc. Microservices in a Nutshell UNIX PHILOSOPHY: “DO ONE THING AND DO IT WELL” SOA FOR DISTRIBUTED TEAMS IN A WORLD OF DEVOPS BOUNDED CONTEXT AND DOMAIN-DRIVEN DESIGN (DDD)
- 29. akana.com29 | Akana by Perforce © 2019 Perforce Software, Inc. martinfowler.com
- 30. akana.com30 | Akana by Perforce © 2019 Perforce Software, Inc. martinfowler.com
- 31. akana.com31 | Akana by Perforce © 2019 Perforce Software, Inc. martinfowler.com
- 32. akana.com32 | Akana by Perforce © 2019 Perforce Software, Inc. martinfowler.com
- 33. akana.com33 | Akana by Perforce © 2019 Perforce Software, Inc. Microservices: Characteristics Processes talking over network Maybe IPC like shared mem Maybe same process like OSGi bundles (like Akana) Independently deployable Easy to replace Organized around capabilities (UI, suggestions, billing) Independent implementation (language, platform, data) Small, message enabled, context bounded, autonomously developed, decentralized Built and released with automated processes Elastic, resilient, composable, minimal, and complete
- 34. akana.com34 | Akana by Perforce © 2019 Perforce Software, Inc. • Cannot share data storage • Ideally no inter-service communication via REST/HTTP • No synchronous communication to prevent cascading timeouts • All async messaging • Eventual consistency • Compensating operations Loosely Coupled
- 35. akana.com35 | Akana by Perforce © 2019 Perforce Software, Inc. SOA manifesto (2009) Microservices philosophy (2019) Business value Technical strategy
- 36. akana.com36 | Akana by Perforce © 2019 Perforce Software, Inc. SOA manifesto (2009) Microservices philosophy Business value Technical strategy Strategic goals Project-specific benefit
- 37. akana.com37 | Akana by Perforce © 2019 Perforce Software, Inc. SOA manifesto (2009) Microservices philosophy Business value Technical strategy Strategic goals Project-specific benefit Intrinsic interoperability Custom integration
- 38. akana.com38 | Akana by Perforce © 2019 Perforce Software, Inc. SOA manifesto (2009) Microservices philosophy Business value Technical strategy Strategic goals Project-specific benefit Intrinsic interoperability Custom integration Shared services (reuse) Specific-purpose implementation
- 39. akana.com39 | Akana by Perforce © 2019 Perforce Software, Inc. SOA manifesto (2009) Microservices philosophy Business value Technical strategy Strategic goals Project-specific benefit Intrinsic interoperability Custom integration Shared services (reuse) Specific-purpose implementation Flexibility over optimization Flexibility over optimization
- 40. akana.com40 | Akana by Perforce © 2019 Perforce Software, Inc. SOA manifesto (2009) Microservices philosophy Business value Technical strategy Strategic goals Project-specific benefit Intrinsic interoperability Custom integration Shared services (reuse) Specific-purpose implementation Flexibility over optimization Flexibility over optimization Evolutionary refinement Evolutionary refinement
- 41. akana.com41 | Akana by Perforce © 2019 Perforce Software, Inc. SOA manifesto (2009) Microservices philosophy Business value Technical strategy Strategic goals Project-specific benefit Intrinsic interoperability Custom integration Shared services (reuse) Specific-purpose implementation Flexibility over optimization Flexibility over optimization Evolutionary refinement Evolutionary refinement
- 42. akana.com42 | Akana by Perforce © 2019 Perforce Software, Inc. Microservices: Advantages SMALL PROBLEMS SMALL TEAMS SMALL SOLUTIONS BEST TOOLS FOR THE JOB
- 43. akana.com43 | Akana by Perforce © 2019 Perforce Software, Inc. Microservices: decisions Service mesh / proxy Communication State management Coordination Deployment Operations
- 44. akana.com44 | Akana by Perforce © 2019 Perforce Software, Inc. Microservices: challenges Distributed computing 01 Cognitive load 02 Service explosion 03 Team dynamics 04
- 45. akana.com45 | Akana by Perforce © 2019 Perforce Software, Inc. Fallacies of Distributed Computing 1. Network is reliable 2. Latency is zero 3. Bandwidth is infinite 4. Network is secure 5. Topology doesn’t change 6. There is one administrator 7. Transport cost is zero 8. Network is homogenous
- 46. akana.com46 | Akana by Perforce © 2019 Perforce Software, Inc. Fallacies of Distributed Computing 1. Network is reliable 2. Latency is zero 3. Bandwidth is infinite 4. Network is secure 5. Topology doesn’t change 6. There is one administrator 7. Transport cost is zero 8. Network is homogenous
- 47. akana.com47 | Akana by Perforce © 2019 Perforce Software, Inc. Microservices: culture Automation True DevOps Embrace Failure
- 48. akana.com48 | Akana by Perforce © 2019 Perforce Software, Inc. Microservices: Best Practices • Extreme automation • Service mesh • API management • Monolith first
- 49. akana.com49 | Akana by Perforce © 2019 Perforce Software, Inc. Security Mediation Transformation Orchestration Traffic management Analytics API service API service API service API management Security PoliciesTraffic management Telemetry Control plane Service mesh Microservice Sidecar Microservice Sidecar Microservice Sidecar • External focus • Central/one • Security • Stability • Internal focus • Decentral/many • Availability • Flexibility
- 50. akana.com50 | Akana by Perforce © 2019 Perforce Software, Inc. Microservices, Service Mesh, and MASA • Microservice: Bounded context, independent data store • Service mesh: Internal implementation fabric, coordination • Gartner MASA: Mesh App and Service Architecture Gartner
- 51. akana.com51 | Akana by Perforce © 2019 Perforce Software, Inc. martinfowler.com
- 52. akana.com52 | Akana by Perforce © 2019 Perforce Software, Inc. martinfowler.com
- 53. akana.com53 | Akana by Perforce © 2019 Perforce Software, Inc. API & Service Mesh Summary • API management & service mesh address different needs • Both critical for microservice architecture • No one-size-fits-all solution • Current best of breed: Commercial API management Open source service mesh
- 54. Miniservices
- 55. akana.com55 | Akana by Perforce © 2019 Perforce Software, Inc. Miniservices • One function • Bundle of microservices • Fat container • Relaxes some constraints • Data store sharing • Sync & HTTP
- 56. akana.com56 | Akana by Perforce © 2019 Perforce Software, Inc. Miniservices • One function • Bundle of microservices • Fat container • Relaxes some constraints • Data store sharing • Sync & HTTP
- 57. akana.com57 | Akana by Perforce © 2019 Perforce Software, Inc. Miniservices: advantages Less culture shock Business value over architectural purity Traditional web communication
- 58. Best tool for the job
- 59. akana.com59 | Akana by Perforce © 2019 Perforce Software, Inc.
- 60. akana.com60 | Akana by Perforce © 2019 Perforce Software, Inc. Grok: Mono/ Macro Mini Micro Code Architecture ? ? ✕ Reuse ✕ Change ✕ ? Deploy ? ? Versioning ? ✕
- 61. akana.com61 | Akana by Perforce © 2019 Perforce Software, Inc. Conclusion •One-size-fits-all is wrong •Consider your needs • Your problem • Your team • Your timeframe
- 62. akana.com62 | Akana by Perforce © 2019 Perforce Software, Inc. Questions?
- 63. akana.com63 | Akana by Perforce © 2019 Perforce Software, Inc. Akana QuickStart S U G G E S T E D P A C K A G E : 250 Gb/month Total bandwidth in/out of the gateway Learn more at akana.com/akana-quickstart Regardless of your size, you still have the same tech requirements. The new Akana SaaS Club gives you our full-featured enterprise API management solution – without the investment or implementation time. QuickStart packages are right-sized to your needs. As you grow, we’ll grow with you! Get started with Akana API Management faster and more affordably than ever before.
Notas do Editor
- Introduction during this slide
- It’s big, it’s bulky, it’s hard to update, but you can kinda figure out what it’s trying to do. It’s the Monolith.
- They’re tiny, they only do one thing, they’re easy to replace and upgrade, but you have to monitor them constantly and good luck trying to see the big picture. They’re microservices.
- They’re different sizes ranging from big to huge, they’re legacy and modern all mixed together, and they make a purist’s head swim, but they’re very practical. They’re macro and miniservices.
- Could be clean layers with excellent software architecture…
- If UI tightly coupled to business logic layer which is tightly coupled to the database, this is another form of “monolith” Can also think of the business logic layer itself as a monolith No parts are easily reusable (if at all) Changes to any part ripple throughout entire app Can’t scale individual functions without scaling everything
- TX: no XA, Saga, or other excruciating pain
- Change: - May need to involve UI, business logic, and database teams to make a small change - May require too much knowledge for one person to make a change alone Lock-in: not easy to change languages, platform, tools, etc Deployment - Big machines, lots of disk, complex configuration (RAID, clustering, HA, etc.) - big/manual installation process is common Must coordinate all teams, dependencies, versions before integrating/deploying Easy to get out of sync with staging environment – need scrubbed prod data, but hard to get securely
- Before jumping into *services, let’s talk about how it all got started: SOA.
- Term coined 2011, used more in 2014. An e-commerce site might have a “get shipping price” microservice.
- Conway’s Law
- Term coined 2011, used more in 2014
- Consider workflow systems (e.g., Camunda) instead of rolling your own state machines and Saga patterns.
- Evolutionary refinement over initial perfection
- Evolutionary refinement over initial perfection
- Evolutionary refinement over initial perfection
- Evolutionary refinement over initial perfection
- Evolutionary refinement over initial perfection
- Evolutionary refinement over initial perfection
- Evolutionary refinement over initial perfection
- Small problems: easier to understand, explain, innovate, communicate Small teams: agile, less communication overhead on each team, teams own dev, QA, operations, and support Small solutions: faster dev, QA, debugging, deployment, smaller resource footprint, fault isolation Best tools for the job: Each service can be implemented with best fit: language, framework, platform, data store, build & dev tools, easier to evolve over time (add/replace services using latest tech stacks)
- Communication: allow sync? Resiliency patterns? Sync: considered harmful due to multiplying downtime (cascading timeouts) Protocols: REST, HTTP, messaging, gRPC? State management: eventual consistency, Saga pattern, Kubernetes StatefulSets, AWS services, data stores on VM’s Cross-team coordination: versioning, SLA’s, status, notification procedures, service replacement/responsibility splitting and changes, deploying features that require changes to multiple services Deployment: Kubernetes, serverless, nanoservices, service mesh Operations: logging, tracing, monitoring, metrics, reporting
- Cognitive load: Function call network latency, message formats, load balancing, fault tolerance Code bakes in assumptions about environment that may be out of date Service explosion Big picture, catalog, searchable registry, duplication Lots of tech ecosystems, implementation languages, etc. – cognitive load Team dynamics: easy to focus on your own serve to detriment of overall project
- Automation: Too many moving parts for manual intervention/workflow DevOps: Development team supports services in production, deep monitoring w/triggers, self-healing (e.g., Kubernetes scheduling), anti-fragility, etc. Embrace failure: Constant state of partial failure is the norm in a large busy system – need timeouts, retries, circuit breakers, bulkheads, and the like
- API management: required for any solution that exposes API’s to the public Internet and extremely useful even for internal-only API’s.
- E-commerce site might have a ”shopping cart” miniservices that provides availability, pricing, and shipping capabilities. Data store sharing: transactions become much easier (possible), fewer issues with eventual consistency
- E-commerce site might have a ”shopping cart” miniservices that provides availability, pricing, and shipping capabilities. Data store sharing: transactions become much easier (possible), fewer issues with eventual consistency
- Culture: Extended team doesn’t have to relearn everything they know about application development and deployment (don’t pay the ”microservice premium”) Business value: develop and deploy services independently, but don’t sweat the details of perfect functional decomposition and granularity of every inner API (e.g., can break “bounded context” restriction for convenience/performance/orchestration/maturity). Most important: can share data sources! Communication: not forced into completely async, message-driven, full isolation, service mesh-based architecture