Cloud Native Attitude

Introduction and Background

Sarah Wells: Hello and welcome to the GOTO Book Club where today I'm going to talk to  Anne Currie about her recently published book Cloud Native Attitude which she wrote with Jamie Dobson. And I'm really looking forward to digging into the details but I want to start with introductions.  Anne, can you introduce yourself?

Anne Currie: So, hi, Sarah Wells, my name is  Anne Currie. I am the author of the book that we're going to talk about today is the Cloud Native Attitude, which is an interesting subject of today's call for many reasons, which will become clear soon. But I'm also the author of O'Reilly's new book Building Green Software, which is very, as it turns out, relevant to Cloud Native. Cloud Native is very relevant to that and I have been in the tech industry as an IC, as a manager, as an engineer and other things for 30 years now.

Sarah Wells: Wow. I think I'm at 25 years, which is quite hard to believe it's been quite that long. And we've known each other for quite a long time and in fact we spoke for the case study for this book for the Financial Times quite a long time ago.

Anne Currie: We did.

Sarah Wells: 2017?

Anne Currie: We did.

Sarah Wells: Actually. I should start by saying I love the book. I mean I think it's such a good overview of what Cloud Native actually means and I frequently referred to it when I wanted to explain to someone what are the components of Cloud Native. But I want to start by saying what's your focus with the book? Why did you write it? Why are you doing a third edition and who should be reading it?

Anne Currie: So actually there's quite a lot of things to untangle in that question. I do want to say this is a very unusual Book Club GOTO podcast because Sarah, who's interviewing me, is also one of the stars of the book. And in some way and in many ways you represent the reason why the book was written. Back in I think it was 2017, me and Jamie Dobson, who was the CEO of Container Solutions at the time, we were sitting having coffee at QCon London which is a big tech conference that runs every year in London, and this year, Sarah, you are the chair of that conference. So anyway, this was many years, eight years ago we were sitting around and at the time almost every talk at QCon was about microservices, cloud, containers, or orchestrators. And it was all very interesting. I was fascinated by this, really fascinated by containers and the changes that they were going to introduce. The Cloud Native, the CNCF, the Cloud Native Computing Foundation had just been formed and we really...at the time we just had no idea whether or not that was complete crazy talk on the part of the Linux Foundation because we didn't really know whether people were actually doing anything with all of these newfangled things in the wild. So basically, Jamie set me off to go off and investigate and actually write down what it all meant and how it all works and how it all fits together and what obviously the plan was and then talk to a whole load of people who seem to be ahead on this and what they were doing, real people, real enterprises, were they doing anything? Because obviously we were saying, "well, this is lovely to hear about this at conferences, but is it real? Is it just completely, maybe Google's doing it, but no normal enterprise is doing it." So we wrote the book in order to try and get our heads around what was going on. Right? And you, one of the people who was sucked in at the FT, you were one of my prime case studies of actual users of this stuff in the field.

Recommended talk: Building Green Software Part 1: Introduction • Anne Currie • GOTO 2023

Defining Cloud Native

Sarah Wells: I think it's interesting because I think at the time we spoke, I don't know that I would have described us as Cloud Native, but then I also don't know that I knew what Cloud Native is. Actually, I'm going to, that's what I want to ask you about, which is Cloud Native is one of those terms that people use.  I'm not sure people even mean the same thing by it. I've heard that the trivial thing is when it's built to run on the cloud rather than just being shipped to it. But I think there's more to it than that. I'd like to understand your definition of Cloud Native.

