David Rogers

I'm Dave Rogers, Chief Technology Officer at the Ministry of Justice, and Kris Saxton, partner at Automation Logic. We're talking to you about hybrid cloud and why we think it is not the right strategy for your organization.

I'm going to give you a bit of context about the Ministry of Justice, because some of you will be familiar and some of you won't be.

One of the most fundamental activities of the Ministry of Justice is so-called criminal justice. We also work in family justice and other tribunals, but the bulk of our workload is around criminal justice.

This starts with the police in terms of the protection against crime, the prevention of crime, but crime will be committed. We then work in detecting that crime, again within the police force. As that moves towards investigation and gathering the evidence, that's when the prosecutors get involved.

The right-hand side of that diagram is the core area of the Ministry of Justice's work.

I've got a slide missing there.

In terms of hearing the evidence, judging, and sentencing, that's our courts. That's our criminal courts. And then detaining and monitoring, that's our prison and probation services. Those areas are what the Ministry deals with, and legal aid is another substantial part of that system.

We've been around for a while. We're about 800 years old. It started with the formation of the first courts under Henry II in 1178, and then Newgate Prison in 1188. There was then an enormous gap before the formation of the first professionalized police force. That was Robert Peel's Bobbies and the foundation of the Metropolitan Police in London.

And then the final piece in the puzzle was 1907, the National Probation Service. It's really not changed as a system fundamentally since then. That's an important characteristic to recognize in terms of how our information flows have evolved and how our technology has evolved, because we've been around for such a long time.

So what's happened in the last seven years?

There was the foundation of the Government Digital Service around about 2011. This was significant because this was the first time that UK government started to say very publicly that we're going to move to public cloud, and that's the strategy.

MoJ Digital was formed as part of a series of organizations that started to form around government to pick up and work and focus on that public-cloud-by-default strategy. We worked on four exemplars as part of the wider program, and all those exemplars were delivered into the public cloud.

Then things started to get really interesting. With the creation of MoJ Digitech, we merged with our partners who were focused on dealing with our legacy technology and our infrastructure and so on, and we wanted to align those strategies. So we started to align on the strategy of what it means for the entire organization to move towards public cloud, and not just delivering new digital services.

And the final piece in the puzzle is when several of our agency IT organizations were also merged into our central organization to allow us to take much more consistent, standardized approaches to how we're going to do this.

But we're still very early in that journey.

Now I'm going to hand over to Kris, who's going to give you a bit of the theory behind our position on public cloud, and then I'll come back to the Ministry of Justice and explain how that works within the context of the department.

Kris Saxton

Thanks, Dave.

It's quite an exciting presentation in that I'm not quite sure what order the slides are going to come up in. It's nice to be with this very exclusive audience, full of familiar faces and people that are not that interested in Docker.

I'm going to talk to you about hybrid cloud kind of in the abstract for a bit, talk about definitions, why people might be interested in hybrid cloud, and why we definitely don't think you'd want one in your life.

So definitions. Hybrid cloud is one of those terms where we're still kind of working out what it means. It's a bit like how cloud was back in the beginning, when it was used to refer to everything from Amazon Web Services to Dropbox. And now we have all these additional, more nuanced definitions like infrastructure, platform, and software as a service. Hybrid cloud's sort of not quite there yet.

One of the most popular or most typical definitions is some kind of mixture of private and public cloud resources. You've got your public cloud, and then you've got something which is generally on-premise, and then some way of aggregating those services and presenting them to the user in a unified way.

The other main type of hybrid cloud that we generally see is what I call the broker or abstraction layer. This is where you have some kind of intelligence that actually forms the interface with your user. Your user makes a request of the broker layer, and then the broker works out which of the many cloud providers that it supports it should dispatch the request to.

That's what I call the broker-based layer.

So why might people want hybrid clouds? The most common arguments we hear are support for different workloads. You might have one cloud provider which has a particular kind of accreditation that means you can run certain workloads in it but not in another. You might have ones that exhibit strengths in different kinds of architectures, things like that.

