How to Shift to a Serverless Mindset

David Anderson at UXDX EMEA. Video: https://www.youtube.com/watch?v=YSuJWrxDyjM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction

[00:00:02] Thank you very much. Hey everyone, how's it going? First of all, are you enjoying the event? I think it's fantastic to be here at such a fantastic conference, and fair play to the organizing teams, they're doing a brilliant job. So here to talk about how to shift to a serverless mindset. My name is Dave Anderson.

[00:00:23] First of all, I work at Bazaarvoice. I'm a technical fellow, which is a strange title, it's kind of like a distinguished engineer. And for Bazaarvoice I sit in Belfast, and we work in retail. What we do is we collect, display and distribute content, actually user generated content, to help consumers buy online. So we have something like 12,000 brands, over 50 million reviews, questions, answers, pieces of social media, visual content, and we help something like over a billion consumers shop every month.

[00:01:00] So that's what I do now. And one of the reasons why I'm talking here today is I've got this book coming out, which is The Value Flywheel Effect, which I'll get into. Really what this is about is, how do we maximize the value on the cloud?

How we got to serverless first at Liberty Mutual

[00:01:12] But first let me tell you about how I got here. My previous role was a CTO role with Liberty Mutual, and I'm going back to maybe right back 2014. We started a kind of a digital transformation, like every big enterprise. And if you don't know Liberty Mutual, it's one of the largest insurance companies in the world. I think they have something like over 40 billion dollars premium, 60,000 employees.

[00:01:40] And really, as we sat there in the leadership team, we started the digital transformation, and there were three things that we focused on: customer centricity, cloud native development, and agility. And me being the engineer, I kind of started to grab hold of cloud native development. Really the ask, the challenge, for the organization was: how do we develop faster? And with my team in Belfast we started thinking about that, and we came up with this concept which was a serverless first approach, which I'll explain in detail as we go through. And that really was to try and drive us forward as an enterprise.

[00:02:17] And the thing was, Liberty were partnering with AWS, with Amazon, as a public cloud provider, and the two things that were really important were both the move to the cloud and the modernization of how we work. They're two different things, they don't always come together, but that was the opportunity we had. When we started thinking about this over eight years ago, the serverless first approach wasn't really a thing, and we kind of worked that and developed that.

The struggles every company has

[00:02:48] So let's talk about some of the struggles that big companies and small companies will have. Speed: it takes months or weeks to get a big product out into production. That's a problem that every enterprise has. Predictability: sometimes we have deadlines, sometimes we have timelines, we want to get something out at a certain date, but often we have real dates that we need to hit, and it's very hard to predict those dates. Cost: in a very large company the IT costs are absolutely extravagant, they go up month on month.

[00:03:21] Scalability: if you hit something like a Black Friday event, it's very hard to scale that. I did a lot of e-commerce for Liberty. The big thing that hit us wasn't Black Friday, it was Cyber Monday. A lot of people buy their cars on Friday, they get insurance on Monday, we used to get a crazy spike on Monday. And again, if you're on-prem, that's a lot of manual effort to make that work. Or even worse, if there's a natural disaster. And finally, engineering confidence: you want your engineers to really deploy product to production really quickly and with confidence. They need a good developer experience.

[00:03:59] And we certainly didn't start out thinking about serverless. We had a look around, we tried different options, and this is actually the AWS definition of serverless. You've got speed to market, you see there's a nice quote there from Vanguard, scaling from like three months to 24 hours. You could build better applications, lower your total cost of ownership. A good engineering team knows how much things cost, it's a great measure of an engineering team: do they know the daily costs of what they're running on? Improve scalability: you can scale in an instant and let the cloud provider do the work for you. And then, run applications anywhere: that confidence to be completely connected, and it's different in how you develop your software.

Modernization over migration

[00:04:43] So really there's two things here when you're thinking of the move to the cloud. It's modernization over migration. There's probably a bunch of people who've been through a cloud migration, but in my experience many companies just move, they don't really modernize. For me, the modernization is the serverless mindset. That's a different way of working.

