 Hello and welcome to this presentation about modern application development. My name is Michael Schmid. I'm the CTO of AMAZIO, a recently acquired company by Mirantes and I'm going to tell you today how we think modern application development should work. Now all of us agree it is hard to develop applications today and we believe specifically that's because today somehow we expect application developers to be system admins. But application developers actually have specialized skillsets. Imagine you're building an website and you need to support all kinds of applications and browsers and screen sizes out there or if you build an Android app that needs to support all kinds of different versions that needs to be run fast and needs to use the least amount of energy and things like that. So application developers should not be cis admins. They should really have the possibility to focus on their skillsets that they are really good at, which is developing the applications. And then one other problem is that a lot of times local and deaf environments are different to production, which makes it really hard to develop applications that really work well in production if you never can test them unless you go to production. On the other side though infrastructure teams struggle as well because infrastructure teams need to deliver really reliable infrastructure that runs 24 seven has really high up times, good SLAs and things like that, but they also need to have very flexible environments that needs the developers needs. And developers, they need to be able to start and stop new environments very fast in a world of social media and really fast news. It's important to be able to update applications to whatever is needed and that sometimes needs deployments. And so this is really creates a lot of conflicting goals where the infrastructure team wants to create reliable, not changing infrastructure while the application developers want to change basically almost every day or sometimes every minute they want to change something. So that creates a lot of conflicts in with two teams that really rely on each other. And so the question is, how can we make this simpler? Well, first of all, we would love to let the devs be devs, meaning that they should really only focus on the application and we should abstract the complexity of this infrastructure away. And it would be cool if we can deploy and consume like infrastructure as a service almost. And it would of course be really good if we actually have specific tooling for developers. So user space-centric tooling. Now we look, if we look into the past of how in the past that things have been developed, we see here we have a development environment on the left and we have a production environment. Now developers, they are responsible for the application. And they usually develop this application on some kind of development environment. And then after they're done, after the developers have been developed or the application has been developed by the developers, usually they throw it over the fence to the production. And that's where the operation team sits. So the operation teams, they have their production environment. That's their responsibility. And the application and infrastructure is really close together. Sometimes they actually use the same tools to use for the application and for the infrastructure to deploy. For example, Linux packages. It has been done many, many times over the over the last few years that you just create, like you install, let's say a Linux kernel the same way you also use the same tools also for application deployment. So that creates a massive gap between the developers that develop the application and then throw it over to the operations team. That usually means that now the operations team needs to actually deploy applications into production. And that's not something that they develop. So this makes the ops unhappy because they now need to work with code that they didn't develop, but they're responsible to deploy, things like that. And the other problem is that the operations team now also needs to run some kind of development environment, but they don't really care about that because they really care about the production. And so there isn't deploy development infrastructure that the developers use to build the application, but it's not really on the forefront of the importance for that operations team. And so this actually makes the developers very unhappy because they need to work in development environments that didn't work. So this is what I call the legacy responsibility matrix. That's how we have done things over many, many years, how we develop applications. Then came DevOps. DevOps promised to change all of this and solve it. And it definitely changed a lot of things. I don't think it solved a lot of problems. It did some of them. And it works in a way that you basically put the developers and operations team in one team. Everybody has access to everything. The application infrastructure comes together for development and the application infrastructure comes together for production. And so if a developer can also be an operations person and vice versa, that should solve all the problems, right? And it definitely did because now, because you have one team, it means you have less knowledge loss. The people that built the application also run it. And it also means shorter development cycles because now you have the same possibilities on development and production. And because it's the same infrastructure managed by the same team, you have less problems on different environments and things like that. The problem is, though, that now we expect developers to know about the infrastructure and operations people to know about the applications. And that usually overwhelms the developers because they really want to focus on the application. They don't want to worry about storage and IP addresses and all these things that infrastructure people all day long do. And infrastructure or operations people, they don't want to worry about browser sizes and screen sizes and all these things. So overall, we overwhelm the developers and we make the ops unhappy. And I think that's one of the problems that we see today is that we expect a lot from these people that build applications that they also manage it and also operate infrastructure under it. And we see operations people being unhappy because that's not the job that they signed up for. So we think at Mirantes and Amizio, we think there should be a new model which we call zero ops or is also called the platform model. And this is how it works. First of all, we're going to rename the ops team to the platform team. And they build a platform. The platform, in our case, is based on Kubernetes and it's the same for development and production. It can actually be the same Kubernetes cluster if you want or you can separate them. It doesn't really matter, but it's possible to have them in one. And then on top of that, we have developers. And these developers deploy with applications. They deploy their applications into containers. And they do this locally. They do these development environments and in production environments. And then these containers can move between these different platforms that all speak the Kubernetes language. And these have massive, massive opportunities or better things compared to the DevOps approach that we saw before. First of all, these containers allow a clear separation of their responsibilities. Everything that runs the containers, the platform is responsible by the platform team. And everything that runs inside the container is the responsibility of the developers. With that, you have a clear separation. There's very few times the question of like, who's problem is it now? If it's something that happens inside the container, it's the developers. If it's something outside the container, it's the platform team. This also means that now developers can start to consume services by the platform team. The platform is not only a Kubernetes. It can be local answers. It can be databases. It can be caching solutions. Things like that. And they can be consumed by the developers through APIs. For example, through the Kubernetes API. So a developer can go to the Kubernetes API and say, I need a database. And then there's an automated system that provisions a new database that is running in the platform team that is in run, managed by the platform team. But again, there's a clear separation of who provisions, what, and the developers can use the APIs to see what is actually there. Another huge good thing is that the development of the productions are exactly the same. Because these containers, they don't have to change. I can just move the containers between these different platforms. And I know that the versions of the running inside the containers, so like let's say a specific version of Java is the same no matter less in which platform is running. This really, really allows the developers to focus on the application. They can focus on what their job is really about, is to build the application, to make the application super performant, super fast. And it allows the platform team to focus on what they really want to do, which is running these platforms. Now you might say, well, but I don't have a platform team. And that's where Mirantis comes in. Mirantis can be your platform team. We can do all of that at the bottom here. We can do all of that for you. We run the infrastructure. We manage all the different servers. We set up Kubernetes. We manage Kubernetes. All of that is done. And Mirantis can be your platform team. And this allows the devs to not worry about operations at all anymore, hence zero ops. Now you might say, okay, this is all good. But how do these developers actually deploy these containers? Because we still have to deploy on top of Kubernetes. And that's true. And that's where we set user-specific tooling. So we need a way to allow developers to deploy these containers that they build. And we need they need to be able to build them against Kubernetes clusters. And we do this through a tool called Lagoon. Lagoon is an application delivery system that is built by developers for developers. That means there are developers in the Lagoon team that used to deploy in these either legacy or DevOps way that have really felt the pain and the struggle through all of this. And these developers came together and said, let's build a tool that thinks like a developer and is helping developers. So it's not a tool that is built by operations people. It's a tool built by developers that really helps developers. And this is how it works. First of all, it's all built on top of Git. Git is already used by application developers every single day to write code, share code, analyze, test it, all of it. So Lagoon hooks into your existing Git workflow. It works like that that a developer pushes their code into any kind of Git server. It can be GitHub, GitLab, Bitbucket, the public versions, the enterprise, self-hosted on-premise. It doesn't matter. You can use any servers out there. After such a push, let's say there's a new branch or a new pull request has been created. This Git server informs the Lagoon core. The Lagoon core is the central place where all the different webhooks and Git repositories send their information about a new commit. And Lagoon then knows which Kubernetes clusters that this code should be deployed to. So in every Kubernetes cluster, so each of these are Kubernetes clusters, inside is running a tiny agent called Lagoon remote. This Lagoon remote can talk with this Lagoon core. And so the Lagoon core looks at which webhook has been received. It knows in which Kubernetes cluster this should be deployed into. And then it tells this remote in that Kubernetes cluster to please deploy the code that just has been pushed. This remote will then start and inside the Kubernetes cluster, it will create a new namespace. It will check out the Git code. It will analyze the Git code. It will see which services are needed. And it will automatically, without any interaction of the developer, create the required Kubernetes objects. So for example, it requests storage, it requests databases, local answers, ingress, services, secrets, all the specific things about Kubernetes is all handled fully automatically by this Lagoon remote. It builds the application. It builds the containers. It sends them to a registry. It scans them. It does everything that is needed to deploy an application on top of Kubernetes. And after all of that is done, after the deployment is done, in Kubernetes world, this means like all the pods have been scheduled, the lifeness and the readiness checks are passing, traffic is flowing in and all that stuff that is necessary. After that, the Lagoon remote will inform Lagoon Core again to tell it, hey, I deployed the application. It's done. And then Lagoon Core will inform again the developer back via, let's say a webhook or a chat system or via the API or there's also UI that the developers can see. Then they can see what Lagoon remote did, if the application has been successfully deployed or if there was a problem or things like that. So that's how we can deploy into Kubernetes clusters without that developer here ever needing to access Kubernetes, manage Kubernetes or even know Kubernetes. Because all the Kubernetes stuff happens in Lagoon remote down here, managed by them. And all the developer needs to do is to push the code and deployments happen fully automatically. And that's what we call about user-specific tooling. This is a tool that is used by developers to deploy into these Kubernetes clusters that are part of the platform that are managed by the platform teams. And with that, again, we have a clear separation. They build these containers that run on top of their platforms and the application developers can really focus on what they are really good at. So in recap, we believe zero ops is the next iteration after DevOps. Zero ops for an input point of view means that we have a clear separation of responsibilities. We have no overwhelmed developers that now suddenly need to learn all these new things that they don't really want to learn about. And zero ops for developers means that they, A, you have the same environment everywhere. They literally have the same container locally in development and in production. And it allows them to really, really focus on building good, fast business requirements into these applications because that's what they're hired for and that's what they should really be to. And that's it. Thanks a lot to listening to that. Like we said, we can help you to build all of this. We can be your platform team. We can help you build your own platform team. We can teach your application developers how to use Lagoon and how to deploy with Lagoon. We're happy to help. Go to dub, dub, dub, mirand.com or dub, dub, dub, amazing.io to learn more and to reach out and we're happy to help and bring your application into the next development ways how we think modern applications should be developed and built. Thank you.