The other big reason for wanting to adopt hybrid cloud as a strategy is to protect against supplier lock-in. The obvious, almost fairly hackneyed, cheesy use case that's given is that one cloud provider is offering a spot instance price that's a cent cheaper, and then your magic broker layer somehow migrates all your workloads over onto that public cloud provider. Or so the story goes anyway.

I'll try and take apart each of those two definitions one by one, starting with the private and public cloud.

My main issue with this as a strategy is that there's really only one part of this that's actually a cloud, and that's the public side. What actually goes on in the private side is rarely worthy of the term cloud, and that's speaking as someone who's actually built over 50 of these things.

That's not to say that they aren't useful. They deliver a tremendous business value often. But really what they are are virtual machine provisioning systems, sometimes with a lot of automation, sometimes with a great amount of sophisticated automation if we've built them, but they still don't really come up to the term cloud.

They're missing usually several of the key capabilities that you'd find with a true cloud provider, such as massive elasticity, infinite scalability, and usage-based billing. The things that we build on private estates usually just don't have those things as requirements, and so they're not there. Again, not to denigrate them or say they're not useful, but it's kind of disingenuous to call them clouds.

The other type of private cloud that I mentioned earlier, the broker-based one, is kind of a bit more interesting in why that's problematic.

Anyone who's attempting to implement one of these broker-based systems is attempting to shift an entire industry. Where the cloud industry is in terms of maturity, there are no common standards for any cloud resource, no matter how simple, not even compute.

Someone wanting to implement a broker-based hybrid cloud has to build the abstraction layer, the interfaces, the data model, sometimes even entire languages in order to implement a broker-based system, and that is a mammoth task.

And then when you add to that, that they don't just have to build it, they have to maintain it, and we all know the speed at which some of these public cloud providers are moving. They're investing tens of billions of dollars a year in these new services. The net effect of that is that you are always presented with the lowest common denominator: perpetually greatly reduced choice.

If you look at some of those original benefits that we thought we were going to get with hybrid cloud: protection against supplier lock-in. Well, that's particularly relevant to the broker-based model because, when you implement something in a broker-based model, you have to architect your service for the broker rather than for the underlying cloud provider.

Again, because there's no standard in this area, you're probably going to be implementing in, at best, a sort of esoteric language, at worst, something that's really quite proprietary. So you might actually be making your lock-in worse. You're just moving it from the cloud provider to the abstraction layer.

And the other argument for supporting different workloads, well, again, for me, that doesn't really add up. Although there's some merit in that, what we hope to show you later today with a multi-cloud strategy is that there are much cheaper and simpler ways of deriving those benefits.

So get real. Basically, the public/private hybrid cloud: it's not really a strategy. It's an incomplete transformation. You really need to be pushing fully towards public cloud adoption.

The problem with declaring something like hybrid cloud a strategy is that it creates a vision in the mind of everyone in your organization that that's kind of the goal and that's acceptable, but it's actually not. Framed in that way, hybrid cloud is not really a strategy. It's a predicament.

The broker-based abstraction layer, that's really just an expensive fantasy. If you really want to go that route, expect to spend a lot of money and wait a long time for benefits that you could derive much more simply and easily by taking a multi-cloud approach.

So what is multi-cloud? What do we mean by that?

What we found, and what Dave will explain in a second, is that if you actually go deeper into a single cloud provider's ecosystem and build highly automated software delivery systems, but in a single cloud provider, but you build more than one of them, that's essentially what we call multi-cloud.

That has a lot of benefits, which I won't dwell on too much. This is actually a slide that Dave was supposed to deliver, but they've come in the wrong order. Just to recap them very quickly.

We recently finished a kind of version 1.0 of one of these multi-cloud platforms, and we found that, over the bespoke system that we'd built previously, we did it in about half the time and with about a third of the code base.

