Downloaded 30 times
Uploaded byMarcel de Vries
Architecting systems for continuous delivery
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.
More Related Content
Similar to Architecting systems for continuous delivery
Architecting systems for continuous delivery
- 2. Marcel de Vries CTOXpirit Architecting systems for Continuous delivery
- 3. About me: Marcelde Vries mdevries@xpirit.com @marcelv http://fluentbytes.comXpirit Also regional director
- 4. AGENDA • Continuous deliverymaturity 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 doyou want to be? Where does your organization need to be?
- 6. How fast? • Howoften do you need to deploy? – Look at it from your organization perspective!
- 7. Gartner differentiation ofsystems 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
- 8.
- 9. Source: http://www.infoq.com/resource/articles/Continuous-Delivery-Maturity-Model Many ofthese items have Architectural implications
- 10.
- 11. Valued business drivers Better •Resilient • Technology choice Cheaper • Test effort • Cost of maintaining Faster • Change • Deployment • Execution
- 12. Dev Test AcceptanceProduction Every step between silos adds waste & lead time to the delivery process Why are we doing this?
- 13. Forces on shipping Developer Projectmanagers Tester OperationsThe Product Direction of shipping the product Business stakeholderBusiness stakeholder
- 14. How can weconverge 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 ofCD • 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
- 16.
- 17. ? SOAMonolith Smaller shippable units •What is the architecture of your system?
- 18. Monolith • Dependencies – Allsoftware 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 wecompose 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 – Softwarecan 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 • SOAsuffered 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 worldof Microservices MSA
- 23. The many definitionsof 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 anetwork of independent parts
- 25.
- 26. Which Service ownsthis page?
- 27.
- 28.
- 29. Decreasing hard coupling between(sub) systems
- 30. Using events todecouple 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 eventdriven 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 • Smartendpoints, 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)
- 34.
- 35. Minimize downtime • Decomposethe 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 • Rethinkhow 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 • InSOA 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 • Enablean 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.
- 40.
- 41. Use of featureflags/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 yourown, 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.
- 44. Classical approach • Unittesting • Integration testing • Manual testing • CD tells us: Automate everything…. – Move to more automation – Manual testing -> Use of UI Automation tools
- 45. “There is noplace like Production” Source: Brian Harry, Microsoft Technical Fellow
- 46. Testing in production SU1 Feature SU2SU3 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 byisolation and build in monitoring
- 49. Hosting your services Host Application container Micro Service Micro Service Hostingin 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 andrunning OS Virtual machines PaaS Container runtimes
- 51. Monitoring build in PerformanceUsageAvailability Diagnostics Application Insights
- 52. Entering (Biz)DevOps • Multidisciplinaryteams • “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 areference 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 • Microservicearchitecture, 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 isimportant! 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.