Les Cloud Natives peuvent-ils apprendre des entreprises ?

0:00 Quand on est dans le cloud, on est plutôt agile. Et on se demande comment conserver cette agilité quand on décide de croître, quand on a cette croissance qui arrive. Et peut-être qu'il y a des choses intéressantes à tirer des entreprises plus traditionnelles qui ont bien commencé en étant des start-up elles aussi, en étant assez agiles. Et donc, je vous demande d'accueillir Pini Reznik, CTO Container Solutions, qui va nous donner beaucoup d'informations à ce sujet. Pini Reznik. Hello, how are you? I forget to say that the conference will be in English. Unfortunately, I won't be able to make it in French. Thank you so much. I can try, it won't work very well. Thank you. You're welcome. Good afternoon. Yeah, and again, sorry, no French. So my name is Pini Reznik.

1:01 I'm CTO and co-founder of Container Solutions. And our main work is related basically to cloud-native transformation. And that's what I'm going to talk about today. What is cloud native? What is cloud native transformation? And how different smaller companies are from enterprises? That's basically the story. Before I start, so we as Container Searchers are organizing all this thing, WTF is cloud native. If you really want to know more, you are welcome to actually join and subscribe and join the conferences and other things. Right, so this is the story of Wells Grid, which is a fictionary company. It's sort of true story from other companies, but I'm going to tell it about the Wells Grid. And normally I'm talking to the crowd of enterprise-related people, so there will be a bit of twist towards the middle and the end of the story.

2:14 But this story is about a journey. It's not about a journey, it's actually about the stranger. So there are two types of stories. One is a person goes on a journey, and another, a stranger comes to town, and this one is about the stranger. And WealthGrid is basically, it's a company that is actually quite nice to work in. It's maybe 20, 30 years old. It's in the financial industry. If you can recognize Which office is this? Who can guess? Yes, Sony. Yes, that's a really, really old picture of Sony offices with PlayStation 1. So it's obviously not old school, but it could be, right? Old cubicles and stuff. But basically, it's a very successful company. Financially, they're great. They have great business. They're dominating in their market, whatever the market is. And within this company, there are people, the CEO, his name is Chris, Jenny, the middle manager and engineers, and Jenny is the main character of the story.

3:24 So she's technical middle manager, sort of a group manager of development or operations. So who is the stranger? Who is coming to Wells Great House? And there are a variety of different things. For example, it could be a traditional bank that becomes, like they say, a tech company with a banking license. So this one is from Netherlands, ING. Another one is Starling Bank, which is... A new startup from UK, which became a bank, actually serving first customer in less than a year with less than 20 people. So actual bank. Today there are way more than 1,000 people and way more than a million customers. Or it could be Amazon, who apparently holds a... banking license. They don't do banking, but they could. They also did in the supermarkets, all kinds of other things. They decided to do it, and then they are very successful in that.

4:26 But most scariest one, the scariest one is InnoVille, which is also a fictionary company, which is a new contender to the market. It's quite similar to Wells Good, it's just much more modern, and obviously with this very fancy modern office. I'm sure there's some sort of pool or billiard, some other tables there and everything else. At this point, Jenny is the one to recognize that the change is coming and something has to be done. And the first reaction is, you know, how hard can it be? Let's do some containers, microservices on Kubernetes and public cloud, right? So it's a naive approach, but unfortunately, that's what happens in most enterprises. They just try it, right? Just put it in a backlog and go for it. And about 6 to 12 months, optimistically, often much longer, they realize it's not going anywhere because very little is delivered.

5:27 There are some bits and pieces. There is a bit of Kubernetes running in something, but obviously nothing in production, not even remotely. It's absolutely not going anywhere. Okay. And there is a lot of pressure to deliver features. So actually, there is no space to work on the new stuff. So, okay, let's do something else, right? So that didn't work, let's do something else. Something else is to go full in, right? Commit, prepare a plan, go to CEO, to the board, to everyone, get the approval, And of course, they can convince the leadership to allocate the resources to this because, you know, we'll spend maybe six months building this platform. And after that, we will deliver twice as fast. Right. So it's obviously beneficial. Of course, it takes about four months to prepare a plan and architecture and everything else, right? And 6 to 12 months.

