Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

You don’t need DTAP + Backbase implementation - Amsterdam 17-12-2015

DTAP is already an outdated concept in 2016. Instead an idea of immutable infrastructure should be used. Backbase in partnership with Levi9 have employed the concept of immutable infrastructure to revolutionize the way Custemer Experience Platform (CXP) is developed and released.

  • Soyez le premier à commenter

You don’t need DTAP + Backbase implementation - Amsterdam 17-12-2015

  1. 1. You don’t need DTAP DevOps and Continuous Delivery at Backbase DevOps Amsterdam meetup, 17-12-2015 Backbase, Amsterdam Pavel Chunyayev
  2. 2. @PavelChunyayev Amsterdam Levi9 HQ Amsterdam – 2005 25 people Novi Sad Serbia Novi Sad – 2005 320+ people Zrenjanin Serbia Zrenjanin– 2014 30+ people Iasi Romania Iasi – 2007 80+ people Kiev Ukraine Kiev – 2008 130+ people
  3. 3. @PavelChunyayev Electronic Retail Digital Marketing Traffic and Transport Software Services
  4. 4. @PavelChunyayev Customer satisfaction 2015 • 4th year great results in Outsourcing Performance study • 2015: 100% customer recommendation score Excellent trust score
  5. 5. @PavelChunyayev Forester Wave: Omni channel Banking Solutions Q3‘15
  6. 6. @PavelChunyayev Gartner Magic Quadrant for Horizontal Portals 2014
  7. 7. @PavelChunyayev Mark Rutte opens Backbase office in Atlanta
  8. 8. @PavelChunyayev Top 10 companies in NL with best work-life balance
  9. 9. @PavelChunyayev About me • 11 years of IT experience • Lived and worked in Ukraine and Estonia • Moved a year ago to the Netherlands • Learning Dutch • Love cycling • De Holandse 100 • https://www.dehollandse100.nl/actie/pavel-chunyayev
  10. 10. Continuous Delivery
  11. 11. Safely, rapidly and predictably deliver new features to production
  12. 12. Quality > Speed
  13. 13. DTAP
  14. 14. @PavelChunyayev Journey across environments Development Testing Acceptance Production
  15. 15. @PavelChunyayev DTAP is history • It was hard to create infrastructure -> we had to reuse it • Manually provisioned environments • Took a lot of time • Ticket to system administrator • Nightmare for both parties • End up with golden images • Fixed set of environments • Name them • Configure once • Maybe even automate deployment
  16. 16. @PavelChunyayev DTAP is evil • Configuration drift • Environments have nothing to do with production • With time they move more and more apart • Dirty environments • Undocumented, forgotten hacks • No one can recreate environment as no one knows how to configure them • Testing is complicated • Different bugs on different environments
  17. 17. Downwards spiral
  18. 18. You don’t need DTAP
  19. 19. Immutable infrastructure
  20. 20. Immutable infrastructure Immutable delivery
  21. 21. Easy on-demand environments
  22. 22. @PavelChunyayev Change in paradigm • Change in paradigm of the way software is built, shipped and managed • No more static infrastructure • Provision and create infrastructure just in time when it’s needed • And then throw it away
  23. 23. Create • Use • Dispose
  24. 24. @PavelChunyayev Never change again • Never touch or change the running system. • No configuration changes • No complicated update processed • Any change = new deploy • Create infrastructure right before deployment • You always start from the scratch • Identical process • No more dirty environments • Does it matter how environment is called if the deployment process is identical?
  25. 25. @PavelChunyayev Variability • Variability is enemy • Manufacturing: Six sigma • How to deliver environments at scale?
  26. 26. @PavelChunyayev Prerequisites • Cloud • Manage infrastructure lifecycle as code / through API • Docker containers • Automate the setup and deployment of your application
  27. 27. @PavelChunyayev Continuous Delivery • Immutable infrastructure enables CD Build • Test • Deploy • When you want to change - go through the whole pipeline
  28. 28. @PavelChunyayev Infrastructure is integral part of application • Application is delivered as a set of immutable virtual machines or containers. • Any change in the application is actually a change of infrastructure • Exactly the same process to deploy any version of the application • MTTR is predictable • It’s time required for whole pipeline execution • Gives incentive to optimize the process in order to speed it up
  29. 29. @PavelChunyayev Immutable infrastructure applies to • Stateless applications • State is stored outside (DB) • Even more relevant for microservices • Pushing of responsibility to someone else • Databases • Separate DBMS from data • There are solutions for this (e.g. Flocker)
  30. 30. @PavelChunyayev Deliverables • Server images (AMIs) or containers should be built using automated CI/CD process • Base image + application = deliverable • Or the configuration process and deployment scripts are applied over and over again
  31. 31. @PavelChunyayev Deliverables • Create your own images, don't reuse someone else's • Images must be versioned and all history must be saved • Implement automated testing of infrastructure • Create building blocks • Test deployments without any fear • Deployments are automated • Identical deployment procedures to all environments • Green/blue, canary and rolling deployments
  32. 32. @PavelChunyayev Immutable infrastructure • Get infrastructure exactly when it’s needed • Dispose immediately after use • Never regret
  33. 33. Continuous Delivery at Backbase And immutable infrastructure
  34. 34. @PavelChunyayev Backbase • Research and Development • Professional Services Customer Experience Platform Launchpad Mobile SDK Digital Banking Services Digital Banking Platform
  35. 35. @PavelChunyayev CXP Architecture
  36. 36. @PavelChunyayev Publishing • Multiserver configuration is needed to test publishing Editorial Staging Live
  37. 37. @PavelChunyayev Dual deployment model • Cloud Native first • But bank are not ready • Dual deployment model • Containers/cloud – modern • Enterprise style
  38. 38. @PavelChunyayev Teams structure • Squads • Team is divided into squads • Each squad is responsible for one or more components • Components • Components = microservices • >10 BE components • Dozens of FE components • Continuous Delivery squad is a Platform team
  39. 39. @PavelChunyayev Platform team • Now consists of 4 people, 5th starting in January • You can be part of this team • Several generations of platform • We are in the middle of introduction 4th generation
  40. 40. @PavelChunyayev Generations 1. Infrastructure as a service MVP 2. All configurations for CXP 5.6 and testing at scale 3. Docker and microservices support 4. Unified way of delivering infrastructure (being rolled out)
  41. 41. @PavelChunyayev Development environments • Docker containers = building blocks • Docker Machine • Docker Compose • No need to use virtual machines • No need to use jetty and h2 • No need to start whole environment
  42. 42. @PavelChunyayev Building blocks • Ansible roles • Packer • Infrastructure testing • Before – Starting full environments • Now – Testing roles in isolation • Test-kitchen • Serverspec
  43. 43. @PavelChunyayev Delivery pipelines git Build Version Test Release Component 1 git Build Version Test Release Component 2 git Build Version Test Release Component 3 Assemble CXP Test Release 342 128 473 921
  44. 44. @PavelChunyayev Pipelines as code • Pipelines as code • Changes -> same process as code changes • First stage is enforcing specifications • GoCD + Gomatic (updated) • https://github.com/Backbase/gomatic
  45. 45. @PavelChunyayev Platform • Services to manage environments lifecycle • The same way for everyone • Autoconfig • AWS • Autodocker • Docker
  46. 46. @PavelChunyayev Autodocker • Swarm cluster • Interface for docker environments provisioning • Limitations • One host for networking • Memory checks • Destruction after TTL • Configuration is a docker compose file • Start exact version of your component and released version of all other components
  47. 47. @PavelChunyayev Autoconfig • AWS on-demand multi-server environments • Any application version • Any configuration option • JSON (Form data) with parameters { "server": "jboss", "database": "oracle", "universal_collection": "true", "htts": "true" }
  48. 48. @PavelChunyayev Autoconfig APIs • GET /api/stacks - List stacks available for provisioning • GET /api/environments - List all currently provisioned environments • POST /api/stacks/<stack_name> - Provision specified stack • DELETE /api/environments/<environment_id> - Destroy environment with specified id • DELETE /api/environments/all - Destroy all environments
  49. 49. @PavelChunyayev Autodocker APIs • POST /api/docker - create new docker environment • GET /api/docker/<env-name> - get info about specified environment • GET /api/docker - get info about docker environments provisioned by the user Optional parameters: • all_users = True • uptime (value in hours) • owner (AD username) • DELETE /api/docker/<env-name> - delete specified docker environment • DELETE /api/docker - remove docker environments provisioned by the user Optional parameters: • all_users = True • uptime (value in hours) • owner (AD username)
  50. 50. @PavelChunyayev Quality • Build the quality in the process • Move tests to the left • Testing pyramid • No more manual testing • Ideal testing framework • Manage parallelism • Create environments M E2E Contract Component Integration Unit
  51. 51. @PavelChunyayev Releasing • Banks don’t want frequent releases • 3 stage release process • Rolling • In the effort to not release too infrequently • Technical previews • At the end of every sprint • Marketing releases • When product manager decides to release
  52. 52. @PavelChunyayev Culture • No blaming, no fingerpointing • Failing the build is a learning opportunity • We failed a lot • Several iterations of JS deployments • Visibility • Shared responsibility • Squad – for component delivery • Tribe – for product delivery
  53. 53. @PavelChunyayev Key takeaways • Forget about DTAP • Believe in immutable infrastructure • Create repeatable and reliable process for releasing software • Build quality in • Improve continuously Any questions? pavel@levi9.com

×