[00:05:04] So let's break that out. And when I say serverless, it could be containers, whatever else. There is a modern way of writing software where you really shift that load to the cloud provider. So Amazon have this, and really this is the same for Amazon, Azure or Google, they'll have this shared responsibility model. If you think about it, if you have your software on-prem, in a data center, you do everything yourself. What a lot of companies do is they'll move out to their cloud provider, to that bottom red line. They'll basically move from your data center to Amazon's data center. You've got that global scale, availability zones, brilliant, job done.

[00:05:44] That's not the end of the journey. If you go up that line another bit, you start to offload things to the cloud provider like compute, storage, database, platform. You offload as much as possible to that cloud provider. What I've seen a lot of people do is think their cloud migration is that red line. The modernization is the green line. And really the question that I often ask people is, where do you draw that line? And this is probably more a conversation for your infrastructure team, but I think it's important that we all understand: what should we do as an organization, and what do we not do? So this is the conversation we had, probably for three years: where do we draw the line?

[00:06:23] And where we started to really make progress: that's Werner Vogels there, he's the CTO of Amazon, with this idea of migrate, measure and then modernize. This became like an iterative cycle, how we made this approach. This was in 2020, there was a virtual serverless first function event, a global event from Amazon, and Werner was doing the introduction. I had been doing a little bit of work getting the speakers lined up with one of my team, and he talked about organizational nirvana: companies that take a serverless first approach, offload all those tasks to the cloud and focus on business value. And then I almost fell off my seat, sitting in Belfast in the house, when he says companies like Liberty Mutual. And so this is insane, we're on to something here. From what started as a crazy idea on a whiteboard, you have the CTO of Amazon talking about this approach. And really the idea is that for every piece of software you write, you look at a managed service first, and if that doesn't work you then scale back to what you need to do.

[00:07:27] The phrase serverless is not something I really like, it's a very bad name for this. But if you think of the adoption curve, all the major cloud providers have different functions between Amazon, Azure and Google, and really this is a survey from Datadog coming a few months ago: over half of organizations that adopt the cloud are currently using some kind of serverless. So you're probably doing this already in your organization, but in pockets. So it's actually something that's from engineers. Some engineers will say, oh, we don't do that, but actually it's very common for a lot of cloud teams.

The myths around serverless

[00:08:04] There's a few myths around serverless. I'm not going to get into the technical details, but I'm interested to hear if you hear any of these lines from your engineering team. We're different, we can't do that, we need to build everything ourselves. No you don't. If you're Amazon or Azure or Google, if you're building a cloud, fair enough. If not, build it on someone else's hardware.

[00:08:26] The fear of vendor lock-in. This is kind of an oldie, goldie: we don't want to be locked into a single vendor because we're big and we're special. No you're not. You may be portable, but you've probably lost business because you haven't been hitting your customer value: speed, transformation, flexibility, every time.

[00:08:41] The consultants don't like it. If you get a couple of hundred consultants from a large consultancy house helping your migration, that's not necessarily a good thing for you. Your migration may run for years, cost millions of pounds or euro, but you may not get the value. I don't think consultants really like serverless because it's fast.

[00:09:02] Services aren't mature. Maybe in 2016, but not anymore. Our engineers aren't ready: this is a really common myth around serverless, it's too hard. This has nothing to do with modern software, it's because you're not training your engineers. The cloud changes every month, it's constantly changing, you need to invest in training. If your engineers are under pressure, just look to see how much training they're getting.

[00:09:24] It gets expensive really fast, because a lot of the managed services and serverless are pay as you go, and there's a fear that your bill will fly out of control. This is just a normal cloud principle you have to get on to, you have to understand opex over capex. You will have a monthly bill and it will fluctuate. You have to invest in FinOps. Good teams know how much their software costs. It's like being on a mobile phone and never looking at the bill and making calls: yes, you will get caught. You need to be aware of your spend.