6:30 And later, nothing happened yet, still, again. And that's despite the fact that there was quite good estimation and everyone knew what's going on and they sort of had the right idea of what needs to happen. So at this point, the CEO is very unhappy because it's not just there is some tiny project that is not succeeding. Who cares? Right now, we took half of the team or a third of the team from the existing products that actually bring the money. So we're delivering less value to existing customers and there is nothing in production. So it will never work out. Right. It becomes really. The biggest fear is losing control. And CEOs, they like their control, right? Especially in enterprises. And then because it's now not a tiny story within the engineering, so that there is now CFO is also screaming, right? This is like, this is endless speed of money, right?

7:30 There is no ROI, there is no delivery, there is nothing happening. It's only pouring out money and nothing coming in, and there is no even end to it, right? So this is not really good situation. At this point, typically, will come some sort of ultimatum. You finish it within four months or else. And else could have different versions, like we will outsource it to some other company. We will shut down the project. We will do whatever, right? So they're... Very different things. We'll fire everyone, right? So it's never good. So, again, We need to do something different. So why is this so difficult? And this is not something that is happening once or twice or three times. We have seen it consistently over and over again in dozens of companies every single time. This is the story. There is Gen 1, Gen 2, and there are variations of every single time.

8:33 So the problem is that there are different stages of product development. And product is roughly, could be also said about any initiative, right? So cloud native is quite a big thing, so it's the same, right? And in the beginning, in development stage, you see there's quite little investment and there's very little outcome. There's no outcome at all. And gradually it becomes actually quite stable and brings the money. So this is classic model. It should be very easy to understand. There's a different way to present exactly the same story, just a slightly different angle, which is the innovator's dilemma, which is also a very commonly used model. And the general idea is that existing technology, that's the mature technology, that's the products that actually bring the money to the enterprise, at some point they stagnate, right? They slow down and they need to be replaced with new products. new products. So this thing on the blue line is called sustaining innovation and jumping to the red line is called disruptive innovation.

9:40 And those are drastically different things. So the reason there, this is again sort of the same model and different angle, is that in the beginning, when a new thing starts, when the red line starts, it's sort of, it's not straight, right? It's actually quite crazy, right? It's an event. No one really knows what to do. So it goes all over. It's mystery, right? No one knows how to deal with it. Then you sort of get the idea, and eventually it becomes the algorithm. Imagine McDonald's. Early days, they invented a thing, right? So drive in instead of drive through or something the opposite. So people actually had to approach the counter. No one knew if it's a good idea or a bad idea. They just tried. And they succeeded. The first restaurant succeeded. Second, third, fourth, they got the idea. Fifth failed. And then somebody else came and created McDonald's of today. So today it's algorithmic. You get a book, and then you do exactly the number of seconds. To get perfectly consistent results.

10:45 So the enterprise's problem is this beginning of this story, right? So the innovation, because they're actually really good with algorithms, right? So they are delivering value, they are consistent, but they struggle with this kind of uncertainty and craziness. And this is something that we thought how to talk about these things. Because people keep coming to us and asking, like saying, you have done it before, can you do it again? Because, you know, you just repeated what you've done it before. So there are two different ways of, I have done it before. The first one is like a taxi driver. Taxi driver, imagine a taxi, right? So a person who is driving a taxi, right? So a person who is driving a taxi, right? around the city. Not every journey is exactly like the previous one, but they're pretty much the same, right? Everything is predictable, consistent, there are tools, just using the tools, right? It's very different from an explorer. But explorers also have done it before, right?

11:47 So they went to one island and another island and another island. It's a very different way of doing things, right? They have sort of an algorithm of which is different, different algorithm. They have sort of like... A way of getting around. Find water first, food second, shelter, or the other order. There's some order of things that is consistent and repeatable, but it's not predictable. Imagine using a map from the first island on the third island. It makes no sense at all, right? So the idea is that at the end of blue line, you want taxi drivers. In the beginning of red line, you want explorers. And gradually, when the red line will become slow, then you will want taxi drivers there too. So it's a different way of doing things. Again, in the beginning, it's exploration, it's research, it's uncertain, it's crazy, right? And at the end, it's very predictable.