Anne Currie: Well, so it's interesting. Defining Cloud Native was one of the reasons why we went, we wrote the book. At the time, this was back when the CNTF was first formed, they defined Cloud Native as, oh, gosh, container packaged, orchestrated, microservices built for scale and cost and efficiency. And we thought, "well, actually, it doesn't sound crazy," but it's quite a complicated definition. Does that mean that if you only do some of those things, then you're not Cloud Native? You have to do all the things and you have to be in the cloud and you have to be releasing 20 times a day and you have to be, otherwise you're not Cloud Native. In which case, what I found now was that pretty much nobody would have been Cloud Native. Maybe Google was, but nobody else. Even now, very, very few people meet the requirements of all of those things, although it has become more and more...I mean, obviously, I think it's turned out that that was probably the direction of travel because there's so much value to doing all of those things. Cloud Native, I came to the conclusion it was a bit of a spectrum and it was also an attitude more than anything else. It was the desire. And it was the desire to be able to move. So I would say it really comes down to...to be able to change your systems, to be able to take advantage of services and third-party services, new stuff as it becomes available. I was reading something that you're very involved in Team Topologies and that kind of movement towards fast flow and faster rolling out of new things. And this was your major focus when you were at the FT, which is why it was so interesting to talk about at the time. Because you were all walking the walk, not just talking. So that was good. But I'm more and more thinking that cloud native was for the kind of people who saw, who cared about their bottlenecks in running, what was slowing them down, what was holding them back and were attempting to address those bottlenecks. And it's often, I mean, many years ago, I was head of IT for an enterprise. And the big bottleneck, the biggest bottleneck was always infrastructure. It was always how long it took to get stuff in our data center ready to run. And then when we had to change something, it was a disaster. I mean, it was like, it was like, "oh, yeah, yeah, everybody wants this tiny tweak, but we've got..." you know, it's totally out of our hands how long we're going to have to wait for the hardware. And not because anybody was an idiot. That was just the way that the world worked. We had unbelievably clever operations folk who were tearing their hair out constantly over this. It just took ages.

Sarah Wells: Well, it's because you went and bought a server and then you configured it. And we actually kept a track of the metrics at the FT. So I know that when I first joined in 2011, it was six months to get our production server bought, racked up with everything on it. And that was probably the first change that the FT did was to try and look at automated provisioning. And I remember we got to 15 minutes by 2014. So we went from six months to 15 minutes. And then shortly after that, at the time I was an engineer hands-on on a team, I was complaining because it was taking 15 minutes because you just get spoiled by how quickly you can do it. And you can't do things like microservices until you can spin up, you know, basically, I've got this idea for a service. Well, I've got to wait six months for a server.

Anne Currie: It was a gigantic bottleneck. I never really...until I was...until I reached the point where I could really see what was holding up the whole organization, I was used to thinking the software was difficult. And then I realized that I'd been living in a dream world in which software is so easy compared to, at the time, compared to hardware. It was...it was really hard. Things like just like the data center doesn't have a socket for you to plug in another machine. Yeah, that's, um, and that's kind of why we thought that...and I think that's really where Cloud Native comes from. It's really going, "what is my first bottleneck?" And it's usually infrastructure. Can I get infrastructure as a service? And then you start...you start from there. And then you move on to your next bottleneck, which is usually...which is often well for a lot of people I talked to the first time I wrote the book, it was another problem for me. I remember from when I was doing the same job, the hiring folk, hiring skilled folk, hiring skilled Ops folk, very hard. And so a lot of the desire for moving into the cloud was to be able to do it with fewer skilled Ops folk.

Sarah Wells: Yes.

 Anne Currie: Because they were really hard to get your hands on.

Recommended talk: Insights on How Team Topologies Drive Organizational Success • Manuel Pais • GOTO 2024

Fundamental Architectural Principles

Sarah Wells: Yes, but I think what I think what you're making me think about with cloud native is, is it's very easy for organizations to think we want to move to the cloud and to forget what it is they're trying to achieve by doing that. And I think with cloud native, you've got an idea of we're not just taking this application and putting it into the...to run on AWS. You're actually trying to achieve some outcome that you couldn't get when you're in the data center.

Anne Currie: Absolutely. Yes. Yeah, yeah. And indeed, it's all about identifying your bottleneck. It might be that your bottleneck is not infrastructure or hiring people or any of the things that the cloud will help you with. Your bottleneck could be something completely different, in which case you don't need to go cloud na-, you don't need to think about moving to cloud or and not everybody who wants to move to an infrastructure service model goes to the cloud. Some people build it themselves, but it's quite expensive. So, you know, Facebook isn't in the cloud, they built it themselves. 

Sarah Wells: But I think your fundamental-, in the book, you talk about several fundamental architectural principles of cloud native. I guess, actually, I don't think any of them include the cloud. And it's like the infrastructure is cloud, which we've talked about. Containers and orchestrators. So I guess you can...you don't have to be in the cloud to be doing that either. What changed around...because I think when you wrote the first edition for this, it was relatively new all of this stuff.

 Anne Currie: Yes.

