O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

June 2015 - OpenStack-fr meetup - Designing CloudWare applications

874 visualizações

Publicada em

From the Continuous Deployment need to CloudAware requirements for SW.

  • Login to see the comments

June 2015 - OpenStack-fr meetup - Designing CloudWare applications

  1. 1. 0 / 3 years with OpenStack… …and, so building CloudAware Apps. Jean-Charles JOREL (jean-charles.jorel@morpho.com) 30 June. 2015 Meetup OpenStack-FR
  2. 2. 1 / Agenda Safran Morpho introduction Morpho use-cases with OpenStack  That lead to CloudAware by Design need Project structure impacts and Change Management Morpho DevOps Service Line
  3. 3. 2 / Morpho Markets Overview • Smart Cards • Secure Elements • Strong Authentication • Digital Signature • Legally Binding Archiving • Citizen Registration • ID Management & Document Issuance • eServices • Criminal Identification • Law Enforcement • Road safety • Hold Baggage Screening • Checkpoint Security • Air Cargo • Border Management JUNE 2015 / CORPORATE PRESENTATION
  4. 4. 3 / About me…  Jean-Charles JOREL (jean-charles.jorel@morpho.com)  DevOps Service Line Manager  Leading a Team of ~20 people dedicated to DevOps deployment & associated operations  Safran Morpho Expert  Promote Morpho Technical Excellence outside of the corporation  Areas of Expertise: DevOps…, Cloud Techs, Network protocols & SDN, Innovation process, Linux hacking…  Help to bring new Tech Trends inside Morpho
  5. 5. 4 / Safran Morpho & OpenStack [1/2] 2012, our issues:  High heterogeneous Customer environments,  Need for complex Test benches  Very costly (HW and/or Std Virtualization) and not relevant…  OpenStack introduced to manage, in an industrialized way, most of our test bench needs and use them as collaborative envs.  We expected to manage IT stuff like SW through CI  We expected to create an internal Marketplace of cloneable test benches  We expected to have all this… self service. Note: See http://fr.slideshare.net/JeanCharlesJOREL/ for more extensive descriptions Morpho DevOps Service Line
  6. 6. 5 / Morpho & OpenStack [2/2] 2015, our status:  3000 VMs active, ~2300 runnings, ~1500VMs created/deleted per day  800 tenants, >800 OVS-SDN networks/subnets  ~200 Compute Nodes with Commodity SSDs (1Tb ou 500Gb)  Our 500.000th VM expected for this mid-August!  Every day, between 11am and 1pm, one VM created or deleted every 15s….  A new way of working under “hot” adoption by teams  Continuous Deployment of complex test benches,  Automated & virtuous VM lifecycle management,  On-demand provisioning/unprovisionning of HW,  Endurance & Performance zoning, Morpho DevOps Service Line
  7. 7. CloudAware by Design… From the CI need to the CloudAware requirements…
  8. 8. 7 / CI induces lots of Orchestration events… …that create ripple effects in the Infrastructure  VM creation/destruction/move, snapshots  SDN link creations/modifs…  (Un-)Provisioning of new Compute Node(s),  Hidden resource congestion algorithm activities  IOPS dynamic adjustment,  SSD breathing  CPU auto-slicing,  Active/Agressive Memory ballooning… Morpho DevOps Service Line
  9. 9. 8 / Ripples… at high rates! The more you make your Cloud change its internal states, more ripples (and so potential side effects) you get. Usually, not visible but perceivable Ex:  Provisioning of a new VM could congestion HDD and so, to avoid IOPS starvation, co-located VMs will be IO traffic shaped,  High network activity from a VM could create network latencies on others…  HW failure could make a VM disappear (or be completely lost as per defined in our own SLA)  Maintenance events (covered as SLA hiccup…  ) Morpho DevOps Service Line
  10. 10. 9 / Ripples = rates / rates = Frequencies!  Cloud IT systems behave analogously…  Resource rescheduling MUST be aligned with the Shannon formula,  Congestion algo. MUST be below Nyquist point Morpho DevOps Service Line Claude Shannon Harry Nyquist (Empiric rules of thumb)
  11. 11. 10 / Designing CloudAware Apps is taking into account all those ripple effects You can’t avoid ripples, so your app need to be ready (and not be sunk by too big waves!) An excellent specification:  http://www.opendatacenteralliance.org/docs/architecting_cloud_a ware_applications.pdf Morpho DevOps Service Line
  12. 12. 11 / Major CloudAware characteristics Morpho DevOps Service Line
  13. 13. 12 / Resistant to failures / Resistant to latency Those ripples make you test your HA continuously! Standard & Relevant test benches are deployed Continuously multiple times a day  Random and rare bugs are found quite rapidly High Availability is heavily tested both implicitly and explicitly  Ex: Dedicated scenarii where Oracle RAC nodes are killed every 10 minutes  Found a Data loss bug in JBoss that should have occur every 15 months at our customer premises Morpho DevOps Service Line
  14. 14. 13 / Some CloudAware best-practices…  Avoid timeouts without infinite smart retries,  Think resilience through autonomous & asynchronous remediation as much as possible  Avoid sequential system component start (as it implies a weaker stateful procedure). Allow random order start.  Make your apps wait for pre-conditions before to produce,  Make your apps go back to these pre-conditions on exception.  Detect and Fence a harming sub-component of your Application (One of the most difficult Best-Practice…) Morpho DevOps Service Line
  15. 15. 14 / CloudAware App by Design is impacting the way you plan your project Non-functional “CloudAware” requirements are managed from the project start  You need a reference test bench: what to put in it?? You need to setup an automated deployment  You need an automated deployment tooling (ex: based on Ansible, Puppet, Homemade script… + CI tools) You will have to fix some issues earlier in the Project life cycle than before!  Ex: HA bug, bad timeout management, error-management, etc…
  16. 16. 15 / People Change Management CloudAware design is a challenge / a disruption for many Developers and IT Ops  Prior to CloudAware design choice:  Infrastructure have to reliable and Ops have only to manage deployment after App release / As a Developer, I focus on my application coding and my own piece of the SW stack  After CloudAware design choice:  Infrastructure can be unreliable and Ops are working with me everyday (Are they still Ops??) / As a Developer, I need to share my time between Coding and Deploying activities.
  17. 17. 16 / CloudAware & Multimodal IT (cf. Gartner Bimodal IT)  Our « cost effective driven » Multimodal process… http://www.zdnet.com/article/how-it-leaders- and-cios-are-grappling-with-tech-change-the- bi-modal-debate/ Dev/Test/Int Environment Endurance & Perf Environment+ Traditional IT Production Environment Public Cloud or Traditional IT + ? Path to Upgradability
  18. 18. Q & A ?
  19. 19. Last but not least: Paying tribute to our favorite OpenStack component We really like OpenStack Swift!! Simplicity & Bullet proof: Thanks to the community for this very good piece of SW!