[00:09:55] And finally, our security tools don't work. If your security is slowing down the technical adoption in your company, you need to educate security. That's not a reason not to modernize. That's probably one of the things I see most, where the CSO is uncomfortable because the suite of tools they bought five years ago don't work anymore. That's a different problem.

The second transformation

[00:10:16] So really, the way I like to describe this, it's almost like the second transformation. If you're through this transformation, everyone's, you know, the consultants have been paid, the bonus pool has been emptied, everyone's got their cloud socks, let's go. But often I have seen this, the CEO or the board are asking questions to say, okay, our IT bill is actually higher than it was, we've spent a huge amount of extra money on this transformation. I love the fact that we're all excited, but I'm not seeing anything move faster. I think there's a second transformation, which is that modernization transformation.

[00:10:52] So one way I want to illustrate that is with a really simple value chain. Say you're a board member or a CEO. You have a need for business value. I don't mean in your project, across the company. We look at the company as an asset, to make sure that company is getting proper ROI. For me, business value depends on leadership. You need leadership in your company to make sure that that is realized properly. Leadership requires technical leadership. You need architects, your senior engineers, to be basically on the money. They need to be driving the company forward.

[00:11:29] They also need engineering skills. Once you have technical strategies in place, you need engineers who can execute on that. And finally you need that modern cloud operations. Modern cloud ops is probably going to sit down there, but there are certain, I would say, smells if your cloud operations team cannot keep it up to speed.

Wardley mapping

[00:11:50] So one of the techniques I use in the book is called Wardley mapping. A guy called Simon Wardley from England has got this way of plotting the evolution of technology. So really, start with your customer need, which is the board member here at the top, and there's a visibility axis from what they see at the top, business value, to what's less visible at the bottom. Your board member may be frustrated about the lack of business value, but they can't see how mature the engineering skills are or the modern cloud operations.

[00:12:23] From left to right here you've got the evolution of capability, and this works for technology capability regardless of the role. There's always this evolution from left to right. When something first comes up, it's genesis, it's novel, there's this brand new thing, it's wonderful, it's so exciting, we just want to learn about it. As that starts to evolve, it becomes custom built or emerging, and so we understand this thing is now possible, we start to get it but we're not quite good at it yet. Then something evolves to be productized, where we're getting good at it and there's market demand. And then it evolves to be commodity: it's best practice, it's the cost of doing business, we just know we need this thing. Every technology and capability moves from left to right.

[00:13:08] So as you plot this value chain on this map, you can actually see where you would place these things, and the movement. As you do this as a team you can actually plot the movement: what are the things we need to do to move these things from left to right? And then there's inertia: what is the inertia that will stop that movement? So this is a technique I've been using for over 10 years now. We've pretty much mapped everything, and it is like the secret sauce. It's the way you can pretty much tell the future, which is crazy. In technology you can pretty much map out a landscape and predict where the movement will be, so you can get a step ahead of it.

Moving the capabilities from left to right

[00:13:45] Now for our second transformation problem here, some of the things that we talk about in the book is this idea of how would you move some of these capabilities from left to right. So business value: we will often have a business goal which is very well understood, but do we have an engineering North Star? Do the engineering teams understand what that business value is? So often, having an engineering North Star, you can translate that business goal to something engineering teams will understand.

[00:14:15] For leadership, psychological safety is something that will move that from left to right into that kind of good practice area. Creating psychological safety, the ability to challenge thinking, to challenge ideas. We stay with the goal, let's challenge how we get there.

[00:14:30] For your technical leadership, people say technical leadership is magic. It's not, really. All the cloud providers have well-architected frameworks, there are very clear definitions of what's good architecture and what's not. Use something that is good practice. Don't let your technical leader invent the architecture. Technology is not that new.

[00:14:49] Next, for your cloud skills, you have to create a learning environment. Learning doesn't have to be classroom, it can be virtual labs, workshops, coaches, guest speakers. You have to invest the time in training, because a lot of the really good cloud content is free online. You need to train your engineers.

