JavaOne 2015 - Swimming upstream in the container revolution
0 likes648 views
Bert Jan Schrijver discusses Malmberg's transition from traditional operations to a containerless continuous delivery model using DevOps principles. Some key challenges included cultural resistance to change, infrastructure limits with Amazon, and ensuring proper testing environments. The approach established expert teams, defined clear principles like infrastructure as code and no downtime, and benefited the business through increased agility, availability, and cost reductions. Areas of ongoing focus include monitoring, performance and security testing, and automated resilience testing.
JavaOne 2015 - Swimming upstream in the container revolution
- 1. Swimming upstream in the container revolution Containerless Continuous Delivery Bert Β Jan Β Schrijver @bjschrijverbertjan@jpoint.nl
- 2. Bert Jan Schrijver L Β e Β t Β β Β s Β Β m Β e Β e Β t @bjschrijver
- 3. Outline S o w h a t β s n e x t ? Approach Principles Introduction Definitions Challenges Β and Β lessons Β learned Business Β benefits Looking Β ahead
- 4. Every Β change Β goes Β through Β the Β build/test Β pipeline Β and Β automatically Β gets Β put Β into Β production. Continuous Deployment Development Β and Β operations Β engineers Β participate Β together Β in Β the Β entire Β product Β lifecycle Β -Ββ Β and Β are Β responsible Β together Β for Β the Β product. DevOps Building Β and Β testing Β software Β in Β such Β a Β way Β that Β the Β software Β can Β be Β released Β to Β production Β at Β any Β time. Β β¨ "Ship Β early, Β ship Β often, Β sacrificing Β features, Β never Β quality" Β -Ββ Β Kyle Β Neath Continuous Delivery Team Β members Β integrate Β their Β work Β frequently. Β Commits Β are Β verified Β by Β automated Β builds Β and Β tests. Continuous Integration Definitions Whoβs Β who Β in Β DevOps
- 5. Malmberg Β is Β an Β educational Β publisher Β in Β the Β Netherlands.β¨ Malmberg Β is Β building Β modern, Β rich Β and Β scalable Β e-Ββlearning Β applications Β using Β Java Β 8, Β Vert.x, Β AngularJS Β and Β MongoDB, Β running Β on Β Amazon Β Β cloud Β services. About Malmberg
- 7. Differences lead to issues Communication between development and operations was slow, problem analysis in production was difficult and releases took a lot of time. Traditional operations Production environments managed by external operations partner. Differences in infrastructure between development and production. Modern development culture Modern tools, lots of automation. Test environments are managed by developers. History About Β a Β year Β ago Things needed to change Issues and differences between development and operations were slowing us down. We needed to shift strategies to keep progressing.
- 8. β¦said no product manager ever. J. Β Paul Β Reed Letβs spend the next few months.. ..working Β on Β automated Β testing Β and Β build/release Β infrastructure, Β Β and Β redesigning Β how Β our Β application Β is Β written. Β We Β can Β postpone Β our Β feature Β development. β β
- 9. Build a complete new setup to allow development teams to transform to the new situation at their own pace. Keep the shop open Build a dedicated team of Devs, Ops and Cloud experts. Expert team Define key points that identify your approach and help you set goals. Define principles Approach How Β we Β initiated Β change.
- 10. Principles
- 11. Master branch is always releasable Principle 1 Every change is developed and tested in a feature branch. Donβt merge it until itβs done.
- 12. Unit/integration (Java & JavaScript), mutation, end-to-end (FitNesse/BrowserStack), performance (Gatling), Sonar for quality and coverage reporting. Rely on multiple layers of tests. Each commit is tested extensively Principle 2
- 13. Manage builds, tests, QA and deployments from a single place. Jenkins as the heart of the delivery process. Every delivery step is a Jenkins job Principle 3
- 14. After deploying 6 new features, when one has an issue, why roll back 5 good features? Donβt. Just roll out a fix quickly. Keep moving ahead. Deployments are roll-forward only Principle 4
- 15. No logging in to servers. Need a change or upgrade? Just update the server recipe. Hands off. Infrastructure as code - for everything Principle 5
- 16. The flexibility and resilience is well worth it. So how about using containers? The EC2 instance is our container.β¨ Even when you donβt need to scaleβ¦ yet. Put everything in auto scaling groups Principle 6
- 17. You canβt explain maintenance windows to modern end users anymore. Our end users are the Facebook generation. No downtime in production Principle 7
- 18. Make sure you find the problem before it finds you. Work proactive, not reactive. Eyes and ears in production Principle 8
- 19. Repeating tasks such as viewing logs and doing deployments must be common jobs. Specialisms are OK, but only for incidental tasks. Repeating tasks are executable for all team members Principle 9
- 20. Differences between teams are OK. A team thatβs dependent on external help is not. Give teams the freedom to work in a way that works for them. DevOps teams work on a self service basis Principle 10
- 21. Challenges 01 When you automate everything and keep growing, chances are youβre going to hit limits. Amazon has limits 04All environments are provisioned automatically. Challenge: how to prevent testing directly in production. How to test Puppet changes Not all developers are comfortable with managing infrastructure and middleware. Devs need to step up their game 06 When transforming an organisation, you need to be really clear about where things are going, why things are happening and when this will impact teams. Communication is key 03 Don't assume that cultural change won't be an issue. It will. Resistance02 This kills team progress. Donβt depend on availability of Ops experts 05 and Β lessons Β learned
- 22. Auto scaling and pro-active monitoring boost availability. A lot. Availability Business benefits High level of automation results in shorter release cycles and faster time to market. Agility Automated provisioning makes sure that every environment can be re-built from scratch in minutes. Continuity Lower operations costs due to scheduling and scaling. Lower maintenance costs due to high degree of automation. Cost reduction Faster problem analysis and solution. Better reaction speed How to sell this to your boss.
- 23. Get Β the Β teams Β the Β information Β they Β need, Β readily Β available Β on Β a Β dashboard Β visible Β from Β their Β desks. Better monitoring and dashboards Looking ahead 01 There Β is Β no Β silver Β bullet Β here, Β but Β useful Β tools Β and Β practices Β do Β exist. Continuous security testing03 Daily Β performance Β runs Β on Β test Β environments Β and Β continuous Β end-Ββuser Β performance Β monitoring Β in Β production. Continuous performance testing02 The Β only Β way Β to Β be Β really Β prepared Β for Β failure Β is Β to Β make Β sure Β that Β things Β will Β fail Β by Β making Β it Β fail Β yourself. Automated resilience testing04 Stuff weβre still working on
- 25. Thanks for your time. Liked Β it? Β Tweet Β it! @bjschrijver