12:49 Now, it's not that explorers are better than taxi drivers or the other way around. It's absolutely not true. They're essential in different ways. Imagine putting an explorer, somebody who is climbing the mountain, and a taxi driver every day, in a taxi to drive it every day. They will not like it. And I'm sure when you think about developers in your own companies, you can feel the difference. People who are happy doing the same thing over and over again and also want to do something else every day. And the way we see it is that generally cloud-native transformation is perceived as a technical. This is cloud-native maturity matrix that we created at some point to explain what cloud-native is. So we feel that cloud-native is not just a bunch of technologies. It's also organizational change and cultural change and all kinds of other things. It needs to be seen as a holistic change across the organization. That's why it's not understood well, and it's perceived as a simple technical change to the existing sector.

13:51 But if you consider cloud native as full organizational digital transformation, then you understand that you need to treat it with respect to full transformation. So what we would typically do is we would understand the current state, we would understand how the target state looks like, and then we would create a path towards that. And that path would start with a small team and explore. And I'll talk about this in a moment. So this is exactly the point. So cloud native is difficult. So first, if it's a new initiative, it needs to be treated like a product lifecycle. Start slow exploration and eventually going somewhere. Something like this. So it starts from strategy, set up small team, cross-functional team, do some research, some POCing, eventually deliver MVP to production quite fast, right? So it has to be fast. And then gradually onboard more and more teams and create some sort of strategy with education and other things.

14:58 While the existing business actually may It's the same for quite significant time. And then there's gradual transition to the next one. So Cloud Native is not a product, but it's a significant transformational initiative that needs to be treated as a company transformation. So the mistakes that happen often, two most common mistakes in this situation is, one, to put too many people up front on the project, which is a mistake because they try to do too much and then it just doesn't work. I won't go. There's this book, Mythical Men Months. It totally explains why it doesn't work to put 50 people in the beginning of this transformation. And the other thing that doesn't work, and for whatever reason everyone is doing, is lift and shift in the beginning. Look, it's like you talk to people, and they say, we know it's terrible, and they still keep doing it. Not because it's wrong, but because...

16:01 It will take longer than expected, and there will be no money left or credit from the business. And by the time you have three VMs on the cloud, the business will lose interest, and there will be no rest of transformation. It's more psychological thing than technical. So this is more or less how it works. That's, in our opinion, this is a right way to the transformation, business case, executive commitment. I won't go into too much details. There are all kinds of things that need to happen in a certain order. Otherwise, the transformation won't be successful. This is correct for almost any transformation, but particularly to cloud-native transformations. And there are all kinds of things, and it starts from strategy, and gradually it gets into more and more technical. Eventually, the technology is important. But it's a slow process. It doesn't have to be slow. It can be fast, but it has to be incremental. So this is the book where the story came from.

17:05 Welcome to... You can buy it, or in three weeks we are going to share a digital version for free if you want to wait. The thing is that, okay, so now we understand how to do this transformation, and it can happen, you know, it takes three or five years to actually go through this, but Jenny gave up, right? So she's already 15 years in that company, she had enough, she wants to do cool things, right? And of course, she moves to Interworld, right? Because it's fun. I mean, with this office, it's like, how bad can it be? Now, it's actually much more fun. For a person, especially for a person like Jenny, it's actually a lot of fun. The reason is because, obviously, Jenny is a proactive person who wants to make change, right? And that's the place. Inner wealth is the place. place to make it happen. So the life is actually quite good for this kind of creative, innovative people who want to make a difference.

18:08 Changing direction is not an issue. There is low hierarchy. Things are actually moving forward all the time. But of course, it's not all perfect. It never is, right? The difference is in InnoWells is that there is a lot of pressure from all directions and there is no clear order, right? So things are like there's a lot of firefighting. There are conflicting requirements. Every team is doing something different. Pressure from every direction, right? And the business is like, we have this customer, they're paying us that many millions, without them we are nothing, and you have to deliver, and they have 17 of those customers, right? And there's all kind of other craziness. And they also want innovation, right? Not that it's not fun, But it's not easy either. So essentially what happens here is that scale-ups are struggling with order.

