Continuous Delivery with Cloud Foundry

Expanded version of the deck from my talk at Platform September 2013.
http://www.youtube.com/watch?v=gjr-nGbWq48

Transcript

2. Continuous Delivery with Cloud Foundry
3. Overview • Refresher on the concepts behind CD and why. • How Cloud Foundry is a great fit for Continuous Delivery. • Practical Concerns. • Anti-patterns to watch out for. • Deployment pipeline for the PaaS itself. 3
4. CloudCredo London
5. Deployment Pipeline • The central concept of Continuous Delivery is the deployment pipeline. • Our code is going to pass through a series of automated gates, each more rigorous than the last to see if it is deployable. • We progress from checks that are very quick to run (like unit tests) through to checks that are slower but more comprehensive (like standing up multiple nodes for integration testing). 5
6. 6 realness -> time -> Deployment Pipeline
7. Refresher: Why are we doing this?
8. 8 ⟳
9. Feedback • What we’re actually trying to do is gain feedback on our changes. • We want to minimize the amount of time it takes to gain feedback on our changes. • If we can reduce the cycle time between making a change and observing the result then we can iterate quickly closer and closer towards something that the customer wants. • Making changes repeatably like this implies a high level of discipline and automation. 9
10. Value • If we take a step back what we’re actually trying to do is deliver a working service to our customers. • If we could do that without having to pay lots of money for expensive software development then we would. • We could have a technically beautiful pipeline with lots of automation but if we’re not receiving real feedback it’s all pointless. • What’s really valuable is the ability to get changes out there and get feedback. 10
11. Cloud Foundry
12. Why Cloud Foundry? • We’ve said we want to avoid doing unnecessary work. So why are we using Cloud Foundry? It’s a complex piece of software. • One reason is to avoid having to manage infrastructure directly. I don’t have to be familiar with Puppet or Chef or write custom deployment scripts for my applications. • I don’t have to think about configuring networking or load balancing. I don’t want to be swamped by deployment concerns. • We gain standardization benefits and avoid each team independently solving the same problem in a bespoke way. 12
13. Consistent Interface for Deployment $ cf push 13
14. CLI • Wiring up Jenkins to deploy to Cloud Foundry is very straightforward. • I can use the same command to deploy my application, regardless of stack. • If I’m a Java developer who is just getting started with Ruby I can learn enough to write a simple Sinatra app and deploy it without having to learn all about how you deploy Ruby apps. • I’m able to focus on delivery of the application without having to make a large number of deployment decisions and implement them. 14
15. Convenient Abstraction • As a developer I must still understand the environment that my application runs in. • This is crucial to being able to diagnose and solve production issues. • With Cloud Foundry I get the ability to build to a convenient abstraction, but also importantly the ability to pull of the lid and see how it all works if I need to problem solve. • That’s why an Open Source PaaS is so important. 15
16. Avoid making breaking changes that delay feedback 16
17. Feedback • We deployed an application to Cloud Foundry on the first day of a project. • There was some disappointment when the customer quickly pointed out some things that needed fixing. • But the value comes from getting that feedback early. • We didn’t spend lots of time building something that was on the wrong track. 17
18. cloudfoundry.com » 18 Feedback
19. decomposed the application into services » 19 Feedback
20. custom release » 20 Feedback
21. multiple platforms, multi-region » 21 Feedback
22. 600,000 transactions in 7 hours 22 Feedback
23. 500 user journeys every second 23 Feedback
24. 10,000 call center operators 24 Feedback
25. ♥beat 25 Feedback
26. Heartbeat • Throughout all of these changes to the underlying platform there was a steady heartbeat of delivery. • Jenkins continued to see the same simple interface as we scaled from a small number of instances on cloudfoundry.com to a platform that spanned multiple AWS regions and a London-based vSphere provider. • We never had a lengthy ‘stop the world I’m refactoring everything’ moment. 26
27. Production-like Environment
28. Production-like Environment • Every difference between your environments (development, UAT, staging) is another reason for your application to break. • I can deploy the same way to every environment using the consistent interface we’ve already talked about. • We can use the built-in organizations and spaces features in Cloud Foundry to create separate environments. • We can reproducibly build isolated production-like environments using BOSH. 28
29. Build and scale new environments repeatably 29 Environments
30. Build and scale repeatably • Increasing the number of application instances on an existing Cloud Foundry platform is trivial. Cloud Foundry takes care of ensuring that all instances are up and running. • BOSH works declaratively and converges to a desired state - but at the level of my whole platform. I can very easily scale up the resource provided by the PaaS. • The BOSH manifest is held in source control and I can build environments repeatably. 30
31. Perform load testing within your pipeline 31 Environments
32. Load Testing • One of the interesting effects of being able to scale up and down so easily is the ability to bring up larger platforms for short periods of time for Load Testing. • Load Testing is no longer an event that takes place rarely and infrequently - it’s another gate in my deployment pipeline. • It is now cost-effective to gain feedback with production-sized environments and tear them down again. 32
33. Externalizing Configuration 33 Environments
34. Externalizing Configuration • A common anti-pattern is to bake environment-specific configuration or logic into your application. • Any testing or feedback you gained in other environments is invalidated because you are not testing the same artifact. • Cloud Foundry helps you here by pushing you towards externalizing configuration. • Service connection details are injected into your application. • Environment variables are the standard for configuring your application. 34
35. 12factor.net 35 Environments
36. Reproducible Environments 36 Environments
37. Reproducible Environments • Our application may be the same between all environments but that’s no good if the environments themselves are not reproducible. • We need the combined state of both the application and the environment it is running in to be reproducible, otherwise we can’t say with confidence that we can deploy a working service. 37
38. Reproducible Environments • Cloud Foundry is great here because we can run on the same base platform and gain isolation through the built-in primitives. • If we build separate Cloud Foundry instances for different environments then BOSH ensures that our environments are reproducible from source code. • With BOSH we get a single manifest file that defines the entire environment, and we can diff this easily to see any differences between environments. • If we’re for any reason unsure about a platform we can shoot it and build another one. 38
39. Artifact Repositories 39 Environments
40. Artifact Repositories • Our service is not reproducible if we depend at build or deployment time on artifacts outside of our control. • You might use Nexus to proxy Java libraries to ensure your application can be built if libraries become unavailable. • In the same way BOSH has an artifact repository - the Blobstore. 40
41. Blue / Green Deployments 41 Environments
42. Things to watch out for
43. Manual application changes 43 Gotchas
44. Manual application changes • Because it’s so easy to deploy applications with Cloud Foundry it may be tempting for developers to go around the deployment pipeline to deploy or making config changes. • Similarly I may be able to tunnel through to services and make manual one-off changes. • Don’t do this! As soon as you make a manual change you lose the ability to look at changes in source control and reason about the current state of your platform. 44
45. Branching Deployments 45 Gotchas
46. Branching Deployments • Long-running code branches are bad because you will likely fail to integrate with changes on the mainline branch. • By having a separate version of the software you’re requiring future effort to perform a merge. Any feedback you gain before the merge is problematic because it’s not against the mainline. • Cloud Foundry makes it similarly trivial to branch deployments and deploy multiple versions of your application. • Just because it is easy, doesn’t mean it is a good idea. 46
47. Adding infrastructure code to the pipeline
48. 48 Application Code Infrastructure Code Base OS Your service
49. Infrastructure dependencies • In Cloud Foundry terminology the Base OS is your BOSH Stemcell and the Infrastructure Code is Cloud Foundry itself. • Each layer has dependencies on the others - so if you change the code that builds the BOSH Stemcell then you need to revalidate that everything above it behaves correctly. • This is very similar to the problem of building libraries that depend on each other and a natural fit for Jenkins to trigger related builds. 49
50. ✔ Validation of BOSH Manifests 50 Infrastructure code
51. BOSH Manifest Validation • At the simplest level check whether the manifest is well- formed YAML. • You can also do more semantic validation of the manifest, for example are the IP addresses in the manifest valid for the expressed ranges? 51
52. ⊖ Automate upload of BOSH releases 52 Infrastructure code
53. Key Takeaways • Cloud Foundry makes building continuous delivery pipelines much easier. • Cloud Foundry makes it easy to Do the Right Thing. • PaaS abstraction allows you to grow from small-scale to large scale and maintain a steady heartbeat of delivery. 53
54. Thanks! andrew@cloudcredo.com