Architecting systems for continuous delivery
2 likes3,828 views
The document discusses continuous delivery (CD) and its architectural implications, highlighting strategies for improving deployment speed and operational efficiency. It emphasizes the importance of smaller, independently deployable units, event-driven architectures, and automated testing to achieve zero downtime and better collaboration among development, operations, and business stakeholders. Additionally, it addresses the need for new thinking around releases and system monitoring to optimize the delivery process.
Architecting systems for continuous delivery
- 2. Marcel de Vries CTO Xpirit Architecting systems for Continuous delivery
- 3. About me: Marcel de Vries [email protected] @marcelv http://fluentbytes.comXpirit Also regional director
- 4. AGENDA • Continuous delivery maturity model – How fast do you need to go? • Architectural concepts to solve bottlenecks – Smaller shippable units – Decreasing hard coupling between (sub) systems – Enabling zero downtime deployments – Different thinking around releases – Different thinking around testing • Better operations by build in monitoring • Call to action
- 5. Source: http://www.infoq.com/resource/articles/Continuous-Delivery-Maturity-Model Where do you want to be? Where does your organization need to be?
- 6. How fast? • How often do you need to deploy? – Look at it from your organization perspective!
- 7. Gartner differentiation of systems Systems of Innovation Systems of Differentiation Systems of Records Innovative systems meant to introduce new concepts or new business High release cadence (Daily) System lifespan: 6 months to 3 year Support primary business functions (a.k.a. back office) Low release cadence (quarterly, half year release cycles) System lifespan: 10 to 20 years Deliver moderate competitive advantage Average release cadence (monthly-weekly) System lifespan : 3 to 5 year
- 9. Source: http://www.infoq.com/resource/articles/Continuous-Delivery-Maturity-Model Many of these items have Architectural implications
- 11. Valued business drivers Better • Resilient • Technology choice Cheaper • Test effort • Cost of maintaining Faster • Change • Deployment • Execution
- 12. Dev Test Acceptance Production Every step between silos adds waste & lead time to the delivery process Why are we doing this?
- 13. Forces on shipping Developer Project managers Tester OperationsThe Product Direction of shipping the product Business stakeholderBusiness stakeholder
- 14. How can we converge these forces to ship? • Operations: ensure we don’t break stuff. This has multiple sides: – Ship smaller increments, since less changes, less change of breaking stuff – Automate delivery to production, since most problems are caused by misconfiguration or wrong install – Build in monitoring so we can predict better how systems behave under certain conditions • Business stakeholder: Provide them faster flow of value, make them understand things can be delivered in increments and make them in control of what matters most for their business • Testers: proof you deliver a quality product
- 15. Architectural challenges of CD • Faster delivery by – Smaller shippable units – Decreasing hard coupling between (sub) systems – Enabling zero downtime deployments – Different thinking around releases – Different thinking around testing • Better operations by build in monitoring
- 17. ? SOAMonolith Smaller shippable units • What is the architecture of your system?
- 18. Monolith • Dependencies – All software is tightly coupled. Most often the system is build in the same software technology (e.g. .NET with C#) – Often one database with strong schema dependency • Deployment strategy – De-install, upgrade/migrate DB Schema, Install new version – System will be unavailable during deployment – Takes hours to complete • Scaling strategy – Scale up and out • Monitoring – Based on home grown monitoring tools Monolith
- 19. How do we compose systems? • We can create a monolith in various ways – Composed out of classes – Composed out of components – Composed out of services • When are these systems no longer a monolith? – When we use components & Services? • What defines the monolith is the way the system is composable and flexible – Can we add/remove parts without bringing the system down
- 20. SOA • Dependencies – Software can be in multiple technologies, communication via a Service Bus – Strong dependency on message schema’s – Strong dependency of services on Middleware technology • Deployment strategy – Per service • De-install, upgrade/migrate DB Schema, Install new version • System will be unavailable during deployment – Takes hours to complete & coordinated effort – Upgrades of ESB also requires coordinated effort SOA
- 21. SOA improved • SOA suffered from vendors pushing their broker software and making all services dependent on this piece of middleware • We see many examples where we have the ESB as the centralized piece of middleware – This often forces us to use one stack, or we need to add adapters to our services – Creates a single point of failure and often also a scalability challenge • What if we eliminate this broker and create a mesh of small services?
- 22. Enter the world of Microservices MSA
- 23. The many definitions of microservices - Small and focused on doing one thing well - Autonomous “Loosely coupled service oriented architecture with bounded contexts” Adrian Cockcroft (Netflix) “SOA done right” Anonymous “… 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.” Martin Fowler (Thoughtworks)
- 24. Services as a network of independent parts
- 26. Which Service owns this page?
- 27. None!
- 29. Decreasing hard coupling between (sub) systems
- 30. Using events to decouple services • Systems keep their own state • Events are used to notify changes • Systems use events to replicate data • Each service will have it’s own data store • Downsides: – Latency in data changes – No central control of business logic – Challenge to reconcile in case of disaster
- 31. Why are event driven architectures relevant?
- 32. Characteristics of EDA • Broadcast Model – Anyone can receive the events • Completely Asynchronous – publishers do not wait on any subscribers • Fine Grained Events – Individual events • Ontology – Hierarchy of events – Publishers can subscribe to these selected events Publisher Subscriber Subscriber Subscriber Subscriber Subscriber Subscriber Event Event Event
- 33. Cross-service coupling • Smart endpoints, dumb pipes • No intelligent middleware • Technologies to look at: – Queues (Azure, MSMQ, WebSphereMQ , ...) – Service Bus (NServiceBus, Azure ServiceBus, ...) – Language neutral data serialization (Google Protocol buffers, Apache Thrift)
- 35. Minimize downtime • Decompose the system into more granular parts that can be deployed independently – Better management of system dependencies • Dependencies on other Systems • Dependencies on own components/services • Dependencies on OS and infrastructure
- 36. Minimize downtime • Rethink how your application works • Traditional – When deploying we need to upgrade the Database schema • Downtime • Potential Solutions: – Use other database technologies that don’t require a strict schema – Make your system more flexible towards the DB schema, e.g. support multiple version of the schema – Upgrade the schema when the data is touched (just in time migration)
- 37. Minimize downtime • In SOA systems become less dependent on strict message schema – E.g. XML + CSD v.s JSON – Get rid of the ESB dependency • Cater for failure in downstream systems an provide fallback scenarios – Well known pattern here is e.g. Circuit breaker – Let systems fall back gracefully
- 38. Circuit Breaker Pattern • Handle faults that may take a variable amount of time to rectify when connecting remote service or resource. • to a – This pattern can improve the stability and resiliency of an application.
- 39. Retry Pattern • Enable an application to handle temporary failures when connecting to a service or network resource by transparently retrying the operation in the expectation that the failure is transient. This pattern can improve the stability of the application.
- 41. Use of feature flags/toggles • When you want to ship often, how do you cope with non finished features? • Traditionally you use feature branches to isolate – But what if you ship daily or weekly? • Break up the changes in independent parts that can be released separately – Use feature toggles/flags to enable or disable the feature – Give business control on who gets which feachures
- 42. Don’t build your own, many out there • If-Else • Nfeature (LGPL-3.0!, last update june 2012) • Feature Toggle (Apache 2.0, last update dec. 2014) • Feature Switcher (Apache 2.0, Last update Jan 2014) • FlipIt (Apache 2.0, Last update feb 2012) http://www.philjhale.com/2012/07/a-brief-look-at-some-feature-toggle.html
- 43. Different thinking about (Automated) testing
- 44. Classical approach • Unit testing • Integration testing • Manual testing • CD tells us: Automate everything…. – Move to more automation – Manual testing -> Use of UI Automation tools
- 45. “There is no place like Production” Source: Brian Harry, Microsoft Technical Fellow
- 46. Testing in production SU1 Feature SU2 SU3 Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Customer segment A <1000 Customer segment B <10000 Customer segment C All other Choosing the right scale unit is crucial to enable this concept
- 47. Test in production • A/B Testing is a simple example • Azure supports this out of the box – Put your new code in production – Throttle a small % of users to the new code – Watch behavior • Telemetry! – No issues? • Slowly move all users over • MS uses it extensively – VSO, Windows 10 insiders program, etc.
- 48. Better operations by isolation and build in monitoring
- 49. Hosting your services Host Application container Micro Service Micro Service Hosting in application container Host Micro Service Micro Service Micro Service Micro Service High density hosting Host Micro Service Host Micro Service Host Micro Service Host Micro Service One service per host
- 50. Services up and running OS Virtual machines PaaS Container runtimes
- 51. Monitoring build in Performance UsageAvailability Diagnostics Application Insights
- 52. Entering (Biz)DevOps • Multidisciplinary teams • “You build it, you run it” – No more ops needs to fix it, you do it your self! • Teams own a set of services • Coordination cross teams where required
- 53. Recap • Establish a reference point for your system where you need to go in CD – How fast do you need to go, no free lunch! • Think of the organizational implication, it’s not only technology • Decompose your system in more independent deployable units – Make services smaller – Rethink your dependencies between services – E.g. Adapt event driven style of communication – Make services failure resilient – Isolate them by minimizing environment dependencies – Ensure services can be monitored • Rethink the way systems are tested and implications on your systems architecture
- 54. Further reading • Microservice architecture, Sam Newman • Domain Driven Design, Eric Evans • Microservices, Martin Fowler • Continuous Delivery. Jez Humble • Xpirit magazine – Azure service fabric, Micro services articles
- 55. Your feedback is important! Scan the QR Code and let us know via the TechDays App. Laat ons weten wat u van de sessie vindt! Scan the QR Code via de TechDays App. Bent u al lid van de Microsot Virtual Academy?! Op MVA kunt u altijd iets nieuws leren over de laatste technologie van Microsoft. Meld u vandaag aan op de MVA Stand. MVA biedt 7/24 gratis online training on-demand voor IT- Professionals en Ontwikkelaars.