It was highly focused on developer productivity. It was pretty close, not quite there, but we had onboarding times for developer teams of maybe a couple of weeks, and then we reduced that to a couple of hours with a new system. So it's quite close to self-service.

An unexpected benefit was that it was very easy to automate, because within a single cloud provider's ecosystem, all of the components are, it seems obvious when you say it, designed to work together. So we need very little glue or integration code.

And if you build more than one of them, you can still support diverse workloads. Actually, something I was speaking with Tom last night at the dinner is that he took quite a different approach between his Linux estate and his Windows estate, and that was as much to do with the capabilities of the team and the background of the team as any technology driver.

That's something that Dave will talk about in a sec, but I would consider that a sort of classic multi-cloud strategy. Similar levels of lock-in, so no worse.

I'll leave it to Dave now to talk about how multi-cloud really worked at the MoJ.

David Rogers

Thank you.

I think the first thing to talk about is giving more context about what's actually going on at the Ministry. We've got three areas where our context is enormously varied.

The first one's capability. We're an organization that actually is the formation of several organizations over quite a long period of time, as I imagine the majority of large organizations are. That means our capability varies massively.

We've got people who have come with a great deal of experience, maybe working from technology companies. They've been working with the cloud for several years. And we've also got people who have been working with the same familiar legacy technologies for a very substantial time, sometimes up to 15 years.

You've also got a mix in terms of our outsourced technology as well, in terms of the capability that resides within our partner organizations. So that creates an extremely challenging environment to work with when you're trying to move things to a very different technology platform.

Culture and policy. We've also got quite a diversity of cultures. We've got diversity of attitudes.

One of the key touch points has always been, where does our data reside, or is it appropriate to put our data in public cloud? The MoJ now has a very firm position, which is that all information classified as official, which is the majority of what we do, it's about 99-point-something percent of what we do, that is appropriate for public cloud.

That's because we believe that you can put in the controls that you need within public cloud much cheaper, much more quickly, and you can secure your data there very effectively.

But that does touch on a culture point. Are the senior leaders across the Ministry ready for a message like that, which is actually quite counterintuitive to someone who doesn't know about technology?

And then the technology itself. As I say, huge diversity of technology.

Going on to the next slide, we've got about 1,000... Oh, I updated this slide earlier. We're doing an interesting project to try and identify and survey the technology across the Ministry, so this picture keeps changing.

We believe we've got about 1,000 complex software systems across the whole Ministry. We consider about 50 of those modern, about 950 of them to be legacy.

Our definition of legacy is about the speed with which you can work with that technology. It's typical with our modern technologies that we can update them within about 30 minutes, and we can do regular software updates during the day.

Whereas our 950 legacy systems have anything ranging from one-month to 18-month release cycles. We find that a really useful definition of legacy because it gets you around a lot of the politics of the age of software and people's preferences and so on.

As I said, the strategy is public cloud hosting by default. That is the central government's official position as well, and we're taking that on. We've added the word "public" on the front there because, as Kris was saying, it's a very strange marketplace, and we're very keen to emphasize that it's this genuine public cloud: your low-latency APIs, your high elasticity and scalability.

Going a bit deeper on that strategy. We're adopting two things. One is cloud transition strategy, and the other is multi-cloud.

First of all, cloud transition strategy. Cloud transition strategy is about getting people to realize that when you're an organization that's been around for a long time, you actually have an enormous amount of accumulated technical debt.

Technical debt might be the more developer-friendly term that we might use to that. But to senior leaders, it's risk. That risk conversation is something that has evolved and evolved. What is helping that is the spate of recent cyber attacks. We're able to demonstrate to senior leaders that they are vulnerable to certain forms of attack, and that the route to protect ourselves is to invest in a lot of our older technology.

But investing in older technology and paying down that risk is not something that moves forward and excites a lot of people in terms of what they might call digital transformation or organizational transformation. Cloud transition strategy is about fighting for a proportion of our budget, a proportion of our attention, to be focused on paying down the risk of our older technology.

