1. Architecting systems for continuous delivery
7/17/2018 6:32 AM
Architecting systems for continuous delivery
Marcel de Vries
CTO, Xpirit
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. Agenda 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
Further reading

3. Current Architectural Challenges of CD
All software components need to be delivered as one cohesive set
Partial updates not possible
Better known as the monolith
All changes are in one huge code repository
Long lived branches, merge hell
Test process takes 2 months to verify regression and new features
We are forced to use technology and tools that don’t fit our needs

4. Smaller shippable units
What is the architecture of your system?
Monolith
SOA ?

5. Monolith Dependencies Deployment strategy Scaling strategy Monitoring
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

6. SOA Dependencies Deployment strategy
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

7. Which Service owns this page?

8. None!

9. Composition is key!

10. Microservices architecture

11. Decreasing hard coupling between (sub) systems
Coincidental cohesion (worst)
random
Logical cohesion
same in nature
Temporal cohesion
executed at a particular time
Procedural cohesion
part of fixed execution sequence
Informational cohesion
operating on the same data
Sequential cohesion
Output of one is used as input by another
Functional cohesion (best)
contributing to a single task

12. Defining Microservices
Finding Autonomous Business Capabilities
Low Coupling
Components are completely insensitive to changes and errors in other components.
No Coupling
Error and changes seldom propagate errors and changes to dependent components
Low Coupling
Errors and changes in one component almost always propagate to other components
High Coupling

13. Bounded contexts

14. 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

15. 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)

16. Zero downtime deployments

17. Circuit Breaker Pattern
Handle faults that may take a variable amount of time to rectify when connecting remote service or resource.
This pattern can improve the stability and resiliency of an application.

18. 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.

19. Reset your defaults

20. Classical Approach Automated Testing
Unit testing
Integration testing
Manual testing
CD tells us: Automate everything….
Move to more automation
Manual testing -> Use of UI Automation tools

21. “There is no place like Production”
Source: Brian Harry, Microsoft Technical Fellow

22. Choosing the right scale unit is crucial
Testing in production
SU1
SU2
SU3
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Choosing the right scale unit is crucial
to enable this concept
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

23. Recap Decompose your system in more independent deployable units
ABC’s
Strive for functional Cohesion
Adapt event driven style of communication
Make services failure resilient
Rethink the way systems are tested and implications on your systems architecture
MSA is not the goal, it’s a means and you will pay a premium to get it in place!

24. Further reading Microservice architecture, Sam Newman
Domain Driven Design, Eric Evans
Microservices, Martin Fowler
Continuous Delivery. Jez Humble
Xpirit magazine

25. Xpirit mdevries@xpirit.com Fluentbytes.com @marcelv
7/17/2018 6:32 AM
Xpirit
All Photos used in this presentation come from unsplash.com
Fluentbytes.com
@marcelv
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

26. Xpirit xpir.it/XpiritMagazine mdevries@xpirit.com Fluentbytes.com
Building a CD pipeline with VS 2015
Test Automation with CodedUI
Testing Web Applications with CodedUI
Introduction to Docker on Windows with Visual Studio 2017
All Photos used in this presentation come from unsplash.com
Fluentbytes.com
@marcelv

27. Please evaluate this session Your feedback is important to us!
7/17/2018 6:32 AM
Please evaluate this session Your feedback is important to us!
The slide will be replaced onsite through Silver Fox Productions with an updated QR code.
This slide is required. Do NOT delete or alter the slide.
From your PC or Tablet visit MyIgnite at
From your phone download and use the Ignite Mobile App by scanning the QR code above or visiting
© 2014 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

28. 7/17/2018 6:32 AM
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.