Sarah Wells: So what's what changed between the first and third edition for this do you think?

Anne Currie: The massive, massive change between and it was what eight years ago, it wasn't that long ago. It's like a lifetime ago. When we first wrote, when we wrote the first edition, it was not clear which orchestrator was going to win.I’m not sure that you'd even started Kubernetes at that point, because it was quite new. And it came in a little bit later than the microservices.

Sarah Wells: Yes

Anne Currie: They were looking like they might be the orchestrators that would take over the world. But the only two that have survived are Kubernetes, who totally took over everything. And Nomad from HashiCorp still exists and it's still a good orchestrator. It kind of coasted all the way through. But basically everything else got kicked up backside by Kubernetes.

Sarah Wells: We actually did build our own orchestration when we started using containers at the Financial Times because nothing was really out there that was going to work for us. But we did quite swiftly move to Kubernetes once it was available, once people were using it in production.

Anne Currie: I mean, I'm casting my mind back, but I think in the first version, there are only a few...so there are a few case studies like that I've...so the book, it covers eight years, that the third edition came out covers eight years. So it covers that all the principles of cloud native pretty much the same because they're principles and they have to totally stand the test of time and have turned out to be pretty much exactly as we predicted eight years ago. Because obviously, Sarah  was one of the early reviewers of all copies of the book. But in the case studies we revisited everybody. So everybody who's now in the case study has been revisited throughout basically. And I think there are three that this...there was the FT was not Kubernetes in 20, in the first version, but is massively now.

Sarah Wells: Well, you say that it is but it's also...at the point I left there were many other ways of deploying stuff and it was always a mix of different things. Yeah,

Anne Currie: Okay, so that is interesting.

Sarah Wells: Yes.

Anne Currie: Starling Bank was not Kubernetes in 2017. But I believe that they are now homegrown. They built their own orchestrators to start with as many people did back then because you didn't necessarily need to start with Kubernetes. It is quite advanced. I mean, in some ways, it was easier to wait, obviously, you don't want to have to build your own orchestrator, but it's not rocket science to build an orchestrator. To do very simple things like automatic restarts. It's not ridiculously complicated. So in some ways, you've got everybody into the mindset of what an orchestrator did by just going and well, I've just run a batch to do this. And the other key case study that really, really I've been like, you know, I've stalked them throughout their entire existence is Skyscanner. And they were ECS or back in 2017. And they are now very Kubernetes. The world has really changed in a way that we did not predict at the time. Everybody was kind of holding off because we weren't sure who's gonna win.

Sarah Wells: Yes, well, it's changed. But also, you are right, all of those foundations are still there and are still important and still give you value whether you do all of it or some of it. 

Anne Currie: I was just gonna say there's a whole chapter in the book on orchestrators, which, despite the fact that actually every orchestrator has changed completely, all ones that were big at the time are dead, all the ones that were happy and exist at the time are now taken over the world. The chapter has barely changed because it was all about the principle of orchestrators. The principles remain identical.

Recommended talk: Enabling Microservice Success • Sarah Wells & Sam Newman • GOTO 2024

The Importance of CI/CD

Sarah Wells: Well, I think that's what's great about the book. It is about the principles. It is about what these things are and why do they matter? So you've got quite a lot in a chapter in the book about CI/CD, about continuous delivery, and which is something that wasn't in that original CNcF definition, but actually, it's pretty fundamental if you're going to really be cloud native and benefit from it.

Anne Currie: I came to the conclusion that it was actually the most important thing.

Sarah Wells: Yes.

Anne Currie: Cloud native, if you didn't implement it, the CI/CD, it seemed like, well, everybody did. The only thing that was utterly common between every single person I talked to is that they were really keen on CI/CD and very fast, and fast, frequent deployments to production. But having said that, I had a bit of an epiphany on that. The other day, I was giving a talk about the book and then the front row was Greg Hawkins, who is another person I interviewed. He was the CTO of Starling Bank at the time. I talked his ear off for all versions of the book. I was talking and I was looking at him, I was thinking, "he would probably pick me up on this," because I was saying, "I think that CI/CD in this fast flow thing was the main thing that cloud native was all about." And as I was talking, I was suddenly struck by this epiphany, which I then said out loud, which is never a good thing to do. Well, you're like, just in case it's stupid, because it could be easily stupid, which was that what I was considering to be kind of...there's a causation correlation thing here that all the people that I spoke to who were. I spoke to all the companies in basically the UK, because they were the ones I had the easiest access to, who were the absolute acme of cloud native. So as I can see, they were the most modern systems. What they had in common was that they did fast, small releases using CI/CD.