Multi-cloud is what Kris has been talking about. It's about working more directly with our public cloud providers and building the platforms, the tools, and the teams that we need on top of those public cloud providers in a way that we are embracing their native ecosystems.

This is a real intentional shift to move away from the idea of trying to abstract, trying to stay within our private data centers as much as possible, where we might be more nervous about maybe security issues and so on, because we know that we can deliver better security in the cloud.

At the moment, we are working with what we consider all three of the major public cloud providers. We're going quite deep with Amazon Web Services at the moment, and along with Kris and his team, we're working on creating a set of patterns that allows us to use Amazon Web Services in the most native, simple way possible.

This is about minimizing the amount of boilerplate code and boilerplate configuration that all of our services use. When you consider that we're scaling up to 1,000 complex services, we can't really afford to build enormous, complex code bases on top of public cloud providers in order to give us a false sense of abstraction or reduction of lock-in.

These are these formalized patterns of use. You can use this idea for any kind of public cloud provider that you might want to use. You basically say, if you use this public cloud provider and you use these native tools and you configure them in this way, and you create those patterns and you publish them and you talk about them and you share them within your organization, it's showing people the way for how you can reduce the cost of your technology.

But crucially also, those patterns can start to be where you place your risk reduction, where you place your security work. Because you can say, if the patterns are used in this way, you get certain security characteristics.

The patterns must vary for your context. We know that very different patterns are emerging for our most legacy technology versus our most modern technology. To build technology that has a continuous delivery pipeline with fully automated test suites is going to look very different to some legacy technology that perhaps doesn't have tests, perhaps hasn't previously had an automated build pipeline.

So we're looking to set up different patterns for the different contexts of our technology.

And then finally, offering a wrapper so that we can provide those patterns to the organization.

One of the challenges that we're facing is, we're seeing in a very large organization, different parts of the organization approaching public cloud providers directly. What we're seeing is, for each direct approach to a public cloud provider, you'll see the emergence of a code base or a set of interactions with that public cloud provider that are only used for that one particular organizational area.

By offering this service internally, we're able to get a much more consistent approach to how people are using public cloud.

Fundamentally what I'm saying is, in this scenario, lock-in is not necessarily a bad thing. Lock-in is something that in a general case you want to avoid, but lock-in is ultimately a balance. It's about balancing the simplicity and time to delivery with the switching cost.

What we're seeing is no amount of engineering and no strategy is going to remove the switching cost if you're going to use one of the major public cloud providers. The market just hasn't standardized. The services haven't standardized. It's not an achievable aim.

Given that you can't reduce that lock-in, why not optimize for simplicity, optimize for that time to market? Because that allows you to get to the point where you're offering value to the organization as quickly as possible.

What are the benefits of this multi-cloud strategy?

As I said, speed to delivery. Focus on the value of your organization, because every line of code you write to configure a monitoring system, or to configure your alerts, or to configure your build pipeline, is not actually delivering value to your organization.

Simple access to the latest services. If Amazon or Azure or Google offer some fantastic new service, we want to be able to use that very quickly. Having a much more native ecosystem that we're using, we're able to get access to those as quickly as possible.

And resilience to organizational change. As I say, working in a very large organization, if different areas of the organization are starting to standardize in how they interact with public cloud providers, if the organizational structure changes, then we don't have very different usages of essentially the same product.

So in short, we're saying forget hybrid cloud. It's either a not very good strategy or a very bad name for something that you have to do, because hybrid definitely implies good.

Just think about maybe: is multi-cloud a better strategy for your organization?

And Dave. Finally, over to you.

Kris Saxton

Just had to stop you in mid-flow.

This is a response to a last-minute request from Gene, I think. Saw you sneak in at the back there, Gene. Which was, was there a slide that we could put up about getting feedback from the audience, or how they could help us?

One thing about this multi-cloud strategy is that we at Automation Logic are trying to codify this, so actually express it as code so that it's shareable and reusable, and distribute that under an open source license.