19:17 Now, a tricky thing is that actually startups, every enterprise was a startup one day, right? By the time they get to algorithmic stage, they forgot how to do it. On the other side, the scale-ups didn't learn how to do it yet. So that's a weird situation. And by the time they get to algorithmic stage, they will forget how to innovate. Sort of cycle of life, I guess. So how it's all connected. First, it's like this kind of question, right? If it's so bad, if being slow is so bad, why all the enterprises are slow? I mean, there has to be an explanation because it's evolutionary obviously, right? So if all the enterprises came to this kind of state that is very similar and they're all printing money like crazy, it cannot be that bad. I think it's too easy to say And this is very common in our company.

20:18 Our engineers are all the time saying, like, they're stupid. They don't know what they're doing. Then why they make the money and not us, right? Why they make all the money if that's the goal? So the point is that they're slow because maturity is slow. It has to be slow because change is actually risky. So this is the reason the enterprises are slow, because they are very successful. Once you are successful, you don't want to change it. There are all kinds of cognitive biases, and one of them is don't change things that work, in different words. And there are all kinds of patterns that are coming out of this. They're sort of emerging naturally. Actually, waterfall, there's nothing wrong with that. If things are not changing too often, there's nothing wrong with waterfall. There's nothing wrong with annual budgets if the change is predictable. There's nothing wrong with incremental change and OKRs arguably are belonging to both worlds.

21:27 So the point is that being Slow is not particularly bad thing. It's actually a good thing. And the general idea is not how you are not going to be slow, but how you maintain the balance between speed and maturity. So this is the new thing that we are working on, which is finance topologies, which is think of team topologies. If you don't know, you can Google for it. But basically, there are different ways. To budget to sponsor innovation and maturity. So at the end, everything is money. Money basically decides what's going to happen. So the way you budget or fund the work basically defines how the work is going to be done. And roughly, in every company, there's these five stages of innovation versus maturity. The first stage is actual innovation, labs, right?

22:31 So crazy ideas, right? So exploring ideas. Doing quick POCs, throwing things to the bin, you know, just proper research. The goal of this first stage in WAPS is basically find future products or future initiatives to improve the business. The second stage is bootstrapping. That's the beginning of the product lifecycle. So you decided which products or which initiatives. If you want to actually deliver, then it's like building the base. Then getting to MVP and then scaling. And then actual maintenance, that's for the actual monies. And it's important to actually retire things. So I'll go one by one, basically. So the first one is... This innovation funnel. So again, the goal is research and learning. It's all about future options. It's all about being ready. The reason enterprises are not ready for Kubernetes, most of them, is because they didn't do this.

23:37 Healthy enterprises, they would consistently invest in innovation. Every time Kubernetes or Mises or whatever other swarm or whatever containers would come, they would spend a couple of months researching it. So they are never surprised. So it doesn't mean that you actually need to invest significant effort in it. It's actually essential to reduce the effort and reduce the funding in this. And we need to treat it as funding, not as budget. We cannot put ROI or... Profit and loss statement or anything like that. We cannot demand return on investment from this because it takes years. It's just options. It has to be funded in a way like seed funding. So you give people a bunch of money, you always consistently keep some sort of amount of your revenue for innovation and you consistently spread it across as many different options as possible.

24:40 And we don't measure profits because there are no profits and there won't be profits. And it would be a mistake because the moment you confuse this with the profits, then the salespeople come and they will never sell it because it's impossible to sell it. It's immature. It's not functional. There's nothing to sell. There's no even product here. You didn't even discuss it. decide what to build. So the result of this stage is basically ideas on paper. That's it. And it's important not to overinvest. That also happens. So you limit this to very, let's say, 3% or less even, 1%, depending on the size of the company. And this is, by the way, not unique. This is typical funnel from pharmaceutical industry. They start from the first cycle, they start with over 10,000 compounds. And they shrink it every stage, and it takes time.

25:42 And if you don't invest early on in all this quick research, then, you know, then... You won't find that one compound, that one medicine that will bring billions. And it's important in the first stage not to overinvest. It has to go through 10,000 compounds. It's very, very important to speed up the process of testing. So each stage has different... Objectives and different ways of working. So this way is not unique. This is standard diagram from wherever on the internet. So second stage is bootstrapping and incubation. And incubation is because actually you didn't yet proven You haven't proven that this is the right thing to sell. Let's say it's a new product. So a successful product needs to be meaningful, probably needs to bring at least 10% of the revenue. But you actually don't know.

