For these weeknotes I am going to write about the workshop we held last Wednesday afternoon to discuss ‘Our approach to cloud – next steps’. Although JJ has continued on work around our pipeline, which I will write about in more detail at a later date, this week the focus is cloud. We have started exploring the second hypothesis of this alpha, namely:
“Picking a primary cloud supplier will save us time and money”.
This workshop involved the management from a range of teams and disciplines from across HackIT and was a chance for us to have a conversation about our views on our cloud approach in an open and constructive way.
At the start of the workshop we set out to:
- have a shared understanding of the terms/ideas we use around cloud
- understand where we have differences of opinion, and where we have consensus
- have explored our assumptions and hopes and fears
- have an idea of the key strategic decisions we must make, and where we can safely test out ideas
Where are people at?
We wanted to start with a quick check to test what everyone’s current take was re: cloud. To do this we all did a self-doodle on a Post-It and used those to mark where we each were along a range of potential approaches, covering private cloud, single public cloud, hybrid cloud and multi-cloud. We quickly discarded private cloud (as no one picked that option) and focused on the other three.
We asked people to go through why they placed their views in each bucket. One of the things that emerged through this discussion is that the things that we valued were pretty consistent between people, even where we’d placed our Post-Its in different places. The common considerations that were brought up were: users’ and services’ needs, flexibility, simplicity / ease, value for money, and innovation.
Although people initially differed on which bucket they put their views into, through discussion it emerged that there was a consensus around a single approach that we felt best satisfied the considerations outlined above. This was for us to adopt a ‘Primary cloud but with exceptions’. This to some people was called multi-cloud and some people single public cloud but everyone broadly agreed this should be our approach.
This was really encouraging for us as it felt as though the hypothesis we are testing really tallies with our broad approach. This is something you always hope to be the case but given that the hypothesis had been suggested by an external agency it was really encouraging to see it chimed with our experiences.
What problems do we need to solve?
The two key areas that came out of the main bulk of the discussion were portability and the exception process.
We had a useful discussion of what we actually meant by portability. Portability is how easy it is to move our applications from one system to another. It can be more or less instant. At one end of the spectrum you could try and set your systems up to be instantly portable, so they could move from one cloud supplier to another at the click of a button. This would have the advantage of being easily able to take advantage of price competition between different suppliers.
In our discussion we challenged whether our scale and sophistication would make the investment in doing this worthwhile. Our overall view was that we needed to have sufficient ease of moving between clouds to avoid expensive vendor lock-in, but that we didn’t feel that we need to be able to dynamically move from cloud to cloud to take advantage of micro-level price changes between providers. We spoke instead about being able to move something over a timeframe of 6 months to a year, which would be much more manageable from a technical point of view and not introduce huge upfront development and implementation costs.
The other area that we discussed was how we would agree for applications to use a cloud provider other than our primary cloud supplier. We identified a number of factors that we want to consider when determining that something should be exempt from our Primary Cloud Solution, these might include things like: Cost profile, meeting user needs, opportunity for innovation, and flexibility.
There will also potentially be some cases where we would choose to accept less portability in order to benefit from specific functionality (i.e. using proprietary cloud or PaaS features), which is something that will have to be considered when exceptions are agreed. This will have to be something that we further consider in line with the initial steer in this workshop.
What do we still need to know?
The areas that were the highest priority for us to follow up on were:
- Deciding the criteria we will use to determine the primary cloud supplier
- Thinking about our ‘minimum viable’ portability criteria
- Agreeing some exception criteria for when it’s ok for teams not to use the primary option
- Determining what capacity we would need to procure from our primary cloud supplier and considering our route to market (our default is the Digital Marketplace / G Cloud, but we need to make sure that’s the best route to take)
We will look into these four areas in more detail over the coming weeks.