We think possibly we might have to do different ones depending on different industries. This one that we're doing in collaboration with the Ministry of Justice is targeted at those official workloads that Dave mentioned, but they all contain some quite sound security and auditing principles that we think would fairly easily apply to other industries.

If you're in either government or in financial services and you might be interested in some kind of cross-industry sharing and collaboration around these codified reusable patterns, then please get in touch.

That's it. Thank you very much.

Q&A

We caught up. Have we caught up?

Yeah.

Should we take questions?

Are we allowed to take questions?

We'll take questions until they kick us off, if anyone wants.

Yeah. We're running wild here. Yeah, hi.

Q: Where's your data? If you're in a multi-cloud environment, do you have any...

A: In the cloud.

Q: ...firewalls around it?

A: In the cloud provider.

Q: Yeah, but you've got three you're using, right? So how do you get that consistency?

A: I think all three have... Are you talking about geographical location?

Q: Not necessarily. I just mean, here's a criminal, here's his bio. I'm just making it up. I don't know the details. And another app over here wants to use it. What do you do?

A: Access it as a service. So you have the services that run, and each of the cloud providers can talk to each other.

Q: So you don't give any rules to the teams about where they should put the data center?

A: Curated choice, I think, is what he's talking about.

I'm not quite sure what you mean by where. Could you describe what you mean by where?

Q: Like, is it in Google or is it Amazon?

A: Oh, which of the three are you choosing?

Q: Yeah.

A: I see. It's left to the teams.

At this stage, we're investing heavily in platforms on top of AWS and Azure, and we're considering that option around Google. In terms of what choice teams make, we might decide to offer certain patterns through certain providers because we think that that ecosystem matches the workload best.

I think once it's offered as a service to the whole Ministry in a more formal way than it is currently, we'd have strong recommendations about saying, "Pick this provider, pick this pattern," based on maybe a set of criteria.

Yeah. But we use the term curated choice to lay out a series of acceptable patterns and providers and allow some degree of choice to the engineering teams to pick a pattern that suits what they're building, but within a restricted range, if you like, so we can make sure we stay compliant and whatnot.

Yeah, hi.

Q: I gather this is probably all aspirational at this stage. Do you have any sense of what percentage of the workloads are running fully in public cloud?

A: Currently?

Q: Yeah.

A: Currently, I think we've got about 40 to 50 services running in public cloud, and about 950 that are running in legacy data centers. We're seeing that number, the proportion, shift every couple of weeks or so.

Q: Is there a timeline that you can think of in your head that all of it will be done?

A: No. I'd say we're at the early stages of understanding how our oldest and most complex software moves to public cloud. There's a particular kind of complexity sweet spot where you get very old technology with very complex licensing rules running on out-of-date hardware.

At the moment, that's an area of exploration, so I think it's hard for us to know the timescales at this stage.

There's a whole other set of workloads that have got a really obvious journey to public cloud. So we would probably expect to see, over the next two to three years, a very substantial volume move.

But one of the things we're also exploring with multi-cloud is having different workloads mean different sort of degree to which a software service is either an asset or a liability, depending on how old it is.

So you might actually have more than one of these cloud platform implementations. One that is targeted for very modern workloads, let's say greenfield, container-based, where you're essentially going to rewrite the app.

But the area that I'm particularly interested in is this huge swathe of applications that you can't just lift and shift or can't really easily containerize, but still has, with small modifications, the ability to run safely in public cloud.

That's where I think you can get enormous amounts of public cloud adoption without having to wait the sort of 15 or 20 years that it's going to take us to rewrite everything to be cloud native.

Q: Do you deploy anything new in your private cloud at all?

A: No, I don't think so.

Q: Not just fixing things that are broken, but anything new?

A: Secret workloads, maybe.

Q: Anything new in private cloud?

A: Secret workloads. Yeah, potentially things classified above official, but not anything else.

Q: That's a really tiny percentage.

A: Okay. There are other people.