Sarah Wells: Yes.

Anne Currie: I thought, "ah, right, it's fast, small releases that are the fundamental concept of CI/CD." But then actually, as I was speaking, I thought, "it could just be that I'm looking, it could be, let's take the reverse that I was looking at the companies that were successful in doing something really difficult. What could be that you're only successful in doing something really difficult in tech, if you're doing CI/CD and you're doing small incremental releases, because otherwise, you don't have that feedback loop, you can't do difficult stuff. I mean...

Sarah Wells: Yes.

Anne Currie: That was what you were attempting to get at the FT out of cloud native more than anything else.

Sarah Wells: I mean, we went from releasing the website 12 times a year to doing 20,000 releases a year across the whole estate. But it just is completely different. It's one of the reasons that fast flow comes out of both Team Topologies and Accelerate. I think if you move to the cloud and you still can't release things quickly, then you're not...you're probably having additional complexity with that without getting the benefit potentially.

 Anne Currie: Absolutely.

Sarah Wells: Actually, I think you mentioned in this edition of the book that there's been a bit of a...bit of a swing away from microservice architectures, which is interesting to me, because I wrote a book about microservices. But what's interesting is, I think that whatever people are replacing it with, it's still things that enable them to do small releases quickly, whether it's a modular monolith, whether people are using serverless more.

Anne Currie: I mean, you could argue that actually...so when Starling first went live, they were more like a kind of macro service model. It wasn't microservices, still quite big, chunky things, although they've moved more in the direction of microservices, because they wanted to do more frequent releases. But it is not terrible to have the...and the same thing. Skyscanner had their monolith in the mix for a very long time indeed.

Sarah Wells: Yes.

Anne Currie: You don't always need to go, you don't have to be Monzo. You don't have to have a million microservices. It's quite complicated. It's and it's complicated if you want to run a microservices and have speed. So you're doing things that are synchronous and that's very hard. I think you need to start with what is your need.

Sarah Wells: Yes. 

Anne Currie: Microservices can be amazing if you want to use third-party services as well. But is there a third-party service that you want to use? If there isn't, then you might not...it might not be worth investing in that complexity. But it's...you know.

Sustainability and Cloud Native

Sarah Wells: Yes. It's called the cloud native attitude. What is the attitude that works for that? What did you see in the people's...in the case of this? But also, if someone is considering that they want to sort of move towards this, what do they need to have in place?

Anne Currie: I would say the attitude was a desire to be able to change things and take advantage of third-party services and just change and move and change. It was that reason that I really twisted Jamie's arm to re-release the third edition because I'd written Building Green Software for O'Reilly with my two lovely co-authors, Sarah Hsu and Sarah Bergman after that, all the Sarahs. What became very clear was that what was holding people back more than anything else in being green, it wasn't the design, it wasn't the lack of desire to be green, it was the lack of the ability to move at all. And that really made me think, you know, that was what the cloud native attitude was about. The attitude was the desire to move and the ability to move. It's hard to go cloud native. You have to get everybody involved. It has to be bought in from the bottom of the organisation to the top. You have to be incredibly persistent. It's going to take....years and years. And you have to really want it. You have to have the attitude that you're willing to put that investment in in order to become really agile with a small, agile, reactive organisation, the ability to change. And that's a desire to change. The desire, obviously, it's not the desire to change, the desire to have the ability to change is the cloud native attitude for me.

Sarah Wells: Yes, I think that I definitely saw that the FT, one of the reasons we were successful was because actually we had a from the top, we had a culture that we're going to try it, we want to do this. We had a very open culture. And that sense of basically being prepared to invest in improving things, I think is really important. You mentioned sustainability, and actually, that's a whole like new...There's much more discussion of it in this version of it. So what's the sustainability challenge and how does Cloud Native help with that?