[00:15:08] And finally, and this is probably the most hidden one, your modern cloud infrastructure. A lot of infrastructure teams are working on custom built environments that are too confusing and they're tying themselves in knots. Go to your cloud provider and ask them for their best practice and use it. Do not reinvent the wheel. Companies are not very good at creating cloud infrastructure. Use their best practice. So these are a lot of what I would call techniques to move these things from left to right.

The value flywheel

[00:15:38] So really what the book's about is that idea of a value flywheel. When you think of the iterative nature of what I've just spoke through: if you feel clarity of purpose, your engineers need to understand exactly what you're doing and why, and there's really good partnership between product and engineering. Challenge: creating that environment where people can speak up, challenge the thinking, not the person, and understand why we're going where we're going. Next best action: if you train your engineers well they can use the latest managed services and serverless technology to build quickly. And then finally, long-term value: if you've got good architects and good technical leaders, they will know what that long-term roadmap looks like and bake it in. And that all sits on what I would call a foundation of modern cloud operations. So this is exactly the model I use for many years in Liberty, with great success.

The voice assistant story

[00:16:31] So let me break on a quick story about how to illustrate that. Back in about, I think about 2016, we were just starting to pull together the idea of a serverless first kind of approach, still feeling the way around. Obviously as a big insurance company we had a lot of call centers, a lot of kind of hooky telephony, we won't name any of the vendors, stuff was very old-fashioned and slow, and we had lots of people sitting answering phones. And with this idea of chatbots all the rage, we had the idea of putting a chatbot in and they'd answer some very basic calls.

[00:17:09] So we had pitches from a lot of the biggest vendors, I'll not name them but you can imagine who they are, telling us they could do this and that, and they had all these fancy AI technologies. So we said, let us build a prototype. We think we can build a prototype in 12 weeks, and some of the vendors were saying, well, we can give you a proposal in 12 weeks. We said, no, let us build something in 12 weeks and we'll see what happens.

[00:17:32] So our idea was, using the serverless first approach, we would use the same technology as Alexa, which is Lex under the hood. We would use Amazon Connect, which is their call center in the cloud, and we would rapidly iterate to build this capability. So we built a fully functioning voice assistant in 12 weeks, and it was quite simple. If you called in and you hired a car and you couldn't remember where to pick it up, you could say, I hired a car, where should I pick it up, and it would give you an address. Quite straightforward. But we got that in production in 12 weeks, taking 150 calls a month. Really simple, tiny for a company that size, but it was working and live.

[00:18:13] Fast forward two years, we started to ramp up the traffic. We were asked to do a talk at AWS re:Invent, which is their global event for technology, to demo the solution. That's one of the architects, Laura McFarland[?] from Belfast, or should I say Laura in the middle there. We talked about, as we ramped up the call volume, recognition was over 90 percent. We're starting to add in more conversations, it would do things like it would understand yes, uh-huh, aye, a lot of these things. We were tuning the model, we were getting really low call deflections and really low callbacks. Fantastic customer experience. One of the funny things we got was, can you make it more robotic, because people like to bark orders at the chatbot. So we were baking all that stuff in, starting to build up traffic, maybe around 200,000 calls a month.

[00:19:07] Then covid hits, 2020. So what's the one thing we never designed for? In an insurance company you never design for no claims. But obviously, as lockdown started, people stopped driving their cars, the claims stopped, the calls stopped. So because this was a serverless cloud-based call center, it scaled down with less traffic, so you stop paying hosting fees as the traffic scales down. On the flip side, overnight there was a decision made to repay a lot of premium, so our outgoing payment system ramped up. Both serverless systems: one scaled down with lack of traffic, the other one scaled up. Two completely unpredictable situations, but the systems handled it without extra changes.

[00:19:55] Fast forward another two years, 2022, that's one of my old team members, Matt Coulter, on stage speaking at the keynote of re:Invent about the serverless first enterprise that Liberty Mutual is. So again, going from a crazy idea from a few architects to actually being on stage saying this is what a serverless first enterprise is. A huge journey over the space of a couple of years.

