Picture this (rather familiar) scenario.
It’s that dreaded time of the year again – your OpenStack upgrade (or perhaps VMware vCloud upgrade) is long overdue. You know that the latest security updates and patches must be applied else your environment will be at a high security risk. After several months of procrastinating-the-unpleasant (some call it blocked due to higher priority work items), you’ve finally come to a realization that this cannot be pushed any further. You’ve had the discussion with your management to chart out an ‘Upgrade Strategy’ with a timeline of 2-4 weeks. A team of top DevOps ninjas has been identified as experts for this task. A war-room has been dedicated with coffee, whiteboards full of action items and the team is finally all geared up to get through this ordeal.
The upgrade itself begins. A few initial unexpected surprises get you thinking that this time might be different! But then the inevitable strikes again. Some new DB schema changes cause the Database upgrade to fault in unexpected ways. A config file change breaks an existing dependency. A new service being deployed fails to come up as the documentation describes. A combination of these cause the upgrade to stall, require support, and get delayed by weeks.
All this time your users are promised an initial downtime window of few days, now are experiencing an extended downtime where service is either unavailable completely or available in limited fashion. They’re now breathing down your neck rather rudely asking for status, and at times escalating to the CIO.
This is a typical (if slightly exaggerated) story of upgrade of enterprise infrastructure management software today. OpenStack upgrade is anything but different. This is how every administrator going through this process usually feels:
A Dream Come True
Now imagine this:
It’s a Spring morning in April. You wake up after having a great night’s sleep, something you’re getting awfully used to these days thanks to a much simplified operations schedule for your private cloud management stack. You get your morning coffee, and pull up your inbox. And there it is. A new email catches your attention:
You pinch yourself to make sure you aren’t still dreaming, then you realize you’ve already had your coffee. In a moment of complete elation, you share this great news with the rest of your Ops team and make plans to start experimenting with and consuming all the new features you’ve been looking forward to.
A version of this is what all Platform9 customers experienced this week. Our Zero-Touch Platform9 Managed OpenStack upgrade did all the heavy lifting of carefully orchestrating an OpenStack upgrade (backing up the control plane, upgrading it, migrating the data and validating the upgrade was successful) so our users could focus on more important tasks (like getting to sleep at night!), and focusing on the consumption of new features that this upgrade makes available.
This dramatic simplification is only possible because of the SaaS nature of our cloud platform, combined with our sophisticated software profile orchestration engine.
Platform9 seamlessly orchestrates the upgrade on the controller services and the data-plane software on your servers. Of course, while your cloud platform is offline for 20 minutes during the maintenance window, the underlying infrastructure: VMs, servers, et al; just keeps working without missing a beat.
Better way to manage infrastructure? We think so. What do you think?
Try It for Yourself
Yes, seeing is believing. Sign up for your Platform9 trial and experience our SaaS magic for yourself.
Under the Hood
In an upcoming post, our engineering wizards will talk about the backend architecture that makes something as complex and hairy as an OpenStack upgrade so seamless. Stay tuned.