Modern Cloud is a phrase that we use a lot. It’s hard to explain what it means without thinking about legacy cloud. Gregor Hohpe has a great description. He says; ‘If you lift and shift to AWS (or any of the cloud providers), and don’t modernise your architecture, all you’ve got is a fancy data centre!’. You’ve moved your old data centre to a cloud level data centre. So you’ve got a top of the range data centre, but you’re not actually benefiting from Cloud.
Mike, Mark and Dave introduce the Modern Cloud and how to implement it for your org
Going beyond ‘lift and shift’
So there’s a term called Modern Cloud. I thought it would be interesting to dive into that. It’s a phrase that we use a lot. But a lot of people are asking: ‘What does modern cloud, modern application or modern architecture actually mean?’ It’s hard to explain what it means without thinking about legacy cloud. Gregor Hohpe has a great description. He says; ‘If you lift and shift to AWS (or any of the cloud providers), and don’t modernise your architecture, all you’ve got is a fancy data centre!’. You’ve moved your old data centre to a cloud level data centre. So you’ve got a top of the range data centre, but you’re not actually benefiting from Cloud.
I spoke to a company a year or two ago, who had a five step maturity model for the cloud. And they asked me about serverless first. And when I responded they said: ‘Oh, you’ve just described step seven!’. They hadn’t moved beyond modern cloud practices. So I thought it might be good to do a series on modern cloud. But before we get into that, what do you guys think modern cloud is?
Continuous style architecture
Good question. There’s a lot of dimensions and lenses to that question. But the way I see it is that ‘lift and shift’ is where we are lifting what we have in there and it’s now running . But are you really taking advantage? Is your organisation taking advantage? Is your team taking advantage of all the capabilities that exist within the cloud space? In order to take advantage of those things, you have got to operate in a certain way.
There are modern cloud operations that we’ve talked about in previous episodes, like well architected and what serverless teams do. It’s about being able to take advantage and really get into continuous style architecture. But doing that in a sustainable and safe fashion.
It’s about reducing time to value, in a sustainable way, so you’re not accruing technical, organisational and process debt. If you’re leveraging modern cloud to its maximum and if you’re following a serverless first approach, you’re able to go fast and sustainably over a decent period of time. Because you’re not building up technology debt that you have to pay down which slows you down in the long run. If you’re in modern cloud, doing serverless first, and leveraging well architected, you’ll feel the benefits and your business will see the benefits.
Graduation of IT
Nicole Forsgren called it out in her book: ‘Accelerate: Building and Scaling High Performing Technology Organizations’. Modern cloud is like the graduation of IT into the actual business by coming away from being a department to driving the company forward. You’ve got the speed to drive the company forward and be involved in the business conversation as opposed to being ‘in the wheelhouse shovelling coal’. So it’s about the graduation of IT and the change from being a cost centre and to value generation. There is an interesting point about modern cloud and technical debt. If you’re set up well, you’re not creating tonnes and tonnes of technical debt.
With continuous architecture, you’re operating in the modern cloud within the modern cloud paradigms like event driven architecture, leveraging managed services and well architected patterns, so you’re continuously evolving what you’re building. When you treat code as a liability and have well architected teams working in a modern cloud, you’ve got great observability. They’re constantly rebuilding, refactoring and evolving to build upon what they’ve done in previous projects on the platform.
And by using strategies like ‘pioneer, settler, town planner’ and ‘innovate, leverage, commoditize’, you tend not to hold on to anything that you’re not leveraging. You are not accruing a lot of debt. You’re continuously modernising, which means you’re constantly managing that side of your architecture.
Ability to adopt new capabilities
Because you’re optimised, when new capabilities, features or services come along, you can rapidly innovate and leverage them for differentiating value. If AWS or Google release a new service or feature, when you’ve managed down your code liabilities and you’re working in an optimal way, you can embrace that rapidly, within days. We have examples in our career. Something is announced and our teams are leveraging it the next day or the next week. When you have a good modern cloud stance, that’s possible. If you don’t then it’s going to take years down the road for you to be able to embrace those new features and capabilities.
That could be the difference between your business making it or not making it! There’s a real business differential to be gained from embracing a modern cloud approach. If you’re higher up the value chain you’re going to have more business impact. You’re more visible to the business, because you’re actually driving business success.
One of the things that is very hard to define with ‘modern cloud’ is technology. There are companies using Lambda that are in legacy, because they’re using it wrong. And there are people using EC2’s that are working in a modern and progressive way. You have to be clinical about your technology choice to use it well.
Wardley Mapping enables the Modern Cloud
There’s no such thing as a good or bad technology choice. It’s how you use it to solve your problem. So it’s not a matter of saying, Lambda is good and a Container is bad. A lot of people outside technology find it hard to deal with the fact that technology changes so quickly. It’s actually nothing to do with the technology choice. It’s about how well your teams are planning to use it.
That’s where Wardley Mapping comes to the fore by allowing you to understand the users, the user needs and the value chain of technology that you have at your disposal to meet those needs. As well as choosing the right tool for the job. So a well optimised EC2 instance, for this particular use case may be perfect. You can justify the additional runtime and operational burden, because you have good situational awareness about your tech stack and the choices you’re making. Teams that are operating in the modern cloud have that situational awareness, and they understand the trade offs for the technology choices they make. They can justify that all the way up the chain to the actual needs of the users.
Spotting the inertia
I think that’s a cracking point. We always describe inertia in Wardley maps and spot teams and tech that suffer from inertia. You’ve hit the nail on the head Dave. Inertia can be not looking after something within a lambda function that means we go back and continuously look at it, fix it or patch it. We haven’t thought about the longer term or what its role is other than for this solution. You can have an EC2 container with operational capability around it. We’re patching all the time, all our dependencies are up to date, we’re getting ready to move mobility, we’re always thinking about the next thing and is this the right piece of kit for the problem we’re trying to solve? There’s a mindset element which comes from teams working in a modern cloud way.
DevOps going from infrastructure to DevOps to SRE, to ‘you build it, you own it, you run it’, is very complicated because it’s changed so much over the past 10 years. One of the acid tests is how DevOps is talked about in the company. If you’ve lots of handoffs and developers are sitting waiting on other teams, then that’s a bad sign. A modern cloud team can do everything themselves. They rarely need to go outside their team for help.
The need for enabling teams
They’re ‘fast flow’. There’s very few handoffs, You still need, not necessarily a DevOps team, but you need enabling teams. There are complicated sub-system teams to ensure that your streamline teams or your fringe stack teams have all the experience, expertise and capabilities to do what they need to do without having to talk to anybody. As Team Topologies say, your streamline teams are set up for success and they’re able to move without friction, without handoffs or dependencies on anybody. They have the organisational structure to make sure it’s done appropriately and the guardrails are the right ones for business.
There’s a good train analogy. The train driver and staff in the train can drive the train from A to B. But they still need someone to lay the track, work the signals and repair the train. You’re not doing it on your own. There’s other things providing other services. Well architected is a factor as well, which we’ve talked about. And there’s ‘time to market’ and how fast the team can deliver.
The flywheel effect
Observability is critical for the team’s to know how they’re delivering with good radiators and good dashboards with frequency, mean time to restore and your lead time for change. The DORA four keys metrics are part of that as well as the well architected pillar and your adherence to them. Teams should have a good understanding of where they are on that journey. It’s critical for teams that are adopting modern cloud to know their current status and how well architected they are to know how to evolve and improve.
It’s an interesting discussion. It’s worth going through the flywheel that we talk about in our upcoming book. We talk about how to be effective in the modern cloud. In the flywheel, we look at ‘Purpose’ which is the strategy of the business/company and the ability to challenge, have an environment for success and the right culture in the organisation. ‘Next Best Action’ is from a developer’s point of view and looks at design patterns, processes and DevOps. ‘Long Term Value’, is about architecture, data security and sustainability. It’s interesting to look through those lenses at ‘modern cloud’. What’s our goal when we talk about the modern cloud? Do you think it is well understood? Or is it changing so fast that nobody knows.
You don’t arrive overnight
Whether you’re a CTO, an architect, or a developer, it’s good to understand the art of the possible. What does good actually look like? What can we actually do? And the direction and pathway towards that. You don’t arrive overnight. If you look at AWS, for example, in terms of how they get people into the cloud, there’s a seven step process. Initially, there’s a ‘lift and shift’. But once you’re there, what next? There are many ways to evolve. It’s good to have a conversation to acknowledge and accept it. You can do it. It just takes time and you have got to keep your eye on it.
Was that the 7 hours of cloud migration?
Our goal is to start sowing seeds by putting questions into people’s heads about what is possible and what good looks like. Hopefully, we can shed light on what works, what we have experienced in our careers, the benefits, the pitfalls and the things that are good for when you’re going down this path, because it’s not easy, but it’s well worth doing. In today’s competitive global landscape, you need to be leveraging the modern cloud properly.
That’s the opportunity. So that’s the craic. We’ll flesh these ideas out over the next couple of episodes. Thanks very much for listening. Our blog is at TheServerlessEdge.com. We’re @ServerlessEdge on Twitter and other channels as well. Thanks very much.