Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

June 2015 - OpenStack-fr meetup - Designing CloudWare applications

875 views

Published on

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!

×