 All right Good morning everyone Welcome to my talk from cloud native to cloud native. My name is Max Körbecher And I'm co-founder of a company called liquid reply. We're based in Germany and actually help our customers to implement Kubernetes platforms actually everywhere So we have edge use cases running in distributed environments going all the way up to cloud providers and even scale them throughout the globe So running on multiple continents and multiple different regions and so on So am I daily work? I most of the time are more Yeah, giving some consultancy and advisory and try to answer questions from the customer What is the right way to do my Kubernetes? How I need to configure it correctly? How I bring my teams to Kubernetes and how I make them actually use of it and so on and I need to give you a little warning for today because it's like not like there's one technical problem And there's a technical solution for it or we're talking about processes But we are speaking about something which is some way meta. It's in in between There are some technical components. There are some kind of processes, but there's a lot of Yeah, this the thing which in a company glues the team together, which is the reason why for example One team is successful with migrating to your cloud and getting cloud native And while another team is maybe not that successful And this is something which we try to find out today and where I will give you our perspective of multiple projects with multiple Customers and what we have recently seen in it and what is our observations on it? And we will also find out what you can do to actually maybe not Stack somewhere but can move forward get some light speed into it and even being successful So the thing is nowadays. It's super easy to go to a cloud You just need a credit card. It doesn't matter if you're an enterprise a small company person startup The entry boundary is very low and it is also fairly easy to use you can Just click your things somehow together or if you get more techie you can build your pipelines You can use some declarative formats infrastructure as a code and so on and so forth But it's very much about you to understand or to Yeah, decide if this is more like a one-way flight ticket through the clouds and then you somewhere will get stuck Maybe or if this is the beginning of a cloud native journey something which lasts long where you have a long time Business visit which will be the foundation of a lot of your services and implementations for the future So I give you a short time to read this beautiful dear bird And then we will proceed on why is this is so true? So the point is this is something which I have at least once in a month as a discussion with a customer It's like I have this and that problem. I need to solve that and that Can we not just containerize it and bring it to Kubernetes and the world is beautiful? Well as someone who is consultant for Kubernetes I would love always to say yes, and let's start a project who will help you But the truth is it's not always that easy because the technology can solve just one half of the story Sometimes even just one-third of the story But there's way more around which you need to be aware of Before you can do anything with a cloud native and before you can become cloud native So we always see there some kind of pyramid and The foundation for this pyramid is actually the way of thinking your methodology Maybe some engineers between you will say like hey, but what is with the infrastructure and we come to that later But the foundation for a cloud native transformation for a cloud native journey Doesn't lie in the first step in the technology itself. It is all about How you are thinking about it and what do you want to achieve with it and how much you are interested in it? Because the cloud native space is moving so fast if you're not interested in it What you will learn today is outdated tomorrow And this is something where you need to stay with your mind and be ready to to keep along with And then another part is the internal developer platform This is what we often put together. It's most of the time based on Kubernetes It allows us a lot of automation But it is more about the extensions which are implemented around which helps a development team from the Software development perspective to speed up and show integrity of the system and show the Security that everything is fine all the way into the production. And then we have something Where I always have a little bit difficulties to name it on the one hand side is the business requirements And on the other hand side at the application development Not every business requirement is a reason for developing a software which is cloud native and sometimes it would be even more expensive to go this way but It's often a good option and you should be aware of evaluated and take a look for some points where you was like well Maybe we can support here will business was building something based on microservices which is fast which can be Stateless and so on and last we have the infrastructure And the infrastructure is very interesting because from a customer perspective the pyramid looks like this The infrastructure is a big enemy in the end It's something where all the complexity lays and all the costs are somehow hidden and it's maybe scales up and down and do Weird things and then you have hundreds of regions and hundreds of services and so on and so forth But that's not the biggest problem Nowadays you can define and describe everything human readable and you can automate everything of it Yes, you need to learn about it, but Well, we also learned how to walk we learned how to speak we learn how to cook So as an engineer as a technician you for sure are very fast able to catch up what's going on in club provider and what you're able to do with it Our perspective of the story consulting major enterprises is It's all about the mindset. It's all about how the teams and the people think about to implement cloud native And how really to Yeah succeed in their journey If you're not interested in modernized your application Maybe rebuild it from scratch into smaller junks Then you will not also go the way to do something cloud native because you miss already one of the foundation and The other thing is cloud native also doesn't mean that you need to go to the clouds You can use cloud native principles wherever you are as that we build micro clouds on the edge They're totally disconnected from any kind of internet Or we scale it full up But the principles behind it are still the same counting for everything on the cloud native environment so this is a very Common picture if you search for like what is actually cloud native and you will found this and that and yada yada yada The thing is this is all unimportant because it doesn't matter so much what is written on the left side or on the right side Because depending on where you are in your integration in your step of engineering It can be true also for the other side But very important is here the mindset again and you will hear this work a lot today But it's one of the key factors when we are talking about out a cloud native transformation And we were talking about getting teams into a position where they are able to build platforms Which are ready for the future which can adopt with continuously updates and changes and replacing integrations So let's talk about a few observations something where some of you maybe will find yourself Where some of you will say well, this is an obvious one and Some of you will maybe say like well, we already passed this by but it's exactly the story which I had The first thing is and we're still discussing it. We're just quite confusing after many years that Companies think you need to suggest another hypervisor So like the ember comparable or sx v-sphere this stuff But this is absolutely not true Kubernetes is a platform. It is something which helps to build your own platform Or if you want to add one another platform, you can say it's a platform to build cross-platform platforms What it means like you can build was one solution something which runs the same way on your Virtualized infrastructure on your bare metal and then the cloud provider giving your developers in the end the same experience And Kubernetes is a system to manage. It helps you to manage your workload. It helps you to manage your Resource and extensions of the resources which you can use is enriches enrich this actually And it runs your application, but do not misunderstand running here as like a hypervisor again Running just means it takes care about all the complexity around about security about networking about authorization All those heavy liftings where you normally have already a year-long project for it if you want to set it up in a classical infrastructure and What you all see? Kubernetes is often treated as a one-time implementation and this is no joke We have seriously some customers where we've re-implemented Same kind of platform in different shapes on different cloud providers But where you really should take a look on and where you should think about it if you build a cubanita's platform Then you need to continuous available team for it a product to someone who is listening to the end users development teams someone who is listening to what is needed in the future and Also who is part of the community because the cloud native community around kubernetes and all the other tools You're using is moving so fast That you need someone a whole team for it to keep track of it on the other hand side if you do it well You don't need much more than that for operate your infrastructure If you're doing it good you get also a lot of benefits out of it Even so the workload in the beginning looks tremendous and what absolutely doesn't work is if Like myself in the past I was an enterprise architect and I draw beautiful blueprints and run to the teams like look This is the the solution for everything and blueprint, you know, it's like a recipe you follow it But it's not a guarantee that the food in the end is good or tasty or that you like it Because what is often not written in some kind of blueprint is your how you spice it up the salt and pepper You which you need to add or maybe the chili if you like and the same as was blueprint it's not a solution and it will not help necessarily your teams to succeed when you move to a cloud and Especially not when you want to get cloud native So your platform team which builds a platform also needs to be trained be good in communication and help others like an internal consultancy to understand how this platform works and I know that a few people here from companies we work with and they tell me all the time the same story I'm my workload is so much not because I have to implement something But because I have to consult the people to adopt my platform But it's a very important point and then finally one of the biggest things the most applications which we are seen They absolutely not made for being microservice oriented and most of the time also not optimized for running on kubernetes When you take a look on the cloud native survey, it's quite interesting because for example in Europe. It says like Something between 17 80% of the companies a major enterprises using containers and cubanitas But the other way around when you take a look on the cloud native developer report There's only 27 of the people who are answered telling that they use actually cubanitas in their everyday life and There is a very big gap in between For sure you want to help on the one side that no one needs to understand the full ecosystem of cubanitas and not needs to understand the 500 600, I don't know how many open source projects out there. It's not yet hugged But you need to understand the foundation of cubanitas to actually build software to run on cubanitas And we will come to this in a while So how we can stay on the cloud native side if you do cloud journey if you migrate and If you want to change our mindset Well, the first big thing is you need to be more like assertion When you do a cloud native transformation, this is not about coming with a very big hammer Just slash the wall out and move everyone into the fresh air and start somewhere This will often not help Because it's overwhelming it can leads to frustration. It's like you Come to a new country and you do not speak the language. You do not understand the people You have absolutely nothing where you can rely on and then someone says like well now Let's build a successful business here within the next three months And I would like that it's adopted by millions of user till the end of the year for sure when you work hard You have a chance to succeed But it's a human nature on this point to say like well, that's a little bit too much for me at this point and This will not help you So you need to be very precise you need to find the people in your corporate Who are already interested who have this drive this motivation this interest? It's maybe the young guys and girls which are here today Which are convincing their bosses their leaders to say like I need to go to this conference I need to understand what they are doing. I need to talk with the people and These are the people you need to find within your companies bring them together and give them a new playground And yes, it's really a playground There should be no rules They should have whatever they need whatever makes them fun to develop their skill set and the capability To build a platform to build a platform for your companies and to build the foundation where you can get truly cloud native so start by zero is A very important factor and I know companies do not like to hear it But the truth is if you're an expert in chemistry The chance that you will be a digital expert in chemistry is quite unrealistic because this is not your expertise The expertise is somewhere else. It works in the past. It will work in the future What you can do with digital services is to enrich your capabilities. You can make your product better faster more transparent But it's not 100% cloud native and that's why it's also sometimes doesn't make sense to compare a major Engineering company with something like a Netflix or Spotify because they have a totally different past The one is cloud born. They started with this was digital services They know all the pain and I mean meanwhile those companies are very old. They're not startups anymore and You have exactly the same experience, but with your domain with your with your specific knowledge So to make the step from the one side to the other side You need to first I don't want to say get rid of but at least try to ignore your past and get this Playground where you can do whatever you want to do and I before had you even a line in it saying like well Ideally you get rid of your CXO whoever is taking care about this department who's taking care about your money Who's taking care about some guidance and rules and whatsoever? So that you have really something where you can build from scratch and there's no one annoying you no one telling you Oh, this doesn't work in our industry or this doesn't make sense for our industry Because this way of thinking is not the way how it helps you to build a cloud native environment So again the mindset makes a difference strategic wise customers also often choose cloud provider by money and From an economical perspective I can fully understand if I can save 30 million on the one to comparable to the other one where I'm currently running It's maybe very attractive But often it doesn't make sense for example to migrate from the one club provider to the other For which reason you want to save 30 million euro But you need five years to make rate all of your workload which you have before built up already You need to retrain all your employees who know the one club provider to use know the other club provider and Even you if you don't do this whole long story and you start by zero you maybe should start by Taking a look about the technical capabilities of the cloud provider first Because there's nothing more frustrating and more slowing down the process to adopt this kind of technologies Then when the technology doesn't work Because you cannot change it if you want to implement something in the cloud provider doesn't provide it to you you have to wait or you have to wait to build it by your own and We see this quite often as one of the reason like okay We are going there and there it seems like it's a cheap but good resource for us They can do on the paper what they all club other club providers also can do But then the project takes three months is longer and you need five more people and then comes some deadlines And you want to go to the production, but this service is actually not available somewhere else So when you do this you should think from the beginning about what you will need technology-wise so that you will not get the pain in the end and Maybe and I'm pretty sure in it You will also lose absolutely no money even so like another solution maybe costs a little bit more No panic. You don't need to read it. It's just for wrapping up for someone who wants to read the slides later So when we moving a little bit more to the perspective of developers like the people who needs to build something What we experience is that quite often? Suddenly nothing works The CICD fails the git repository is not available. We cannot push something. We cannot document something and This is because resources are often saved on the development side Nowadays if something stops this is higher automation, which we normally built It means that we even cannot fix anymore anything in the cloud provider for example or in the platforms you build somewhere so the infrastructure which we use for implementing is Getting very very critical and it needs to be treated like this. It's the same like I Do not want to say your major application which brings you all the money But it's very much comparable to it Because if all the development tools fails It's getting very difficult to fix something which is maybe running in production Another thing and I mentioned already earlier. We see projects are often Timeboxed obviously you get a team 10 people five months as you build the platform goodbye This is how most of the project are working and this is normally fine If you build something which afterwards is not going to be changed so much But this doesn't work with your internal developer platforms for example based on open source or cubanitas Because we have major releases every three months Is and if you have just a default stack on cubanitas running you actually needs to do every day For example an upgrade Sure, you can model it and do it maybe once a week or every few weeks But in the end it's a few hundred updates you have to run and this is just the maintenance side You maybe have discovered this week a lot of new technologies a lot of new projects a lot of new products Which you want to use which you want to integrate Who should do it if you just give your existing cluster to an operations team Who is busy and most of the time do not have enough people and to keep your cluster alive And then you come like look here's a cool product. This will not work Because internal developer platforms When they build right are the foundation where all of your future board projects are running on and then this is something Where you continuously have to work on where you continuously have to adopt it implement new features Extended and it's getting very critical for you. So you need to treat it like a life-long living Product it's nothing which you just build and put into the corner and give it from time to time some water it's not a Cactus or something like that which just needs a little bit water and love from time to time and Last but not least and again, please don't read all of these It's just to show you that there's a lot of patterns for example in the cloud native environment These patterns must be understood And you need to train your developers But you need to train also your platform engineering teams to know exactly when to use which pattern and this patterns are often old but gold a once got asked from from a Engineer like you come with pattern. How old are you you were enterprise architect in the past like yes I was but you know, it at least helps you to understand how the things should work Because what we also see very often is that for example a conflict pattern is used as a database Theoretically nice for development, maybe okay But this is absolutely not the way to go if you would like to really use it because what also happened and you maybe Know it when you have implement once something. It's very hard to get rid of after a while it will stuck forever there and We have seen there are a lot of dirty and shady things Sidecar patterns which communicate in the wrong directions Demon patterns for distributing application for high availability It shouldn't be there not in this way So to wrap it up from the development and product management perspective if you focus so much on the IT on your teams on developing your products projects Then you also need to give the right priority to the tools around it and to the education around it Do not appear from nothing and we're not just come out of the air. It's just don't happen but if the expectation is that it's somehow between a full week of Deployments and fixing some stuff and maybe get an error done in the production stage To find then for example time like today on a cubicon or this whole week on a cubicon It's not possible if you're not actively push it if you do not make the room available for your teams to take this time to understand and to learn and Obviously, we also need to talk about Kubernetes because that's why we at least partly here and This is very basic, but it's so often done not right Just get your security in the beginning of your projects already implemented We just a few weeks ago finished a project where we had to re-implement all the security mechanisms and it's a hell lot of a work and It's nearly impossible because the output is like well if I activate now this around 120 microservices are just going to die was in one second and it's such a amount of work to fix this but if you have already the Right processes around it for our bug and security And for network policies in the beginning of your implementations You will have in the long run never ever a problem because the people understand how it works and the fun thing is that Security with kubernetes is super easy It's not like in the past you need to start fiddling around make some profiles and Harden somewhere your server for sure platform team needs to harden the server, but from a development perspective you don't have to do this and If you mess it up then in long run you will get some pains with it before you go into production This is what we often see development phase or good Testing phase also everything fine, and then it hits production nothing works and not because it's production but because suddenly you have security and network and Role-based access control which prevents that your services execute like you have done it before and on the same layer is actually also the even more simpler things Like probes startup probes for example or readiness checks health checks We see so many services even from open source project sometimes which do not have any of these implemented The fun thing is if you have this implemented It is the only thing Which guarantees that kubernetes will fight you so hard to shut down any kind of services So it's super important if you want to build the software which is reliable and highly available and in the past You also call it self-healing But if you do not have it in place kubernetes would just raise the hand and say goodbye to your service if you have it in place kubernetes will fight like a mother cat for their children Until everything is done and ready and finally we come to the master discipline Multi-cluster single cluster one cluster for everything one cluster per application Actually does not matter so much which way you go you should not choose one of the extreme Not one cluster for everything but also not one cluster per application But everything in the middle is somewhere right you can cluster your applications based on for example departments Everything what does sales everything what is for your production line? for example or for criticality Maybe it's not the best thing to put everything what is highly critical on the same cluster So this maybe you should split but for everything else you can layer it a little bit up and As long as you have a good automation in place and you take care about that everything runs smoothly The approach is absolutely Unimportant a good Some pool for it is the less scripts you have implemented in your CICD pipelines the better it is Because every script is a single point of failure every script is basically calling That you maybe do not handle any exceptions and that your whole pipeline will break in the state Which you do not want to have stored somewhere so less sometimes way better it must be easy to use and You always should first take a look that you build something which is really useful But which is not like having 500 features where you just use one out of it Because sometimes this very complete platforms have 499 features which sometimes can cause issues for yourself And you do not want to maintain something which no one uses right? So the most important thing itself is just do not over engineer Don't do it. We have seen companies which built their whole own operators to do something while there was another operator available if you're unhappy with one of these solutions you can go and contribute for example, it is way more easier and Companies in this point are often a little bit. Yeah worry about their intellectual property The thing is we do not build any business logic into the platforms. You do not sell any very specific knowledge of your industry to it But you can solve the problem for yourself for your other teams and Maybe even for companies which you are actually very close with Companies which deliver parts to you companies which deliver components to you or where you deliver things to so Don't do it yourself If you have problems with intellectual property, maybe sort it out how you as a company can also contribute to open source So that's makes it sometimes easier to fix problems and To get the things done and write for yourself and to conclude For the cloud native journey and where you're heading to You do not need to reinvent the wheel as you have seen today There are around six seven thousand people just here and around nine to ten thousand people online Just interested in exactly the same things like you are interested and they're running around so many experts in this fields Which have solved already those problems? So why not to catch them up discuss with them bring your ideas to them? And maybe in a few weeks in a few months this feature will appear in one of the open source projects keep this thing simple as Said the over engineering is sometimes killing projects from the inside because you increase the dependencies and nothing works anymore and Everything's lost you want to bring in new people, but they need to months is to get on board it The months is to understand what you have built and then you hinder yourself to move forward and obviously Design and build for change You need to adopt Changes within the environment you need to be able to accept changes and to go with this changes And you might be sometimes even need to be able to handle that different platforms have different needs But the good thing is it's not magic nowadays, and we see a lot of solutions which can help you to do it so thank you very much and If you have some time come by into our booth and have a talk. We are happy to talk with you