 I hope you didn't just come for the pizza because pizza is out and content is on. Some people definitely came for the content. So my name is Gregor. I'm a smart nation fellow. I always like to highlight the nation is already smart. I'm just a fellow helping out wherever I can. So it makes for a very nice title and I work with GovTech, work with Chahoe and many other folks on our cloud strategy architecture in general. Today though I don't talk so much about just what we do as a government. There's plenty of cool things like I mentioned. But I want to take sort of slightly different lenses, sort of what does cloud actually mean. The reason that's interesting is because if you ask anybody today whether they're going to the cloud, the answer is of course, yes, of course, everybody's going to the cloud. And people don't just go to the cloud like normal these days at a minimum you're going to have multi-cloud, right? Because come on, right? Otherwise it's just for beginners. And look, oh, sorry, I forgot one there, there's one more, right? So if you go cloud, at least we do multi-cloud because otherwise it's just for children. And you know what? While we're going multi-cloud, at a minimum we are going to be cloud-native. All right, come on. How can you be not cloud-native? All you need to do is implement these things. This is the cloud-native landscape, right? I see AWS here, at least one thing I recognize, right? This is all you need to do, and then somehow you magically become cloud-native, hell yeah, right? And you're going to be so cloud-native that you don't even have time for cloud immigrants anymore, right? Because it's like, you're going to be so cloud-native that's all you're going to have, right? Fantastic. So everybody's in the cloud, everybody's going multi-cloud, everybody's cloud-native, sounds fantastic. So I have a really interesting study that I found why people actually go to the cloud, right? It almost seems like superfluous to even ask, but why do people go to the cloud? Well, the reasons are fairly straightforward. We want to save money, right? We want to improve uptime, right? The clouds, you have availability zones, all these kinds of things, right? You can make your systems run really well. You want to speed things up like you want to deliver and deploy software faster, and of course you want to somehow transform your IT. There's a few more reasons, though, which is, well, the developers just went to the cloud and we couldn't really notice, right? So we went to the cloud without planning, and there's another reason it's actually good for my resume. And if anybody believes the statistic, be assured this is completely made up. On the other hand, it's a fairly good reflection of reality. And the research company, you know, there's these research companies that have nice acronyms, like Dora is one, like the DevOps Research and Assessment. So this comes from the cloud research and prognosis. So that's where this research comes from. However, this matches reality fairly well. And one of my pet pieces, I like to learn about architecture from real life. So let's put the cloud thing aside and let's look at real life, what all our hybrid, multi-cloud native thing looks like. And it looks very much like these things, right? Very nice, shiny objects. Who wants one? Well, I do, certainly. Give me all three, right? This is multi-hybrid cloud native all right there. Now these things have a name. They're called wishes, right? These are things that you would like to have, right? That you're wishing for, but, you know, more likely than not that you don't really have. Now, that is a little bit sad. So if you want to make some of your wishes come true, you need to have some concrete goals, like getting a good education, saving some money, right? Things become a little bit more concrete, like the boat and the Ferrari are not going to materialize, right, until you have some goals along the lines. Now, of course, these goals also don't materialize out of nowhere. So you need to do some things. You can study, you can inherit. Other people have a different strategy, which is winning the lottery. And then there's people who sort of think they're going to rob a bank. But to be honest, that is unlikely to get you either to your goals nor to your wishes. You're going to live in a very big house with many rooms, but that's called prison. That's not the house you wanted. So if you want your wishes, you better have clear goals and a clear strategy. And the reason I'm making this little detour is because I do see a lot of wishing in cloud, a lot of buzzwords, a lot of shiny objects, right? We didn't quite get to the cloud in the first place, but at least next time it's going to be hybrid multi-something cloud, right? So the wishes, having wishes is relatively easy, right? Now, since we're learning from reality, there's another hard lesson. Reality is just, you know, life isn't 100% fair. So there's another hard lesson, which is buying these is not going to make you that guy, right? So, you know, just like the sneakers, don't make you the coolest rapper dude on the planet. Just provisioning something in the cloud is also not going to make you digital transformed automatically. This is called marketing. And there's always a small gap between marketing and reality, right? I say, marketing is a great thing as long as you don't believe everything you hear, right? So, you know, more bad news. So now that we're all depressed, right, we had all these fantastic wishes about the cloud and we thought we're going to be like super cool, right? Mr. Rapper dude, big house, big car, big boat, right? That didn't quite happen. So now it's time to actually look back at cloud and have a different point of view. Fewer buzzwords, but a bit more thought provoking. The first one that I like to highlight is when people think about cloud and embarking on a cloud journey, they tend to look at, well, what does cloud bring? Well, the first thing they see, servers, network, storage, right? They see equipment, infrastructure, right? That's what you do, right? The first thing you do on AWS, deploy some EC2 instance, right? Or something, right? That's how you start. So the way they go on the organization is they look first at servers and network and storage. Now the reality is nobody wants a server, right? People want to run applications. Servers are known as those things that cost a lot of money, consume a lot of energy, right? Produce a lot of heat and obsolete in three years. That's a server. Nobody wants, right? So in the end, people want to deploy applications. And that's why if you see cloud as an infrastructure topic, you probably made the first major mistake, right? It's not about infrastructure. It's about changing the way you build and deploy applications. So that's first lesson, right? It looks like infrastructure. But if all that cloud was, was another kind of data center, it wouldn't be half as exciting, right? Nobody would be talking about it. We had outsource data centers for decades, right? So cloud is a different lifestyle, not a replacement for your data center. Second one is when we talk about enterprise cloud, right? So enterprise wants to go on the cloud or any large organization. Even I would include us. There's sort of a few things you need to keep in mind. You can't just run off of the credit card and everybody just like go provisioned servers left, right, and center, right? That will not work. So you need a few things. You need generally an onboarding process, some billing approval, right? Who's going to the cloud? Who's going to pay for it? What cost center you have, it makes a lot of sense, right? You will need some sort of hybrid approach, right? You're not going to be able to move everything into the cloud overnight. Some stuff will stay on premises for us as the government, particularly true, right? Well, we're not so keen to share our cloud with just like anybody else, right? So what do people do? They get a virtual private cloud, right? The cloud providers offer that, right? And then usually there's some stuff to do still internally, like open firewalls and some other things, right? You just carry a little bit more weight with you that you need to take care of when you go to the cloud. And lastly, IT departments like ours, like GovTech, we need to recover our cost, right? Building this enterprise cloud, these things on top of the public cloud cost some money, right? So somehow we need to recover that from our customers. Now, this all sounds entirely reasonable, but there's one catch. As many of you know, the NIST, like the National Institute of Standards and Technology has published five properties of what a cloud is. And this has been around for many years, right? It's on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. Now, the unfortunate result is, if you look at the things on the left-hand side, they unfortunately exactly the opposite of the right-hand side, right? The onboarding process took your rapid self-service away. The hybrid approach, right? Your network just isn't the same as the internet, right? Your private cloud isn't as big as the whole cloud, right? The service requests make the scaling a little bit slower and harder. And you know, the cost recovery doesn't make it a measured service because somehow you need to have a baseline cost. So the sad thing is that in the end, if you follow this approach, you lose the label, right? This is no longer a cloud. So this makes bringing cloud to enterprise ever more interesting, right? And we are part of this journey, right? We're trying to be a little bit smarter than this, right? Because this is sort of the classic pitfall to fall into. We take the cloud, we get all the buzzwords and then we wrap it in enterprise, right? And then all the abilities go away. Please don't do that. Now the answer to that is you need to rethink and rework the way UIT works, right? If you layer this, just copy paste on your existing IT, you don't get a cloud, you get another data center. And no CIO ever needed another data center, right? So the only way out of this is you need to rethink how your IT functions, otherwise you will do exactly this and that's very dangerous. Last one is when people go into the cloud, they sort of wonder about, well, what about the applications which aren't so cloud native, right? We have a lot of commercial off-the-shelf applications, packaged applications, there's a lot of stuff, right? How are we gonna get that to the cloud? Because it may not run in containers, it's certainly not serverless, right? It might not scale out. There's a third lesson to be learned and the third lesson is running other people's software is actually a bad deal, right? Most of IT, like we spend like often 60, 70% of our budgets running other people's software, right? Obviously there are great stuff, I mean there's SAP and Oracle financials and HR systems, right? And CRM system and all that kind of stuff, right? We run this all, but if you think about it, it's actually a very bad deal because you pay for the hardware, right? You do all the installation, if anything goes wrong, it's your fault, right? Because it runs a new infrastructure and if you want a new feature, you're gonna wait for the next feature release because it's not your software. So the hard lesson here is all that stuff that you have, the short answer is you shouldn't be running at all, right? You shouldn't be like making this container ready, et cetera. And we know the buzzword that stands behind this answer, right? This is what software as a service means, right? Software as a service means don't run software that you didn't build. You use Workday, you use Cloud CRM, you use Cloud Integration, whether it's Salesforce, whatever it is, right? SAP in the cloud, all this stuff is available. So the vector here is clear. The things that you don't build, you have somebody else run and you run in your cloud stuff that you build yourself and that's why it's not about infrastructure but it's all about application, delivery and velocity. So quite different view, right? Nothing to do with servers, as I said, nobody wants one. So let's translate that into a strategy, right? So we now kind of know what some of the pitfalls are and have a different way of thinking about cloud. Now, that alone doesn't make a strategy. We have some goals, right? But we still need a strategy. Remember, we have like four possible strategies. So in our case, the one that always comes up is multi-cloud. Everybody talks about multi-cloud because you don't want to be locked in. Maybe some cloud provider has a nicer feature. Reinvent is going on this week or last week, right? So there's like 40 new AWS features and the next equivalent from the other cloud providers will come, right? Now, when I look at it as an architect and this is actually a blog post from my website here is, I see very different flavors of multi-cloud. The one that nobody wants to really admit is but you randomly have some stuff in one cloud and you have randomly other things in the other cloud. This is particularly true in the pillar. My developers went in the cloud already and nobody noticed, right? Because they go wherever they think it's best. What I see a lot when I worked at Google Cloud for a little while, I saw this quite a bit, right? A lot of people came to Google for the analytics, like BigQuery and stuff like that. But to be honest, a lot of the VMs and computing stuff was still on AWS because it's just way earlier to market, right? So you segment, right? You have some things like workload, normal compute you have here and then maybe data analytics, machine learning you have there and maybe some other things you have in a third cloud, right? Big step ahead. Or you can give people a choice. So for whatever application they have, you can say, I allow you to go to this cloud in this cloud. That's how GCC is built. Because as a government, A, we like to have an open mind and B, we have a mandate to have a neutral spread across vendors. So GCC gives you this. Our government commercial cloud, right? You have an application, you want to deploy that on GCC. You can choose. You can have AWS, you can have Azure, you can have GCP. Then you can do more clever things if you want, right? You can tell people, oh, I can deploy here and I can deploy there at the same time. At that point, I would ask you though, be careful to know why you're doing this. So for example, you might want to do this for resilience purposes, right? Fair enough, right? But you need to have a good idea why you're doing it. And the last one is sort of the nirvana, right? Where you just move stuff to the cloud and it sort of magically shifts left and right and there's always this scenario about, oh, if this cloud provider raises the prices, right? I just take my stuff and drag and drop it to the other cloud and I tell him, ha, see, right? I got here, right? So remember the wishes. Everybody's wishing for this, but most people are actually here, right? They have random stuff in random places. So what I'm trying to say is these things are not black or white, right? And having an architectural thought about it and understanding what the different sort of patterns or reference architectures are and choosing wisely. Like for us, this is actually a great thing. We have a few systems where we might want to this and to be honest, this is kind of rare, right? It's rare that we need to sort of shift applications willingly from one cloud to another, right? Looks good on paper, but in reality, not very much needed, right? Those are the shiny ferraris that you're probably not actually gonna get. So very, very different look at multi-cloud, right? Nice buzzwords. You need to check reality. What do you actually need? What brings you value and what kind of architecture stands behind it? Here are some of the trade-offs, right? I probably have a bit much text to read on, but message here is none of these are free. One of the reasons we don't go to shiny object land is because this has some disadvantages, right? It's like complexity, right? It's just a lot of moving parts that you need to manage. And you know what? You might not be locked into a specific cloud, but now you locked yourself into a multi-cloud framework. Now, is that better than being locked into one cloud provider? Now you're locked into somebody else's multi-cloud abstraction complexity layer, right? I don't think you've got much better off, right? So you need to make these conscious decisions. All of these have advantages, right? And all of these have some disadvantages. That's the business of architecture. Let's look at the next buzzword, hybrid cloud, right? Hybrid cloud means some stuff goes, some stuff stays, right? You move some stuff in the cloud, some stuff stays, I promise. Now, you don't need to be sort of a PhD in cloud strategy to know that the next question is, well, what goes and what stays, right? And again, from an architecture point of view, many, many, many choices, right? You can move the front then out and keep the back end on, very popular. You can also put the new things out because they're more likely to be cloud native with air quotes, right? And you keep the old things on premise, right? But you can also, some people wanna test the water. They put some non-critical systems out and keep the critical ones, right? And the list goes on, right? For us, by data classification, right? So for example, we don't put secret things in the public cloud, right? They stay where they belong. Things that may be restricted are okay to go. Some people are happier to stay on premise unless they need to do a disaster recovery and then they're happy to run in the cloud. So you can slice many, many different ways. So again, I have a whole blog post about this, right? The word is there's a lot of thought behind these buzzwords, right? So rather than chasing buzzwords, what we should do is actually look at these carefully and say, well, which one can we start? Maybe we do a little bit of this. We do a little bit of this. And that makes the difference between buzzwords and cloud strategy, right? That's the difference between a wish and having a strategy how to make the vicious become reality. Cost was one of the first things in my fake statistic and of course it's not that fake. Everybody wants to save money, right? IT is great, but if you can do it for less, that is even better. You will save money in the cloud but you have to be very clear about that doesn't come free. The cost savings have to be earned. Well, the first cost savings that you might get and you likely get this, by just moving to the cloud, you can shave a little bit of money off. Slightly better economies of scale, right? You get sort of sustained use discounts or a little bit of money you will save. But it's not gonna be like half or like 90% off or something, right? It's like hell. And then Amazon and Google don't buy the server for 90% less than you do, right? They have more efficient operations but it's not gonna be that much, right? Then my experience, the biggest one is you optimize what you have and then once you optimize, you can even get better and make it resilient and I explain what you mean. What I mean, sorry. The first ingredient you need to do in order to get from on-premise to cloud, there's migration costs. So it's not free both intellectually as well as from a dollar's perspective, right? Migration costs money. No, you need to do that equation, right? To be honest, most of the time or many times this equation comes out sort of closer to zero, right? The migration costs, your applications are not gonna be sort of perfect for the cloud, you're learning new stuff, right? It's gonna cost some money. So if you break even or save a little bit, you're actually in pretty good shape. This one though can be a big winner and there's an ingredient that is often underestimated as being valuable in the cloud and that is transparency. Like now you're in the cloud, you can see your utilizations, you can see your applications, you can see your workload, you have much, much better overview and you can see all the servers that are not doing much. You can see oversized infrastructure, right? You can see redundant machines, machines like orphans that were left behind that never did anything in the first place, right? Transparency in my experience, this is actually, that's where the money is, right? So a lot of people do this and get disappointed, right? And they forget that actually here is where the money is. And then of course the next one is automation, right? And I can explain why automation is actually such a big ingredient into savings, right? When people think about automation, they think it's about reducing manual labor, right? It's like, oh, if it's automated, you don't need anybody to click the buttons. That is totally not the main goal. The main goal of automation is to reduce our overall operational cost. And the way I'll illustrate this, this is a blog post I wrote for Google Cloud, right? We see we have sort of classic CIO agenda, right? What does IT need to do? Well, nobody wants to be in the front page of the newspaper, right? It's gotta be secure, right? Nobody wants to pay for IT that isn't actually running and please, as we said, don't spend too much money while you edit. Yeah, when I worked at Google, I would always go to the customer and say, look, I have all this cool stuff, right? I can bring you automation, speed, feedback, you know, machine learning. I can bring you all the cool things. And the CIOs invariably would say, hey, dear Google guy, that is all really cool, but you know what, my world is very different, right? They're like, I totally get what you're pitching me, right? But it's like my world is very different. Then now we need to think about what's the most expensive server? Well, the answer's relatively easy. The most expensive server is the one that's not doing anything. And you know what, if you get it for 20% cheaper, it's still the most expensive server, right? So don't try to get 20% of your servers, figure out which servers aren't doing anything. So what are the servers that are not doing anything? Most people's data centers are full of servers that aren't doing anything, and the reason is very simple. Availability, how do you buy yourself availability? A warm standby, right? You have redundancy, that's the way. You get availability, huh? Now what is redundancy? Redundancy is most of the time, unless you have a fancy, active, active, whatever, right? Most of the time redundancy is you have a server that's not doing anything. So what you're realizing is that actually in the classic IT, we believe that cost and availability oppose each other, right? The more highly available I need to be, the more money I need to spend. And we totally forget that the real levers are the levers on the left, because if I can provision new instances near instantly, I don't need all those warm standbys, right? They have this fully containerized, right? Maybe I run three instances, one dies, right? I spool up another one. If I know quick enough, right? If it's fully automated and I have fast deployment, I can be cheaper and more resilient. And that's why rethinking the way cloud words, that's the way you save the money, because otherwise you're always stuck in your own equation, right? And that's why in the previous slide I showed, right? Having the automation, that's the money saver, right? Everything else is sort of a little bit of fine tuning. And a lot of folks get disharmed or disappointed early, so they never actually get there, and then they never get the full benefit of the cloud. And that's actually kind of sad. So my role as architect is, how people think about this in different ways. Last one I have is locking. I alluded to this before. And people wanna go to the cloud and then that's like, ooh, but I'm gonna be locked in. Like these days, like the press, everything is full. I need to be hybrid, multi, everything, avoid the lock in. As always, lock in things are not black or white, and lock in is also not black or white. The way you think about lock in, what is lock in? Lock in is something that gives you a high searching cost, right? If you wanna get out, it's not that easy. You pay a little bit of money. But that's not the only dimension is, lock in can also give you benefits, or vice versa, avoiding lock in is gonna cost you. So you need to see, of course, if I have a benefit for low switching cost, that is really nice, right? But I might be happy to be locked into something, right? If I get the benefit. Edgian Cockroft has a great talk opener that he gives. He asks everybody, who is worried about lock in? All the hands go up. And then he says, who is married? And all the same hands go up. And he's like, well, all right? The world isn't so black or white, right? So you can be happily locked in. I'm a little bit more devious than that. And I say, who has an iPhone? Well, I see one right there. Because my example is, you're also happily locked in. Actually, some people sometimes more locked into the iPhone. There's a statistic when people wake up, what percentage of people reaches for the phone first as opposed to their partner. And the number is scarily high. So the Apple lock in is very real. Now, here's the one where you don't wanna be, right? But you don't get a utility, but you have high switching cost. And that's usually called mobile contracts. Sorry, hopefully nobody here. I picked US examples to be a little bit politically correct. Right? This is your 24 month contract, you know? That you get nothing. Then down here, where it's like little utility, but switching, that's like your adapters, your plugs, whatever, right? It's like, anytime you get a new one. Down here, it's a little bit harder. The best I can come up with is some chat applications where you're not as locked in because mostly they use your address book. So when you switch, your address book is still there. Your friends might not be there, but that's a different story. But from a technical perspective, right? You can switch between most messaging apps and your contacts, your numbers, transport over. But it's unfortunately a little bit rare. We have things in this category. But yeah, this is totally fine. If you get the value out of it, just use it. Another way to look at this is basically avoiding lock in is basically investing upfront to avoid a future liability, right? You're paying more now to switch more easily in the future. There's a couple of things you need to be very careful about is you need to consider the total cost, right? Because you're spending money right now to avoid something in the future. We call this reducing the cost of uncertainty. Well, that's the thing you can do, like buying insurance is a good thing. Generally work for a large insurance company before, right? Buying insurance is reducing the cost of uncertainty. You don't know what's gonna come. So you're rather paying now than they are paying big time in case something happens. Now, in IT though, you need to see how much it's gonna cost you. So let's say you wanna make your stuff portable across clouds, right? Well, it's gonna cost you some money. You need to learn Kubernetes, deploy some things, right, do some stuff. Let's say it's not even that expensive. Let's say it costs you like a couple of person weeks or something, right? Let's say it costs you like $20,000 or something, it would be actually very, very low, I would say, right? What is the likelihood you're gonna switch? Like in the foreseeable future over the lifetime of your modern app. Modern apps live like three, four, five years at best. Let's say three years. What are the chances you're gonna switch? Like 5%, 10%, all right? If I can't, how do I say it? Let's say it's 5%, right? So one out of 20. So if I spend $20,000 now, I would need to have a migration cost of $400,000, right? Times 20 to make that break even. Now, that would be high migration cost, right? It's like, it's not gonna cost me $400,000 to migrate my application. Or maybe cost me $40,000. Maybe worst case, it cost me $100,000, right? So let's say it cost me $100,000 to migrate my application from AWS to Azure, right? If the chance I need to do it is one out of 20, that is an effective cost of $5,000. For $5,000, I'm not gonna build myself a hybrid sort of multi-cloud, automated kind of provisioning, moving thing, no way, right? If somebody will do that for $5,000, please talk to me later. I'll be happy to retain your services, right? So be careful, right? As architects, we tend to be overexcited about investing now to avert things in the future. We feel we always need to have the option, but we forget the cost of it. So I highlighted the cost in terms of dollars, but there is a much worse cost because the end dollars kind of sucks, but you know what? Money you can usually find somewhere, there's too much worse cost. The one is complexity, right? And the reason usually things don't move quickly or they break is complexity, right? So complexity is very expensive for us because that's where a lot of the problems come from. And the second one is equally nasty. I go to the cloud because the cloud has all these managed services. I can get RDS, I can get BigQuery, I can get Aurora, I can get DynamoDB, I can get all this cool stuff it's fully managed for me. Well, if I want to be fully portable, then that kind of goes out the window, right? Because my stuff runs on Aurora or DynamoDB and I move this to Azure, doesn't work that well, right? Now I need to do something, right? So what people do is they actually deny themselves the main reason they went to the cloud in the first place, right? Because you want to have access to these managed services and now you're saying, oh, but I don't like to be logged in. So I'm not going to use any of these managed services. That makes little sense, right? So make sure the equation comes out for you, right? Don't be stupid, maybe you abstract some things but don't try to achieve a zero switching cost for something that maybe has a 5% chance of actually occurring, right? It might be fun from a technical perspective but this is the cost curve for you, right? It's definitely not the minimum. If you do that, you much rather want to be there. But with that, that's probably all I have and I hope I could move a little bit from the next time somebody says, are you going to the cloud, right? You can say yes, but I know why I'm going. I have clear goals. I have a strategy behind it and I have an architectural mindset how I'm going to do that. So thank you very much. Two to three questions. Oh, cool. I thought I talked enough that there's no room for questions. I was just giving away a few stacked t-shirts so no more questions asked. All right, somebody please ask a question. The non-Gov techies first. You can get a t-shirt anytime. Oh, yes. And I treat, oh, sorry, let me get this. I'm pretty sure you're preaching to the church but my question is after all of us hear this message we're all excited. We go back to our CIBOs and our senior management and we pitch this to them. Transits are they've not had the chance to sit in to hear this. Do you have any advice how we could put this in the perspective that senior leadership tend to be in go soaps or they tend to be not in go, and they need to see it from a business perspective. How do you pitch this to them? So I have like three answers. The first answer is you should have brought them along. So I mean all jokes aside, I mean this is, they always need to hear this. The second one is depending who it is, we might even go visit them. We have a mandate ultimately to help people understand. But the third answer is I find is that management can understand this quite easily. The biggest problem we have, if people don't become upper management by not being very smart or not learning new things. So yeah, that doesn't work. The challenge they often have is they grew up with a different set of technologies and a different set of base assumptions. Now when we come in and all we do is babble acronyms, like cloud native hybrid, multi-tenant la li la la, and then everything is, so I used to say that business complains about IT because we sound like we speak in Greek. And you know what, now we're actually speaking Greek. Everything is Kubernetes, Prometheus, Istio, right? It is actually Greek, right? So business has a point. So, but more seriously, right? So if you come in with the shiny object acronyms, they will not listen and you know what? They're actually probably right. If you come in with explaining the mechanisms behind it, which evidently I compressed this a little bit, but what I try to do is show the mechanisms behind it, they will most of the time understand. My job at Google Cloud was basically, I talk with CTOs and CIOs all the time. And the reason I came up with some of these models and this concept was that I can convey this to them. Second one is harder, but also doable, requires patience. You need to understand that they grew up with different assumptions. Give you a great example. When I was in Allianz, very, very smart guy, board member. Yeah, like top, top, top, making millions of euros, right? Super successful, super smart guy. And he came to me and he said, I don't like scaling out. Like he says like, scale out architectures are no good. I'm like, how can this be, right? All we do is elastic, scale out, resilient, right? That's like sort of our Bible, if you want to use the analogy. And this super intelligent man basically says, yeah, I don't believe in that. So what you need to understand there is you need to reverse engineer. So don't assume they're dumb or don't know or don't listen. It means they have learned something and made assumptions that were true at some point, but are no longer true. In this case, the answer was relatively simple. In the old days, scaling out carried a lot of overhead, right? Because you couldn't scale up that quickly anyway. And to be honest, nothing scales linearly, right? Twice as many servers don't give you twice the performance. So he saw that as a waste of money, right? I can buy a twice as big server and probably I get almost double the performance versus if I buy two servers, I need load balances and synchronizes and other stuff and B, I will not get double the performance. So he was looking at from an efficiency perspective, not from a scale perspective. And you have to admit, if you look from a pure efficiency perspective, scaling out is less efficient, right? The answer that we would have is, yeah, but it doesn't matter. Now that is a big jump, right? We know it doesn't matter. So what you will find is they have learned things and made assumptions based on that that were absolutely correct and are sometimes still correct, but no longer valid or applicable. And my tip there is you need to reverse engineer where these kind of beliefs come from, right? That requires some patience, right? I'll give you another classic example. People have learned that speed and quality opposes each other, right? People are like, when you hurry up, you know, quality goes down. We know that is not exactly true because all our DevOps automation kind of stuff, right? Does miracles, but they don't know that, right? So if you're talking to somebody who believes that quality and speed oppose each other and you're gonna pitch my sort of continuous delivery DevOps kind of stuff, that's gonna be a very hard sell because in the head, all the speed you're pitching, right? It's gonna translate into lower quality, right? So you need to speak the language of the folks you talk to and reverse engineer their assumptions and then you need to basically prove to them or show to them why the world has changed so much because the tough part is most of the time they have living proof for their assumptions. Like they made a change and everybody stayed up three nights straight to fix it, right? Or they rushed the project, right? And they cut QA because in the old days, you know what they did? QA was always at the end. So if you cut the project by a month, QA took the hit and you know what? The quality was actually lower. So they have living proof for their beliefs. So you need to be patient and basically make one step back before you can take two steps forward, right? So one, don't come with the buzzwords, right? Explain to people, they will understand they're smart folks. And number two, if somehow it's not connecting, it's not because they're not listening and it's because they have some belief stuck somewhere, right? That they learn that you need to get them to unlearn. That's what I do most of the time, right? That was my job. So I can happily say it can be done, right? Not easy, but it can be done. I think there's probably only one more question, right? Okay, one more, yes? We need to have some tips on how to reverse engineer. Ah! Yeah, I call it debugging and troubleshooting, right? We engineers are very good at this, right? We see a system which doesn't do what we want, right? And we need to find where it's falsely programmed. So all jokes aside, the exercise is a little bit like that, right? You're observing something where the system is not, the system in this case is your organization or your management, right? It's not behaving the way you want. We have a name for that. That's called a bug, right? If our system doesn't do what we thought it does, it has a bug, right? So with that is you need to basically reverse engineer. The best, there's two good techniques. The one technique we use way too little is ask them. Ask them, why do you think that is? Like honestly, right? When somebody says like, oh, I don't believe in scale up. So yeah, that's surprising. Why do you think that is? That's how I found out, right? I said, like, why do you think that would be? And he said, well, I never scales linearly. And I said, and I'm like, oh my God, yeah, he's right, but he's also wrong, right? So ask us the easy one. The other one is the list of beliefs that classic IT has is not infinitely long. So there's a cheat sheet, all right? And now I'll be a little bit self-serving because I have a book here which I have on my website. There is a new chapter which is actually in the book. I'm working on updating my book and one of the chapters, it's gonna come out with a Riley in sometime next year. There will be a chapter where you basically get a, you get a cheat list, right? It's sort of classic things that people believe like, people believe you can solve everything with more money and more people. People believe that quality opposes speed. The list is not infinitely long. So having a cheat sheet goes a long way. Good, with that I think we have a lot more exciting stuff. Thanks for listening.