Anne Currie: Well, the sustainability challenge is fundamentally that it's...there are some things you can do to be sustainable that are really easy. Anyone can do them. You don't have to be Cloud Native to do them. You don't have to be in a cloud or anything like that. It's just turning things off that are wasted, don't need to be on right sizing, all that kind of stuff. A manual passthrough will probably save you...the irony is doing those simple steps probably saves you about the biggest chunk of carbon you will ever save. It can quite easily and usually we see it cutting people's carbon bills between 30% to 50%. And at that stage, that's also the hosting bill. So the early stage, your hosting bill and your carbon bill are pretty much, you know, they're very directly correlated. But to take it further than that, then you need to start automating that stuff, you need to do automated right sizing, aka auto scaling. And it's very hard to do that stuff outside of the cloud. So unless you're using it, there are services that exist to help you do that. A lot of services that exist to help you do that are in the cloud. So to get to the next stage, you really have to be able to turn off machines. You have to be able to turn off machines automatically, you have to be able to respond to changes in demand and fluctuation. You have to be a lot cleverer. You have to have real organisational smarts to get to the next stage. And then that...doing that can halve your carbon bill again. So you get your, by doing this initial pass and then getting really good at operations, you should be able to cut your carbon bill by broadly 75%. But you do need to use the techniques of cloud native to get to that next stage, level three of the maturity matrix, we call it. I would also call that effectively being cloud native. To get further than that is interesting. To get further, to get beyond really good Ops, which is everybody's best interest, because it's much more resilient, saves you money and it's much more secure. But to get beyond that requires you to do things like write code efficient code. And you do not...most enterprises do not want to and should not ever do that because it's really, really expensive. Code, this used to be my area back in the, when I was really young, 30 years ago, was writing really efficient code in C and it's really difficult and it's really expensive. So if someone writes it, you want lots of people to use it. You don't just want them to use it. It's a crazy investment for an enterprise to make. It's a perfectly good investment for a vendor to make. You want to buy off the shelf. You want the ability to buy things like that off the shelf. And that's really, again, where it comes down, where the cloud native attitude comes in. You need to have the ability to take advantage of what we call green platforms, platforms that are efficient, that will just keep getting, that will just take you to carbon zero under your feet without you having to do anything. But you have to adopt them. So all we need to do is get people the ability to move to such a platform, not write it, just the ability to move to it.

Sarah Wells: Something really interesting there to me is that lots of the stuff that's actually, you were saying the first thing that gives you a huge reward is a manual process. I think there's a thing where if it's things that aren't exciting, but can make a big difference, and actually that pragmatism of...it doesn't have to be perfect, but we can do something that gets us closer to where we want to go. I think it is something that made us very successful at the financial times. We didn't want to build the perfect solution. We were okay with something that was much more simple, but gave us a lot of what we wanted. And I suspect it's more exciting to think about learning how to write very efficient code than it is to think about the other side of it. Just actually looking at what you have left running that you haven't turned off.

Anne Currie: Absolutely. It's not very glamorous, is it? There's a company in London called Ravelin who run these regular, what they call thrift-a-thons. So rather than a hackathon, you know, exciting hackathon, everybody gets to write some code. They do a thrift-a-thon regularly where everybody wins, someone wins by turning off the most stuff and saving the most money. And I think that's fantastic.

Sarah Wells: That is fantastic. We used to have gardening days in the platform engineering teams at the  financial times where the idea was we're going to do the weeding. We're basically going to go around and just clean things up and make everything look super tidy. And I love it because it is gardening. It is like if you do this periodically, your garden will continue to look nice. You'll benefit from it. I think that's pretty good. I think it's really interesting to say, move to the cloud and you can take advantage of a lot of this sustainability stuff because my experience is very often people move to the cloud and then six months in the finance people are saying, "why is it costing us more to run things now than it did when we had our own data center?" I mean, what do you think about that?

Anne Currie: Well, yes, the cloud is not guaranteed to be green. In fact, unfortunately, most people who move into the cloud become less green, not more green. And I think one of the problems is that moving into the cloud has such a wide range of meaning as to be essentially meaningless. That's if you move, if you just lift and shift into the cloud, but you don't use any of the services, then you're just running an incredibly expensive on-prem data center where it's really easy for you to just keep over provisioning and buy more. I mean, the good thing about the old days when it took ages to buy a machine was that you didn't over provision too much because you had so, you know, you just couldn't get your hands on the stuff. It's now so easy that things get over provisioned and over provisioned. One of the stories I tell all the time from the Cloud Native Attitude is the story that you told me about the FT, about how when you originally moved, when you first moved into the cloud, your bills went through the roof and then you decided that what you were going to do is give teams access to information about what their hosting bill was. Once they could see it, they just reduced it. All they needed was information. And if they could just go, "oh, I could just have another one, another one, another one." As far as they're concerned, it doesn't cost them anything. They'll keep pressing that button.

