Reflections of Red Hat Summit 2017

I returned from the annual Red Hat Summit last week, which was as exciting and inspiring as ever. This year the summit returned to Boston and was held at the highly impressive Boston Convention & Exhibition Center (BCEC), which is located in the Seaport District of Boston.

The summit took place over 3 days and we were treated to an astonishing array of sessions from Red Hat developers, staff, customers and partners, with each one being better than the next.

It was also an excellent opportunity to see a series of presentations from several members of the Red Hat Mobile team, including two from myself; a Lightning Talk at the main DevZone entitled, Application Health Monitoring from the Inside Out and a breakout session on Cloud Solutions for Enterprise Mobility.

There were numerous other highlights but some of my personal favourites were:

  1. A new partnership between Red Hat and Amazon Web Services;
  2. The launch of OpenShift.io, a hosted developer environment for creating and deploying hybrid cloud services;
  3. The launch of the industry’s first Health Index for container images;
  4. The story of Easier AG (a Swiss medical company) and how Red Hat’s Innovation Labs helped to make their ideas a reality, which all started in our home office in Waterford.
  5. Attending a baseball game at Fenway Park to see the Boston Red Sox in action, live!

I’m already setting my sights on Summit 2018 and am very much looking forward to the year ahead preparing for it.

A Simple Model for Managing Change Windows

One of the more common things we do in the Cloud Operations team at Red Hat Mobile is facilitate changes to environments hosted on the Red Hat Mobile Application Platform, either on behalf of our customers or for our own internal operational purposes.

These are normally done within what is commonly known as a “Change Window”, which is a predetermined period of time during which specific changes are allowed to be made to a system, in the knowledge that fewer people will be using the system or where some level of service impact (or diminished performance) has been deemed acceptable by the business owner.

We have used a number of different models for managing Change Windows over the years, but one of our favourite approaches (that adapts equally well to both simple and complex changes and that is easy for our customers and internal stakeholders to understand) is this 5-phase model.

Planning

The planning phase is basically about identifying (and documenting) a solid plan that will serve as a rule book for all the other elements in this model (below). In addition to specifying the (technical) steps required to make (and validate) the necessary changes, your plan should also include additional (non-technical) information that you will most likely need to share externally so as to set the appropriate expectations with the affected users. This includes specifying:

  • What changes are you planning to make?
  • When are you proposing to make them?
  • How long will they take to complete?
  • What will the impact (if any) be on the users of the system before, during and after the changes are made?
  • Is there anything your customers/users need to do beforehand or afterwards?
  • Why are you making these changes?

Your planning phase should also include a provision for formally communicating the key elements of your plan (above) with those interested in (or affected by) it.

Commencement

The commencement phase is about executing on the elements of your plan that can be done ahead of time (i.e. in the hours or minutes before the Change Window formally opens) but that do not involve any actual changes.

Examples include:

  1. Capturing the current state of the system (before it is changed) so that you can verify the system has returned to this state afterwards.
  2. Issuing a final communication notice to your users, confirming that the Change Window is still going ahead.
  3. Configuring any monitoring dashboards so that the progress (and impact) of the changes can be analysed in real time once they commence.

The commencement phase can be a very effective way to maximise the time available during the formal Change Window itself, giving you extra time to test your changes or handle any unexpected issues that arise.

Execution

The execution phase is where the planned changes actually take place. Ideally, this will involve iterating through a predefined set of commands (or steps) in accordance with your plan.

One important mantra which has stood us in good stead here over the years is, “stick to the plan”. By this we mean, within reason, try not to get distracted by minor variations in system responses which could consume valuable time, to the point where you run out of time and have to abandon (or roll back) your changes.

It’s also strongly recommended that the input to (and outputs from) all commands/steps are recorded for reference. This data can be invaluable later on if there is a delayed impact on the system and steps need to be retraced.

Validation

Again this phase should be about iterating through a predefined set of verification steps that may include examining various monitoring dashboards, running automated acceptance/regression test tooling, all in accordance with two very basic principles:

  1. Have the changes achieved what they were designed to (i.e. does the new functionality work)?
  2. Have there been any unintended consequences of the changes (i.e. does all the old functionality still work, or have you broken something)?

Again, it’s very important to capture evidence of the outcomes from validation phase, both as evidence to confirm the changes have been completed successfully and that the system has returned to it’s original state.

All Clear

This phase is very closely linked to the validation phase but is slightly more abstract (and usually less technical) in nature. It’s primary purpose is to act as a higher-level checklist of tasks that must to be completed, in order that the final, formal communication to the customer (or users) can be sent, confirming that the work has been completed and verified successfully.

 

A new era begins for Red Hat in Waterford

As the year that was 2016 draws to a close, we embrace and celebrate the dawn of a new era for Red Hat in Ireland with the opening of our brand new offices in my home city of Waterford on Monday, 12 December 2016.

This is an immensely proud moment for the entire Red Hat team in Waterford, especially so for those involved in the FeedHenry acquisition from October 2014 which has lead us to this wonderful occasion.

It is also fitting that the new offices are the first to feature the trademark We Are Red Hat internal branding in the Irish language, which translates as “Is Sinne Red Hat”.

So to the management, staff, families and friends of the growing Red Hat community in Waterford, take a bow and enjoy the celebration and delights that this day will bring.

It is everything that we have worked for and is no more than our wonderful city deserves.