26:43 When you start building it, you don't know if it will or not. The same as in standard startup, right? When the startup in the beginning got seed funding, and then in this stage, it's more like... Serious a B right so this is to build the processes to build the sales team to build the capabilities to actually manage and build this product so there the result is functional product and That is even before actual scale. But this is functional product, so all the basics inside. And it's funded based on milestones. So not based on revenue, because it doesn't really bring meaningful revenue yet. Very similar to startups in first three years. So they're not measured based on revenue and profits. They're measured based on number of users, traction, whatever it means. You need to have certain processes in place. You have so many customers. You need to have so many... Whatever it is, but it's never profit until much later on. The third stage is scale.

27:46 That's when you need to prove that this is actually a valid product. If it doesn't scale fast enough, if there are no users, there's no point. It's still a good idea to kill those things before it's too late. And the goal here is to actually build a product. It's still milestone-based, but it's based on revenue. So milestones based on revenue and growth of actual business. And the deliverables are stability, right? The processes, whatever is happening later on in the algorithmic stage. So that's where basically you lay the ground for being the enterprise successful product. Maturity, that's what we all know in enterprises, right? That's where the money comes from. And actually, you don't want too much craziness there, right? Stability is a healthy thing. And it's all about optimization, right? More automation. Cost saving, better quality, all kind of things like that. This is actually very well understood in enterprises.

28:54 Another thing that doesn't happen often anywhere is retirement, right? Because why would you, right? It still brings 20 euro a year, right? So why wouldn't you keep it? It's better than nothing. Of course, it costs you 5 million to maintain it, right? So, and to summarize, and this is the last model, all the models are the same, right? If you look at them, they are all the same. They have exactly the same curve, right? They have exactly the same life cycle. So this one is also quite the same, which is three horizons, which is attributed to McKinsey, but apparently they also stole it from somebody. Every company, every business should invest with the right proportion in research, innovation, and delivery. The majority should go into delivery. Significant portion should go into innovation. And a bit needs to go into research.

29:57 And of course, those are the things that... The research needs to become innovation that needs to become delivery. It is all about balance. It's not about one is better than another. It's about consistently creating new things, but then scaling them, making them mature, and retiring them. It's cycle of life. So this first part, the the funnel, the innovation funnel, that's the Horizon 3. That's the research for future. That's the thing that will bring new ideas, will bring new features, new products, new revenue. That will prevent enterprises from being surprised by innovators or by startups. It's about being prepared for whatever happens. Horizon 2, which typically is expected, the typical company in the middle of introduction of new products or in transformation, should spend something like a quarter of its revenue on innovation.

31:10 That's where you build new products or you optimize the business. So the business can be improved either by introducing new products or innovating on the business model. So cloud native is innovation on operations, which is basically you're innovating on the business instead of on the products. So it's optimizing the business delivery or the ways the business can build the value and the way they can deliver to the customers. And that will eventually save costs and allow create new products. So it's enabling technology. And the last part is Horizon 1, which typically will go 70%. So in an enterprise, unfortunately, most of the time, this will be 99%. And that's the reason enterprises struggle, is because they overinvest in current business, because the business, the salespeople, they own the future.

32:18 And they always create pressure to sell more. And it's always easier to sell mature products. It's very difficult to sell innovation. So, again, it's not, it never is about maturity versus innovation. It's about the right balance. If a company, doesn't matter the size or maturity, consistently invests in more or less this proportion, then it will be both happy with the revenue and the profits, and will come with new products and new ideas. And if you like, you can join WTF as SRE, which is a conference that happens in London in May. It will be actually in person, first time. This is the third time we are running it. Yeah, it was really good last time.

33:22 That's it. There's more answers about cloud native as in WTF is cloud native. And I guess questions now. Thank you so much to be there with us. So do we have any questions in the audience? Burning one for Pini? You can ask in French. I'm sure somebody will be happy to translate. I can actually translate with Google Translate. I can try. Nobody? En français, on peut y aller aussi. Mais mon anglais est bien meilleur, donc n'hésitez pas. I think that's it. It was very clear. And we scheduled the May 23rd, that's it? Yes. May 23rd, okay, in London? I think, yes. You Google for it, you will figure it out. Okay. So thank you so much, Pini. Thank you.

34:24 And have a nice evening in Paris. Merci beaucoup.