Sarah Wells: They don't necessarily pay any attention to it. They spun this thing up three weeks ago and they've forgotten about it. There were teams at the FT that built Slackbots that would say, "hey, there's this server that you spun up. Are you still using it?" And actually that you could see, and people liked being able to see what was happening to their bill. And I think that visualization is quite important.

Recommended talk: Next-Generation Cloud Native Apps with Spring Boot 3 • Thomas Vitale • GOTO 2023

The Future of Cloud Native

Sarah Wells: What do you think the next changes in cloud native are going to be? Is there something you can see coming up that's going to be affecting how people use all of these technologies?

Anne Currie: Obviously you're dangling there for something that I didn't mention in the book at all, although we did have a chapter on it in the green, in Building Green Software, which is AI. I just can't get over how good AI is, how good LLMs are. I think it's too soon to say, but I think revolution. So I was talking to an old colleague who's...who I very, very much trust their opinion at DevOps, at a DevOps workshop last week. And he was saying that he started to make significant use of Claude, actually, and say it's just so enormously useful that he's using it all the time every day. And it just massively cuts the amount of work he has to do. And, you know, he has to check over the stuff, but that's fine. It still cuts what he's doing massively. So yeah, AI enabled infrastructure as code. It's got to be coming, hasn't it?

Sarah Wells: I think the same. It's interesting, because I think the principles will still be there. It will still be the same underlying things that you're benefiting from and the reasons you're doing it. It's just that something is applying some of the stuff for you.

Anne Currie: The chatbots are very good at explaining the principles. It's a bit, because every now and then, you know, I do come ask Chat GPT about, you know, green software and that kind of stuff. You go, "oh, my goodness, that's an amazing description I could have written myself." But especially as I think, "I did write an awful sort of stuff around this, you know, maybe it's not."

Sarah Wells: It could be your words.

Anne Currie: But I don't really care that much. I mean, I've written a lot of books, both fiction and nonfiction books. And one thing I can say is that as an author, you make no money. So look, the loss of your IP is not as bad as you might think. You know, there is only one JK Rowling. Everybody else is just doing it to get the message out. And I said today, I'm sure that I mean, as a fellow O'Reilly author, Sarah, I like you working one day, possibly afforded to share a cup of tea between the two of us on our royalty payments. We do it for the message. And if you...and I don't mind someone even if that someone is Chat GPT reading my books like that, and then sharing the message. I have no problem with that.

Sarah Wells: I know that's true. But I also think you do it for the message and you do it for your own understanding. And that is the reason why, why I think there's still a reason to write. The fact that it takes forever to get your thoughts in order. And then you come back to it a week later and you completely change it. There's always that there's always value in that.

Anne Currie: Somebody has to write the books. Somebody does have to write the books because that does evolve all the thinking and it's on...it's the most expensive way of thinking that you will ever do. But it is a very good way of thinking.

Sarah Wells: This is slightly off topic of your book, but I think spending the time to really think through something and write it up, whether it's for an internal presentation or a talk or anything like that, leaves you with a really thorough grounding in that.

Anne Currie: Yes.

Getting Started with Cloud Native

Sarah Wells: I have a final question about the book, which is if someone reads this and thinks, "I've got a challenge that this could help with," what would be the first steps you'd recommend for them to get started on it?

