Enterprise Devops Presentation @ Magentys Seminar London May 15 2014


Published on

Thanks to Liam and the crew from Magentys for arranging a fantastic evening of presentations on all things DevOps.

Attached is my presentation from the event on Enterprise Devops.

For those of you who missed it:

“Join the crowd of 100 industry leaders across the Retail, Finance and Digital sectors for an exciting evening of talks in London’s Tech City on DevOps. Enjoy networking with a chilled beer alongside the experts who are making DevOps work and those who want to make it work.

Whether you’re a corporate or start-up, DevOps should be a hot topic so listen to how the experts are achieving great things, hear their views on the trends and discuss the future of DevOps.”



Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Enterprise Devops Presentation @ Magentys Seminar London May 15 2014

  1. 1. Enterprise DevOps from the trenches Jonny Wooldridge Head of Web Engineering @ M&S & Chief Geek @ enterpriseDevOps.com 15th May 2014
  2. 2. Intro
  3. 3. Aims of the next 30 minutes Our definition of Enterprise DevOps Why is Enterprise DevOps relevant to you? 10 Tips from 3+ years of getting DevOps working in an Enterprise
  4. 4. I’m not trying to sell you a ‘DevOps’ Tool. I’m not trying to sell you my latest book. I have a family and a day job, so forgive the odd spelling mistake! Word of warning These are my personal views, not the views of my employer. If you have a different view on anything in this presentation, I’d love to hear from you!
  5. 5. Me 2000-2003 Web Master / Lead Java Developer 2003-2007 Lead Developer / Head of Development 2008-2011 Director of Platform Development 2011+ Head of Web Engineering
  6. 6. Definition of Enterprise DevOps? It is about better software delivery practices It is end to end – from requirement to production It is about best practice in connected tooling It is about being fast and lean It is understanding the operational requirements of a system and making it easier to support/deploy It is understanding the trade offs. You can’t automate the entire Enterprise in one go. It’s about evangelising the power of great software engineering practices.
  7. 7. Why (I hope) this is relevant to you? Your start-up might be the next enterprise! Enterprise experience is 100% relevant to a start-up What can you do now to maintain DevOps momentum and not slow down as you grow? Being good at software engineering cuts across all aspects of an organisation, of any size.
  9. 9. Define what you are trying to achieve and why? TIP#1
  10. 10. Define what you are trying to achieve and why. Plan your attack: It may be boring but you need a plan and define clear goals explaining the benefits of a DevOps approach in the enterprise. What is your definition and how exactly will that be the game changer? Spell out the benefits but also create a sense of urgency as moving to a better software engineering approach in your enterprise is non-negotiable. Keep it simple: There will be a lot of people who will not have even a basic understanding of the steps required to make great software. They may have had experience in the past of a bit of coding or might have some understanding of Ops but assume that they know nothing. Knowing a little bit from 10 years ago is actually worse than knowing nothing so be sure to explain how the industry has moved on.
  11. 11. Define what you are trying to achieve and why. Show it working…: You can have all the powerpoint presentations in the world describing your approach and the benefits it will bring but in an enterprise people won’t get it until you actually show something actually working. Choose an application that they are familiar with. … and supplement with diagrams and animations. People in the enterprise are less likely to get excited by the latest scripting platform, test automation tool or cloud service! That is until they realise what benefits it has for them or their team. Show it in pictures and compare and contrast old ways of working. Make it clear that you care: In an enterprise you will find that if you clearly articulate that you care that software engineering is done well and can prove how ultimately it will make the organisation run better other teams will soon start to come to you for thought leadership
  12. 12. Define what you are trying to achieve and why.
  13. 13. Be an expert at the basics: Greater productivity through reliability: DevOps is an investment in tools, processes and people throughout all phases of a project to provide repeatable, reliable, and secure environments. Standard Developer Machines Continuous Integration build systems ‘DoD’ * throughout lifecycle Standardised Binary Deployment Robust Source Code Management Reliable Environment propagation Security Standards Coding & Testing Standards * Definition of Done Define what you are trying to achieve and why.
  14. 14. Define the pace of your apps TIP#2
  15. 15. Define the pace of your apps Danger: Don’t assume they all go at the same speed! Define you path to production which will help you…. Define what paces you have. As an example: FAST - applications you can continuously deliver that are decoupled and have a great % of automated tests MEDIUM – applications that are coupled and need end to end regression testing (hopefully mostly automated) SLOW – Projects dependent on Corporate Release Cycle (SAP etc.) Put in place different governance for different paces Understand your pace dependencies
  16. 16. Define the pace of your apps Ecommerce Engine Basket, offers, personallisation, up-sell, payment Digital Assets Image and video storage Content Mgmt. Page Content & Templates Search System Facetted navigation, search Apps Web Staff Apps Responsive Adaptive RESS IOS Android ReportsFront End User Interface API Customer Mgmt. Customer contact, CRM Communication Emails, text, chat Connectivity Layer (enterprise service bus) Routing, security, transformation, connectivity Order Management Orders, refunds, cancelations, stock, fulfillment, POS Product Information Product Catalog and Attributes Delivery Systems Courier/Standard delivery/Labeling Payment Systems Finance Systems Fast Medium Slow Frequency of change:
  17. 17. A typical start-up route to production Start-up* ★★★★ Stage 1 > Stage 2 > Stage 3 > Stage 4 > Development Continuous Integration Staging / Performance Production Define the pace of your apps Relatively Easy to continuously deliver Into this environment– buy the book! * Assumes a startup-up with a non-complex architecture Fast Frequency of change:
  18. 18. Are you brave enough to do continuous deployments for a payment module that your whole £multi-billion business relies on? Not all apps should be treated in the same way. How well de-coupled are they? Automated tests? Define the pace of your apps Slow Frequency of change:
  19. 19. Define the pace of your apps Development Continuous Integration System Test Product Group SIT Fully connected Corporate SIT Staging / Performance Production Decoupled Isolated Project Corporate ★★★★ ★★★ ★★ ★ ContinuouslyDeliverySlider Continuous Continuous Continuous Continuous Continuous Continuous Continuous Continuous Continuous Continuous N/A N/AN/AN/A N/AN/A Standard Standard Standard Standard Standard Standard Standard Continuous StandardKey: An environment continuously deployed to An environment where deployments Are managed in a standard way Standard Different Release types affect how fast your apps can go into production
  20. 20. Define the pace of your apps The idea being that you should always aim to continuously deliver your apps into production HOWEVER, if there are reasons why you can’t or don’t want to, make sure you can continuously deliver your apps into lower environments. Factors influencing how far you go with Continuous Delivery: how many environments you have how well you have control over the deployments made into those environments how many other teams are sharing the environment
  21. 21. Kill dependenciesTIP#3
  22. 22. Kill Dependencies – Obsessively understand and control your dependencies – Decouple your apps & architecture – create services – Decouple your people – give them more responsibility E2E – Integrate with 3rd parties carefully – Stubbing is a solution – Less Dependencies = Easier Testing
  23. 23. Focus on MVPTIP#4
  24. 24. Focus on Minimal Viable Products – What is the minimum you could go live with that will add value for your customer – See if it works then improve it – A change to culture and requirements only but has a massive impact on solution DevOps is therefore End 2 End from requirement to production
  25. 25. Be aware that DevOps affects every aspect of your organisation TIP#5
  26. 26. DevOps affects every aspect of your organisation – Technology and Architecture choice – HR, recruitment and rewards – Finance – funding allocation and Total cost of ownership – Governance – Auditors – should love DevOps btw ;-) – Suppliers & Contracts – which projects to offshore? – Ways of working – always can improve
  27. 27. DevOps affects every aspect of your organisation Stage 1 > Stage 2 > Stage 3 > Stage 4 > Stage 5 > Stage 6 > Development Continuous Integration System Test Product Group SIT Corporate SIT Staging / Performance Production Decoupled Isolated Project Corporate ★★★★ ★★★ ★★ ★ CAB CAB CAB VS Same Day Every Quarter Angular.js, bootstrap.js, mongodb, Scala BDD and Continuous integration, Struts, mainframe, test data issues, infrastructure SLAs Affect on recruitment Do more with Less
  28. 28. You are unique. Think for yourself. TIP#6
  29. 29. You are unique. Think for yourself Take guidance from best practice, but don’t be afraid to innovate What’s appropriate for you may not be appropriate for somebody else Having a DevOps Team might be an ‘anti-pattern’ but it might work for you: To build frameworks to empower agile teams to do their own devops Provide shared tooling where it makes sense Sort out contractual arrangements for the enterprise for cloud and tooling providers
  30. 30. Make your tools work for you. TIP#7
  31. 31. Make your tools work for you Make your tools work for you, not the other way around Embrace OpenSource it’s generally years ahead of the main vendor thinking Don’t believe the hype Why has the GUI seduced you? Deployment for Dummies? If you can script it, why do you need an expensive tool? TOOLS GAP: one area that is lacking in OpenSource is visibility of your working pipelines – how are the deployments progressing? What stage are they at? What’s the status?
  32. 32. Build a Software FactoryTIP#8
  33. 33. Build a software factory Build a software factory What is a factory? Let developers focus on the creative aspects of writing code, not how their code gets into environments for testing Connect your tooling to get value EXAMPLE: what’s in a build, differences between two versions Don’t forget security! Add them into your build pipeline. Maintain ownership of your delivery pipeline at all costs Force all suppliers through your pipe without exception Get visibility of every code commit Out source your dev, but keep them honest by making everybody come through your factory Machines.
  34. 34. Build a Software Factory
  35. 35. Don’t (just) focus on Deployment automation TIP#9
  36. 36. Don’t (just) focus on Deployment automation Requirement to Production Risk of local optimisation Make it as fast as possible but be realistic Testing is the real problem – and how do you scale it Requirements – INVEST sessions
  37. 37. Think like you’re the Enterprise of tomorrow TIP#10
  38. 38. Think like you’re the Enterprise of tomorrow Make the right choices with: Technology Hiring Contracts 3rd Parties Make the wrong choices and your DevOps dreams can be shattered
  39. 39. We need each other Thanks for listening!