[00:20:20] Looking forward, if you think of what that was, this is not a quick fix. Back in 2016 there was clarity of purpose. The engineers thought big, on being completely customer-centric: how do we completely revolutionize how we manage call centers, how do we build a serverless call center in the cloud? Challenge: we assessed that on a Wardley map, we mapped that entire landscape back in 2016. But we didn't put a date on it, like, Matt will be on stage in whatever, 2022. But we mapped out that entire journey. We could see what we had to invest in, what we didn't want to invest in, where we needed to focus on the customer experience of the voice assistant and the scalability of those systems.

[00:21:04] Next best action: everything was serverless, which meant a lot when that scale came, AWS handled it. And then finally, long-term value: we used the Well-Architected process all the way through to make sure we had security, cost optimization, operational excellence, reliability and performance, so they were all baked into that product right the way across. And this is one project. There were probably like 10 or 15 projects like this, this happened right across the enterprise. And again, this is just a different way of thinking. Engineers want to build, but taking this approach engineers start to think about what's the business value that we need to create in the cloud, and not getting obsessed with is it Kubernetes or Docker or whatever else.

The value flywheel effect, and the book

[00:21:46] So within the book now we've got this model which is called the value flywheel effect, and again it's these four stages. Clarity of purpose, and really this comes from the top: you need to be crystal clear what you're doing and why you're doing it. So some techniques we find really useful is the North Star by Amplitude, which is fantastic, and even measuring time to value. We often talk about, can we measure innovation? No, measure time to value, worry about the innovation later.

[00:22:13] Challenge: create an environment of success and psychological safety, but put the Wardley map, the strategy, on the wall, and challenge that map thinking. What if? Here's an inertia point. What about this movement? Let's move, how do we move that across? That opens up conversation, so that we can challenge each other.

[00:22:30] Next best action: create a brilliant developer experience. Your users can go fast, and train them in the latest technology, they will absolutely blow away your expectations. And then long-term value: create a problem prevention culture, where we eradicate problems before they happen. Use best practice like Well-Architected to measure goodness. And then we even start to talk about sustainability as a way of measuring success, but there's more of that in the book.

[00:22:57] So that's the story. What I've done is I've captured that whole technique and detailed it with Wardley mapping. There's four case studies in there, which is Liberty Mutual, BBC, A Cloud Guru and a startup called Workgrid Software. It's published by IT Revolution, a US-based company, at the end of November, and it's part of the DevOps Enterprise stable, so other books in that label are things like The Phoenix Project, Accelerate, etc. We have a blog called theserverlessedge.com[?], a bit of Mastodon and Serverless Craic.

[00:23:30] And it would be really interesting to see what you think of the book. For me, I think the ability to think of modernization, not just migration, that ability to merge business and technology strategies, is absolutely priceless. It's so valuable. The amount of companies that would come up to me and say, we've migrated to the cloud but the value is not there. There's an entire second transformation that we need to start thinking about. Thanks very much.

Q&A

[00:23:57] Host: David, hold on, let me see if we have any questions from the audience. Or very quiet after their lunch. We have a question just down here, I'm halfway down in the center aisle.

[00:24:13] Dave: I forgot to say, actually, I'll be doing one of the forums at four o'clock, we'll continue the conversation. So I think that's on the Empire stage.

[00:24:22] Host: And just on the Wardley maps, I think that's a really interesting area. Where can people find out more about how to use those?

[00:24:27] Dave: It's in the book. There is some case studies as well listed on YouTube, where people have used it. There's a whole bunch. There's a great site called Learn Wardley Mapping. The technique itself is pretty much open sourced, so there's a lot of great content. There's lots of information in the book about taking you on that journey, and how you do it, and tips and techniques. I would just Google Wardley mapping, there's lots of really interesting examples.

[00:24:52] Host: Great, anybody else? Okay, great. Like I said, David is part of the talks later on as well, so please do join him there. And David, thank you very much.

[00:25:03] Dave: Cheers, thank you.