Downloaded 185 times
![Do SOA Anti-Patterns Prevail?
Symptoms
๏Isolation, Uniqueness, Duplication
๏Tight Coupling and Build Again
Cause
๏Lack of Trust - Not Invented Here [NIH]
๏Shared Service Invisibility
๏ Teams do not know about a service
๏ Non-functional and functional requirements are not well documented
9](https://image.slidesharecdn.com/microservices-2014-0915-v1-150308180545-conversion-gate01/85/Merging-microservices-architecture-with-SOA-practices-9-320.jpg)
![Fragility and Anti-Fragility
๏ Failover Strategies
๏ Load Balancers – route to available nodes
๏ Watchdog Health Monitors - identify break points
๏ Circuit breakers [https://github.com/Netflix/Hystrix ]
๏ Infrastructure
๏ Intelligent Content Routing
๏ Topics / Queues
๏ Management Scripts – restart service instances
๏ PaaS Service Management
28](https://image.slidesharecdn.com/microservices-2014-0915-v1-150308180545-conversion-gate01/85/Merging-microservices-architecture-with-SOA-practices-28-320.jpg)
![Do SOA Anti-Patterns Prevail?
Symptoms
๏Isolation, Uniqueness, Duplication
๏Tight Coupling and Build Again
Cause
๏Lack of Trust - Not Invented Here [NIH]
๏Shared Service Invisibility
๏ Teams do not know about a service
๏ Non-functional and functional requirements are not well documented
9](https://image.slidesharecdn.com/microservices-2014-0915-v1-150308180545-conversion-gate01/75/Merging-microservices-architecture-with-SOA-practices-9-2048.jpg)
![Fragility and Anti-Fragility
๏ Failover Strategies
๏ Load Balancers – route to available nodes
๏ Watchdog Health Monitors - identify break points
๏ Circuit breakers [https://github.com/Netflix/Hystrix ]
๏ Infrastructure
๏ Intelligent Content Routing
๏ Topics / Queues
๏ Management Scripts – restart service instances
๏ PaaS Service Management
28](https://image.slidesharecdn.com/microservices-2014-0915-v1-150308180545-conversion-gate01/75/Merging-microservices-architecture-with-SOA-practices-28-2048.jpg)
Uploaded byChris Haddad
Merging microservices architecture with SOA practices
This document summarizes Chris Haddad's presentation on merging microservices architecture with SOA practices. The presentation discusses how microservices can help overcome common issues with SOA implementations, such as tight coupling and duplication. It defines microservices and compares them to traditional SOA approaches. The presentation also covers best practices for defining, decoupling, and deploying microservices as well as DevOps patterns that can help overcome challenges in deploying microservices architectures at scale.
More Related Content
Similar to Merging microservices architecture with SOA practices
Merging microservices architecture with SOA practices
- 1. VP Platform Evangelism ChrisHaddad Merging microservices architecture with SOA practices 15 September 2014
- 2. 2 About the Presenter •ChrisHaddad ๏ VP Platform Evangelism ๏ F500/G2000 Advisor ๏ Cloudy DevOps for Dev guy ๏ API Strategy and SOA Roadmap consultant ๏ Former Gartner research team leader Architect ๏ SaaS and PaaS ๏ Service portfolio and infrastructure ๏ Data management ๏ Java, .NET, JavaScript, Open Source Learn more about me • Follow me @cobiacomm on Twitter • Blog: http://blog.cobia.net/cobiacomm • Decks: http://www.slideshare.net/cobiacomm/ • Profle: http://www.linkedin.com/in/cobiacomm/ • On Google+ too
- 3. Agenda •Service Success andService Angst • Are microservices the answer? •Microservice Mindset • How to properly define, decouple, and size a microservice. • What DevOps practices overcome microservice deployment roadblocks • When microservices create fragile instead of antifragile building blocks 3
- 4. Service Success –Extend Legacy Reach 4
- 5. Service Success –Extend Business Reach
- 6. Service Success –Useful Service Blocks 6
- 7. Service Success –Agility at Scale ๏ How do you measure agility? ๏ Have services increased your agility? ๏ Does IT service agility exist? http://blog.cobia.net/cobiacomm/2013/03/19/accelerating-business-agility-with-app-factory-devops-paas/
- 8.
- 9. Do SOA Anti-PatternsPrevail? Symptoms ๏Isolation, Uniqueness, Duplication ๏Tight Coupling and Build Again Cause ๏Lack of Trust - Not Invented Here [NIH] ๏Shared Service Invisibility ๏ Teams do not know about a service ๏ Non-functional and functional requirements are not well documented 9
- 10. Tired of BigSOA?๏ Set up a cross-functional SOA Working Group ๏ Develop a SOA Adoption Plan ๏ Define Target Service Portfolio ๏ Develop a Business Case ๏ Plan and Fund Development of SOA Infrastructure ๏ Establish New Roles ๏ Plan Training and Mentoring for Staff ๏ Develop Corporate Policies, Guidelines, and Best Practices ๏ Institute SOA Governance Processes ๏ Establish New Incentives that Reward Good Behavior ๏ Identify Candidate Projects ๏ Establish Priorities ๏ Reassess Your Software Development LifeCycle (SDLC)10
- 11. Can we MicroSizeSOA 11
- 12. Be Like Mike!– aka NetFlix 12
- 13. Microservices to theRescue Microservices Defined ๏A small problem domain ๏Built and deployed by itself ๏Runs in its own process ๏Integrates via well-known interfaces ๏Owns its own data storage 13 Source: http://www.brunton-spall.co.uk/post/2014/05/21/what-is-a-microservice-and-why-does-it-matter/
- 14. Microservices to theRescue “designing software applications as suites of independently deployable services.” Common Characteristics ๏organization around business capability ๏automated deployment ๏intelligence in the endpoints ๏decentralized control of languages and data Source: Martin Fowler http://martinfowler.com/articles/microservices.html 14
- 15. Microservices Scope ๏ CoarseGrained, Atomic, Business Capability ๏ Example ๏ Customer Profile ๏ Product Catalogue ๏ Shopping Cart ๏ Account Activity ๏ Ratings ๏ Recommendations / Reviews 15
- 16. SOA == Microservices ๏Services expose a business capability ๏ Factor applications into composable services ๏ Re-use service building blocks ๏ DRY (Don’t Repeat Yourself) ๏ Shared service delivery ๏ “Microservices is SOA, for those who know what SOA is” Source: Steve Jones 16
- 17. SOA != Microservices SOA ๏ServicesDeployed in a Shared Bus ๏One Team Goal ๏Centralize Mediation ๏Not prescriptive on the back- end implementation pattern 17 Micro-services ๏Services Deployed at the Edge ๏Teams aligned with Business Units ๏Dumb Infrastructure ๏Prescribes back-end implementation pattern “SOA is a lame enterprise approach, whereas microservices are a cool hacker approach.” Source: Ycombinator
- 18. Microservice Roadblocks ๏ Howbig is a micro-service? (UX-first approach, data domain approach) ๏ How decoupled is a micro-service? (Dependencies, versioning, routing, linking data) ๏ How to micro-size a business capability (granularity, user experience composition) ๏ How to take a RESTful approach towards managing micro-service dependencies (DNS, /etcd, load balancing) 18
- 19. Microservice Myths and Legends ๏The NetFlix Legend – QoS and rapid delivery ๏ Micro-services Foster Rapid Evolution ๏ Agility, Creative Experimentation, and Dynamic Composition ๏ Silos are good (if Micro-serviced) ๏ Containerization Panacea ๏ Lifecycle Complexity is Overblown ๏ Micro-services don’t require SOA principles to succeed 19
- 20. Agenda •How to properlydefine, decouple, and size a microservice. •What DevOps practices overcome microservice deployment roadblocks •When microservices create fragile instead of antifragile building blocks 20
- 21. DevOps Practices Microservices Pre-requisites ๏Business Domain Responsibility Decomposition ๏ User Interface Integration ๏ Communication Protocols ๏ Data Formats ๏ Redundant Data ๏ Business Intelligence Interfaces ๏ Root Cause Analysis (Logging, Monitoring) ๏ High Availability and Fault Tolerance ๏ Dynamic Service Management Adapted From: Stefan Tilkov http://www.infoq.com/presentations/Breaking-the-Monolith 21
- 22. DevOpS Patterns Loosely couple ๏Bounded Context ๏ Tolerant Reader ๏ Consumer driven Contracts ๏ Ubiquitous Language 22 Source: Martin Folwer http://martinfowler.com/articles/microservices.html#MicroservicesAndSoa
- 23. DevOpS Patterns Loosely couple ๏Bounded Context ๏ Tolerant Reader ๏ Consumer driven Contracts ๏ Ubiquitous Language ๏ Silos per business capability ๏ Separate database per product 23 Source: Martin Folwer http://martinfowler.com/articles/microservices.html#MicroservicesAndSoa
- 24. Agenda •How to properlydefine, decouple, and size a microservice. •What DevOps practices overcome microservice deployment roadblocks •When microservices create fragile instead of antifragile building blocks 24
- 25. Fragility and Anti-Fragility “Anti-fragilitydoes not merely withstand a shock but actually improves because of it.” ๏Redundancy ๏ Clustering, Service Farms ๏Failover ๏ Watchdog monitors , Circuit breakers 25
- 26. Fragility and Anti-Fragility “Anti-fragilitydoes not merely withstand a shock but actually improves because of it.” Achieve High Availability in Distributed Systems through: ๏Redundancy ๏Failover Traditional Service way ๏ Dedicated active-active, active-passive instances Micro-services way ๏ Dynamic instance provisioning, graceful degradation 26
- 27. Fragility and Anti-Fragility ๏Redundancy Strategies ๏ Clustering – maintain session state ๏ Service Farms – identical active nodes ๏ Infrastructure ๏ Load Balancers – route to available nodes ๏ Elastic service provisioning – spin up/down based on load and availability 27
- 28. Fragility and Anti-Fragility ๏Failover Strategies ๏ Load Balancers – route to available nodes ๏ Watchdog Health Monitors - identify break points ๏ Circuit breakers [https://github.com/Netflix/Hystrix ] ๏ Infrastructure ๏ Intelligent Content Routing ๏ Topics / Queues ๏ Management Scripts – restart service instances ๏ PaaS Service Management 28
- 29. Start Small ๏ ImplementSOA principles on a project-by-project basis ๏ Identify relationship between services and business capabilities ๏ Build a top-down and bottoms-up data model ๏ Work with your Enterprise Architecture Team 29
- 30. SOA & MicroservicesReconciliation ๏ When to create services ๏ Create a service when sharing a business capability ๏ When to create APIs ๏ Sharing a service outside a domain of control ๏ Targeting the widest possible reach and consumption ๏ Offering the service across native web infrastructure ๏ Maximizing asymmetric evolution between service clients, interface, and implementation. ๏ When to create and use microservices ๏ Building an application crossing domains ๏ Rationalizing and consolidating your SOA portfolio 30
- 31. 31 Accelerate Your ITBusiness Strategy with WSO2 Services
- 32. References ๏ SOA andAPI Convergence Strategy and Tactics ๏ Promoting service reuse within your enterprise and maximizin ๏ REST Easy: API Design, Evolution, and Connection ๏ Martin Fowler on Microservices ๏ Stefan Tilkov, Breaking the Monolith ๏ Brunton Sprall: What is a microservice and why does it matter 32
- 33.
Editor's Notes
- #2 Microservice architecture promises to pragmatically overcome service development hurdles by using a single responsibility pattern (SRP) and full-stack development teams. Do we now throw out SOA and integration practices? In this session, Chris Haddad will describe how you can rapidly build systems by adapting SOA practices, extending your DevOps toolchest, and defining microservices. You will learn: How to properly define, decouple, and size a microservice. What DevOps practices overcome microservice deployment roadblocks When microservices create fragile instead of antifragile building blocks
- #8 Business agility can be defined as your ability to rapidly change business vectors. A business vector is your business speed and direction. The direction may lead into nIew markets and new products, or engaging with new participants. Reducing time to IT solution delivery increases your team’s ability to adjust the business vector and match business opportunity. With adequate instrumentation, IT delivery agility can be quantified. Consider the following agility metric recommendations: Rapidly create project workspaces and environments Reduce time to build, integrate, test Streamline processes to approve, promote Automate deployment and releases Eliminate Dwell time – time waiting for the next operation to commence or complete After application project inception and before coding commences, systems administrators must create project workspaces. How long does your team wait before gaining access to source code management repositories, requirement management projects, and defect tracking projects? Moving code through build, integration, and test tools is often a time and labor-intensive process. The entire team waits while applications assets are built, integrated, and tested. When teams use iterative development processes, the wait time aggregates over several hundred or thousands cycles. How long does your team wait during build, integration, and test phases? When one team member finishes a task and the work enters an approval phase, how long does the team wait? After the work is approved to move through phase gate, how long before the project is promoted into the next phase?
- #9 SOA business perspective and API Economy echo SOA can be a strategy to align IT assets with business capabilities, business resources, and business processes. SOA’s strong focus on sharing and re-use can optimize IT asset utilization. Most intriguingly, SOA was promised to re-invent business-to-business interactions, enable better partner relationships, and support process networks. External services were seen as a mechanism to extend an enterprise’s economic reach by reducing interaction costs, incorporating external business capabilities, enabling business specialization, and creating higher-value solutions that extend business processes across a partner network. The current API economy buzz co-opts the SOA business value proposition, injects lessons learns, and rides popular industry trends (i.e. REST, Internet of Everything, mobile, Cloud services). The Only Sustainable Edge, John Hagel III & John Seely Brown, 2005 http://www.johnseelybrown.com/readingTOSE.pdf
- #14 Each microservice should be standalone, it should be possible to build and run the service in complete isolation from any other services or systems. Microservices are loosely coupled vertical stacks. Each microservice should communicate with other services via well known interfaces. The ability to own your own data model is the key to microservices in my mind Source: http://www.brunton-spall.co.uk/post/2014/05/21/what-is-a-microservice-and-why-does-it-matter/
- #15 Source: http://martinfowler.com/articles/microservices.html
- #16 Source: http://martinfowler.com/articles/microservices.html
- #30 A Small SOA approach implements SOA principles on a project-by-project basis. This approach incurs less risk, but produces a smaller return. Typically there’s limited coordination across projects, and Small SOA doesn’t require as much cultural, arm-twisting, or political unrest. Using a Small SOA process, the organization can slowly build a portfolio of services, but with limited coordination, the services are less likely to be reusable or shared across multiple consumers. Small SOA initiatives often focus on run-time environment concerns instead of design-time concerns. Popular run-time environment concerns include enabling flexible communication styles, interaction patterns, and mediation mechanisms that facilitate integration and promote loose coupling. Example communication styles include synchronous, asynchronous, one-way, and request response messaging. Commonly supported interaction patterns include peer-to-peer, brokered delivery, hub-and-spoke, publish/subscribe, and orchestrated workflow, which are used to bridge the gap between consumer-provider availability, reliability, and topology. Mediation mechanisms reduce the need to provide symmetric messaging platforms where both consumer and provider communicate using the same protocol, message format, and communication style. Mediation mechanisms also encapsulate implementation details related to location, versioning, and identity domain.
- #31 Create a service when sharing business capability or business data across network or run-time application boundaries. A service should implement a reasonably autonomous business task and not be designed as a fine-grained component with interdependencies on other components. Developers and business analysts are more likely to understand the purpose of the service when the service exposes a discrete task within a business process. Designing services for business task granularity reduces the complexity of the service interactions and simplifies application maintenance. Examples of business tasks that are compatible with a service-oriented approach include “submit order,” “retrieve customer record,” and “pay bill.” Create a RESTful API when sharing a service outside a domain of control (i.e. business unit, organization), targeting the widest possible reach and consumption, offering the service across native web infrastructure, or interested in maximizing asymmetric evolution between service clients, interface, and implementation.