Anne Currie: Well, I would thoroughly examine your challenge, make sure that it really is a challenge, make sure that everybody in your organization agrees that it is a challenge, that it is worth significant investing in solving. You know, is it, the key thing is, is it the bottleneck? Is it what you should be solving? Because you've got to and it has to be convincing, you have to convince everybody because it's so difficult. It's about writing a book about IT organizations. It's so hard. You will learn a load, it'll be amazingly useful. But it's so hard, you have to make sure that everybody agrees that that is the problem that you should be focused on. And if you can get everybody to agree to that, then if they don't agree, then it's worth listening to what they think really is the problem and make sure that you aren't thinking, right, "we'll do this amazing project that's going to take up everybody's mind cycle for years and years." Whilst it's a bigger problem and a bigger choke point or bottleneck, that's...that won't be resolved by that project. So the first thing you need to do is, and it will help as well. It's good in all senses, you can work out whether it really is the thing that you need to be doing next. But if you talk to everybody and you become convinced and you convince everybody else that it is the thing that everybody needs to work on, it'll be a lot easier for you because then everybody will be on the same page and pulling together, it will be aligned.

Sarah Wells: I think that's amazing. But that means people are having a single coherent engineering strategy, which is a really, like a surprisingly challenging...surprisingly challenging thing, I think, to come up with. But I agree that, I think knowing that we at one point at the FT had an objective for the year, which, well, it was for several years, actually, it was cloud only in 2020. And which was a great objective, because you knew exactly what it was and when it had to be done by and how you'd be measured for it. It worked because everyone was completely aligned in it. Everybody knew what they had to do to make that happen. I think having that sense that everyone is up with it. It's really interesting to me a lot of times you have a couple of teams within an organization that want to bring in infrastructure as code, they want to bring in automation, they maybe start some work. I think you hit a natural limit. If you haven't convinced everybody else that there's a reason, a reason to do things like that.

Anne Currie: I think that's true. Alignment is step one, isn't it? Getting everybody on the same page and in agreement. And then, step two is infrast-, is CI/CD.

Sarah Wells:  If you did that and nothing else, you would improve, you would improve things so much. The difference that I found between writing code and it may be going live in four weeks, six weeks, and writing code and I could push it live that day was just amazing. You know, both in terms of the benefits to the organization, but also just what it's like to be a developer. So much more rewarding.

Anne Currie: That neither of those things are classically what you describe as cloud native.

Sarah Wells: No.

Anne Currie: But they are still the most important, you know, it's, you know, you have to build your platform, to build your platform is something...an old colleague of mine used to say all the time and he was quite right. Then after that, you can start thinking about whether you want to be in the cloud. And you say there are pros and cons. It's...if you're a startup these days, I think you'd be absolutely mad to not be in the cloud. But I can also see why it is a really difficult thing to do, especially if I feel lift and shift projects are very, very problematic indeed. And I see what people do is totally...theoretically is a good move. Theoretically good is a good move. But I think psychologically, it's a very risky move because to make the cloud work, you're going to have to do iterative small, small...You're going to have to move into a mindset of iterative small steps and putting a gigantic single monolithic project right at the start of that doesn't get you in the right mindsets, does it?

Sarah Wells: It doesn't. Even if you are moving things that are relatively small, I think that having that lift and shift mentality of we're just going to do what we do, but we'll do it on someone else's servers. We definitely had to learn that it's a lot quicker to use the components that you can buy from the cloud providers than it is to, like, to build and operate your own database cluster. But we had to learn it by doing it.

Anne Currie: Yes.

Sarah Wells: I think if you lift and shift, you just...and normally what happens is you decide you're going to do it. There's some kind of deadline that means you have to do it. Then you're all exhausted and you've got everything running in the cloud and it's more expensive than it was in the data center and you haven't got any benefits from it. And then the will to do with the next step can just disappear. 

Anne Currie: It is. I mean, will is what delivers projects more than anything else.

Sarah Wells: Yes.

Anne Currie: And if you burn it all out and you're all disappointed and everybody's going, "but you said when we're in the cloud, everything would be great." And he said, "well, we're in the cloud, but we're only halfway to where we need to be."

Sarah Wells: Yes.

Anne Currie: That's a really hard sell. 

Sarah Wells: It is. I think this is where the attitude comes into it. You really...Like, you need to be doing, moving to cloud native with a vision of what you're trying to, like, as your book says, with a vision of what you're trying to achieve and with an attitude that's going to make it work for you. Definitely. And with that, I think we are pretty much out of time. It's been a great discussion. Thank you so much. And thanks for speaking to me about your book. And I really recommend it to people. It's great and small. I always like to recommend short books that can be read quickly because basically you get a lot out of investing the time to read it. Thank you so much.

Anne Currie: Thank you.

Sarah Wells: Goodbye.