Infrastructure on auto-pilot

Life just got a whole lot easier on SilverStripe Platform with infrastructure auto-upgrades. 

SilverStripe Platform's goal is to help developers focus on what they do best: building outstanding web experiences. We take care of operational concerns: minimise obstacles on your way to production, ensure availability in the face of changing traffic patterns and patch security holes in the software underlying the application code.

One area where we want to better deliver on our promise to remove distractions is the use of the .platform.yml to control infrastructure upgrades. You have control - but also responsibility.

That doesn't sound right, so we are putting infrastructure upgrades on auto-pilot.

If you have already used a fuzzy matcher in your .platform.yml, such as “^3”, you'd have already experienced the usefulness of this approach. You still had to do the upgrade yourself, but at least the latest compatible version would be picked up automatically.

We have observed that such fuzzy-matched stacks tend to be the most stable stacks out there, especially if they are deployed often. Frequent, small upgrades reduce the risk of failure, and lower the time-to-patch for security vulnerabilities. Thanks to auto-upgrades, those benefits will soon apply to all stacks. 

Changes to expect

With auto-upgrades, the “infrastructure” setting in .platform.yml becomes deprecated - it will no longer work. Instead, we will compute the best infrastructure version to be used on your stack based on the latest release information.

If you deploy to your stack often, the new infrastructure version will just tag along on top of the first deployment you make. That's it - all done as soon as you deploy.

If you don't deploy often, we’ve still got you covered: our agents will schedule an upgrade for you in a week’s time. It will be scheduled for whatever time your stack considers as "night" based on your stack’s region in AWS. It will also ensure plenty of support is available on our side during the deployment window.

You will know this is happening because you will receive an email notification (if you happen to be a Release Manager). You will also see the deployment popping up in the "Upcoming" list on the Dashboard. 

From within the deployment details screen you can also check when the deployment is scheduled for.

Our agents will automatically trigger the deployment as close to the right time as possible. UAT and test will be upgraded first, followed by production if all goes well.

Automated upgrades are conservative: they will not deploy any changes apart from the infrastructure upgrade. This means that if you have pending environment changes such as whitelist, they will still be pending after the auto-upgrade.

Anatomy of agents

Let's have a look under the hood of the auto-upgrade agents.

One of the main tools here at SilverStripe is PHP. Platform Dashboard is written using SilverStripe Framework and our command line tools are written using Symfony components. PHP however is not perfectly suited to systems programming.

In response our team has built up Golang capability as our secondary specialisation. It lets us fulfill the need for fast, low-footprint, self-contained programs. With Golang available, we've decided to split the auto-upgrade functionality into standalone Golang agents, placing them away from the dashboard.

Three agents were created to do the auto-upgrade job:

• autoupgrader crawls the Dashboard looking for outdated stacks, and schedules upgrades some time in the future
• triggerpuller crawls the Dashboard looking for things to deploy, and triggers them at the right time
• surveyor computes statistics that pop up in our monitoring system such as the median time between infrastructure release and its deployment.

This separation allowed us to improve overall system architecture: 

• agents use our Dashboard API. It's exposed to you so it makes sense for us to use it too! This immediately makes the API much more solid, as we get to learn about shortcomings and problems first-hand
• critical pieces of the Dashboard are more likely to maintain their uptime. Agents can be deployed independently reducing the risk of the dashboard core going down
• isolating agents from one another allows us to perform narrowly-scoped maintenance, and increases reusability. For example triggerpuller is useful for scheduling code-only deployments, even without the autoupgrader.

To make writing agents easier, just as AWS provided an SDK for their API, so did we. It's currently an in-house tool, but we have open-sourced it if you want to have a look: github.com/silverstripeltd/ssp-sdk-go.

You can also have a peek inside the agents: github.com/silverstripeltd/ssp-agents.

Finally, a little treat for those who managed to read all the way through to here: as of today scheduling is available through the Dashboard API. Our agent will do its best to trigger your deployment within the window you specify. No promises are made though: maintenance windows may run out if Dashboard is heavily loaded, invalidating your deployment.

Available soon

Auto-upgrades are being rolled out as you are reading these words. Your stacks will soon see the benefit of:

• decreased time it takes to get vulnerabilities patched
• reduced risk of upgrade failures, thanks to smaller and more frequent changes
• faster availability of new Platform features.

Finally, we also hope that this feature will make your life easier by giving you one less thing to worry about.

Interested in SilverStripe platform? Request a SilverStripe Platform demo today!