Hi everyone. Welcome to my talk. I hope you will enjoy it. So let's start. What I have prepared for you today is a talk about environment as a service. And I hope I will explain it well enough to help you understand how with this practice you can unlock innovation and speed up product development. Why I'm talking about this today for you? Well, first of all, my name is Caio Medeiros. And, I have been playing as DevOps human, a huge part of my career, but also a software engineer. So I'm going to talk from my experience working with teams. and in the last, six or seven years, I, I had the chance to work with the different teams and different companies. So taking all this experience, I want to explain this practice to you. also I had the chance to start, being ambassador for DevOps Institute, platform engineering, do my, my participations in the communities. And I will be bringing the DevOps Days to Santiago first time in the history with some folks. I hope if you have the chance to join us here, and also with Open Source Santiago, we are generating some content, Time to time and we are planning also to bring the key CD if you are able to come to Santiago, drink some wine and enjoy with us. If you want to connect with me, just scan my QR code and the request to connect in LinkedIn. So let's start with the talk. And this is the structure I prepared for this talk. We're going to Check first what must see behind the continuous improvement process to unlock innovation inside companies and improve the productivity. And later we're going to talk about what I have seen and how we can go through the practice everything environment as a service to help organizations on that same path. So the first. I think I have seen there is, or what Massey is, the adoption journeys of these three main topics, the endless adoption journeys, because again. It's about the continuous improvement. So continuous improvement is not something with a clear end. So it starts and probably whenever I end or just will stop for some specific reasons. But what I have seen or people see based on my experience is Agile transformation processes to improve the customer focus and the time to market. DevOps adoption journeys to a customer. Increase the productivity of teams working throughout the software development life cycle at the same time, ensuring the reliability of these products and the platform engineering to ensure that the experience of the engineers behind the agile and DevOps adoption journey is the best one. At the same time, is standardizing the practices they will be implementing to. You know, live the principles, values of Agile and DevOps. So to, to have a better understanding, I wrote this, my vision of the software development life cycle is just, a small, or let's say macro vision of the software development life cycle now, a small value stream mapping where the customer is in the beginning, right? And all the needs or ideas of this customer will come through the. Ideation phase to later develop a requirement, verify and promote to production, an amazing product that will solve all the needs of these customers that, probably we know everybody know that, Each of these phases, they have a specific roles or sometimes specific teams assigned with the ownership of the specific phase or some of these phases, depending on the structure of the organization on how they did the transformations that we have been seeing in the last 10 or 15 years. But definitely we still have some organizations with teams that are creating this wall of confusion between them. Reducing all the possibility to improve the productivity or the reliability of their products. They are generating with the software development lifecycle. So through this three main or most popular adoption journeys, we're going to see, People or the leaders of these adoption journeys trying to bring frameworks like Scrum. The Scrum is the one that they have seen is the most popular, to some frameworks to scale, the adoption of agile inside organizations like safe, trying to reorganize in the teams in product. Multidisciplinary teams where all the different skills will be there. So the ownership of the whole product life cycle will be in inside the team, reducing all the handoffs and delays that we can have with other teams. Obviously, the, the, the, the restrictions will still exist. That's why Scrum has the Scrum Masters, and the Scrum Coach to improve the communication between other teams, and implementing the integration practice to release every, two or one week, right? that will help. Definitely. I have seen that has a good result. I don't like at all all the different specific details behind some frameworks, but definitely it's something that works for specific to improve specific phases or specific parts of the software development life cycle. Later, when we talk about DevOps adoption journeys, the most popular practices we have seen, what people see in the market is the implementation of CICD and everything around CICD, right? Continuous integration, continuous delivery, and continuous deployment. Trying to reduce the human touch with automation, right? To give the chance to engineers to work on creation. On put their minds on generate value, moving left all or shifting, shifting left all the quality and security gates that usually we have later in the software development lifecycle process and promoting practices like everything as a goal, testing automation to reduce even more than human touches. And finally. Not only related to platform engineering, but, for all the three adoption journeys, we're going to see AI everywhere, everywhere, because with AI, we have, some success. For use cases like generating, auto generating the testing code to do unit testing to your, regression test or load test, helping developers to code or engineers in general to code, to create the infrastructure as a code as well, if we need to talk about the infrastructure or, operation side, reducing the time to solve issues because sometimes, People rotate to a lot in IT world, so sometimes it's not the same person, not the same engineer who needs to fix an issue or who wrote the code. So using AI we have seen that this can be improved the time to solve issues, to generate documentations and some other use cases. So even without this Different adoption journeys focus on this most popular practices or movements. If we want to say that, we're gonna see that not all metrics will be showing as good as we want to, right? In case of agile, some of the ones, the metrics I have seen is spring burnout, customer satisfaction, cycle time, lead time. And focusing on specifically in the metrics that are measuring. Time here when we talk about lead time or cycle time, it depends really depends on where you start to measure to really know if the whole cycle is improving or just part of the cycle, which is okay, right? We can improve the whole cycle, just improving some part, but we're going to reach the end. Some levels, we're going to reach some level of improvement and from there it will be hard to keep growing, right, to keep improving. And we're going to see this in some, in an idea I have so in the other section of this talk. Later with DevOps metrics, we have the Dora metrics, the most popular metrics in the market, right? Due to the Dora reports, the state of DevOps reports, right? there we have delivery time, the volume and frequency, time to restart, change failure rate, and, the idea I want to broke with the environment as a service, will not be visible in some of these metrics. And that's why I'm putting them here, because, as well as, some agile metrics and platform engineering metrics. The in a pass on boarding time mean time to unlock on resource allegation. Sometimes they are just focusing on show what is the current state or where we are in with some specific part of the flow, right? So I want to invite you to see what I saw there, right? Because, A lot of organizations using this matrix going through these three adoption journeys and trying to implement those practices we already talked, discussed, they seem like, they see that like they are, they are having success. They are improving. Everything is going good, but they have so that developers are burning out. Do some other reasons, some other holes we can find in the software development cycle because maybe I'm automating everything after my commit push, my commit and push to the core repository. But what happens before if I need to start a migration to cloud and, the, the unique, support they have inside organization is provisioning the resources, but they need to go ahead I need to go to other side to request network configurations and I need to go to other side to request certificates. So everything it's in different teams or even in small companies, the is the same thing who wants to who must own everything and manage everything. So all these different holes will generate problems in the flow that cannot be solved with the traditional We are at least the common practices. We, I, I, I mentioned it before. So what I, I, so, as main problems, or if I need to put an example of Some of these holes. The first thing is lack of knowledge. And, you're gonna say probably. Yeah, it happens. It's normal. Lack of knowledge is something that we can we will live with lack of knowledge. It's a problem that we're gonna have all time. If we don't have the expertise inside the organizations and thinking on in all 80. It's a common problem even more and more. But there I also have seen lack of capacity, lack of budget. That again, you may say it's, they are common problems. so to, to reinforce this problem that probably you see, yeah, it's a problem at the fact that I have seen, in with some of the teams I have worked is, They took from 3 to 24 months to adapt, to really adapt new technologies. So it's a, it's too much time, right? If we want to innovate and be better than competitors and win in the marketplace. Same thing happens with the tractors. People that is saying, if it works, don't touch it. Let's leave it there with the speech, like, we are using, this process or this standard because we are used to do like that. Or someone else told me I need to do that and I don't know who decided this. And the standard says that, have you ever read the standards? and also sometimes the standards are, based on interpretation and it can generate a lot of biases. And the fact gives a story again, because 70 to 80 percent of the teams I have worked, they had the tractors, they had the skills to, start, in, improvement path. And later, we have the bureaucracy that, is one of the holes I want to reinforce with the, Environment as a service practice because the bureaucracy generates a lot of burnout on teams. the probably most of the organizations are trying to solve this with platform engineering and the agile and DevOps. but, in the organizations they have worked, mainly in the bigger ones, even having years working in the adoption journeys. They still have some problems with bureaucracy and the fact they cannot look at the software development life cycle as a whole process. They just focus in specific phases of the flow. And the fact kills the stories again. Some teams they have worked, they waited during three to six months to for their environments to just start deploying some small POCs. It's crazy. It's crazy. That definitely will block any kind of competence the organization can have. So where to start with the environments as a service and how to approach this to, face the challenges and try to, solve or remove the holes I mentioned that before. The first thing is a start by name, there is no way to improve if you don't know where you are, that's part of my, my, my, my pillars, my mindset, and they want to share this with you before to even talk about the practice because DevOps, Agile and platform engineering practices have been shared in the last years as something that can be reused and definitely it can be done, but, it depends a lot on the reality of each customer company, right? Sometimes, there are some practices that will really help the organization. Sometimes, they gonna do that just because they want to have. C I C D as an example, right? So Gator data from the value stream is important to understand if the efforts you can put to implement some practices will really generate the value expected Gator the data, do some Gemba walks, walk with teams, understand what they are doing and understand these holes they can have in the in the process and be as much as possible open with your mind to go fewer, even more to the left, right? Or even more to the right, because maybe there is the holes that is really generating delays in your software development life cycle. So there, having that in mind, let me introduce my understanding of environment as a service. Definitely, it takes some ideas and principles from these three different adoption journeys, the endless adoption journeys I introduced later. Before, sorry, which is Agile DevOps and Platform Engineering, mainly DevOps and Platform Engineering because the teams to go and implement the practices. And the mindset of DevOps, they're going to need technology, they're going to need, the environments where they will be able to automate the deployments, where they're going to be able to automate the monitoring, and improve the practice of DevOps and all the different roles in between them, or even Before after them. So if we take the idea of platform engineering on generating platforms as a product inside organizations based on the needs and exposing them as a service through API's, we're going to have an example on how to implement environments as a service because, What I have seen here in the market working with teams is usually they request for environments, and the idea of environments is just the resources, but it's not just that. And when they reach production, they discover that they are a lot, they are, they have a huge gap on non functional requirements and, specific security conditions to reach production, generating a lot of delays. So I'm not talking about Infra provisioning or configuration provisioning, right? This is just a small part of it, right? it's not a matter of, putting as a service the generation of a virtual machine or to request a namespace environment. I'm talking about, To something greater than that. Also, it's not just reusable assets, right? This is a common service that the organizations are trying to implement generating in their source communities inside the organization to share, Small pieces of technology that can be reusable to to improve the activity of teams and also very used by platform teams. I have seen that the platform teams are generating a lot of community inside organizations to avoid teams to reinvent the wheel. But also, I'm not talking even. of user management. It's these three things are parts of the idea of environment, right? An environment. It's a concept for me is everything you need to put your software and make it run. So that's the definition of environment. I want to generate the shared understanding between us right there. It's everything that need a team needs to start working. On their, release of the software they are developing of the product they are delivering. So it's a box with a lot of things inside. Resources. I'm talking about infrastructure and configuration things. Secrets. Credentials to connect with the third parties, services, databases, messaging brokers, processes to understand how I can promote my software to that environment. What is the standards I need to follow? What kind of authentication, authorization, non functional configurations I must ensure to promote something to production inside my organization. The rights, the permissions to my internal team, right, and also other support teams to ensure that this environment will be useful. Assets to reduce the reinvention of the wheel. Ensuring that the teams are using the right. Tools, the right files, the right configurations, and finally documentation, which is, something, I have seen, it's, one of the worst things that, platform teams I had the chance to, to work with, they, they must take more care of documentation is, is the way to solve the gap of knowledge, adopting new platforms and environments. It's something similar, right? when we talk about the commendation, it's, Achilles, fit, for every product team, Because, since they are focusing too much on generate the product, sometimes they delay or they forget to create documentation. So environments will be everything a team needs. So, and also in specific organizations, well, in each organization, the needs of an environment will be sometimes different, right? So that's why I think the generation of this environment should be a product. An internal product and as fast as you can provide these environments will have the teams to not only generate value throughout the software development life cycle, but also will help them to modernize their applications in the future, right? Some of the experience I had was, some teams trying to move from, virtual machine based environments to go to containerized environments, and they Waste a lot of time, like around three to six months just waiting for the first environment to do the first POC of that migration. That's crazy. Not, competitive at all. Some, some other takeaways I want to share. For you today, in order to really be successful, if you want to go and try to implement the environmental service with this, this, conception of environments in your organization. One of the things you must take care is this is the costs. So something we discussed a lot with my my friend Francisco Meneses in the last Q comes out Lake City. Which is, if you want to give environments to, to the teams, you, you need to understand the money is, limited, right? It's not a, endless resource. So, here it's important to make it visible. If the information is there, if you are monitoring the costs of generating an environment, it's enough to generate the shared responsibility. And say you have your budget. This is the costs you're going to have if you request this environment and give also the chance to have a trial plans, right? Maybe I can request an environment during one or two days to do a PLC and I can have that environment in a matter of minutes or one hour, maybe, and remove all the burnout or all the stress of waiting for an whole environment just to be able to try. That environment to try that technology. Another thing which is super important. I have seen makes the difference between the success or not are the failure is generating training. Training, and observability enough to, again, generate this shared responsibility because we're going to have different teams here. It's not the same team which will use the environment, who will be providing this environment as a service. Which can be even a platform team who will be providing this environment as a service. So the different teams using the solution of environment as a service, they will need some training, some preparation to use the platform. And also they will be able, they must need to see what is happening there, to understand what is happening there. So the team, That will be in charge of generating the environment as a service. They must ensure that the solution is understandable with the logs. It's generating the messages, right? And also have a huge amount of knowledge base to train the team. Sometimes I will Try to correct what I said on huge training knowledge base, I will say, as better as possible to guide the teams as fast as possible to start using the platform and later, last but not least, I think it's super important to have a clear service level of agreement. With the support team providing some connection with the users of this platform and the engineering team working on continues improve this solution of environment as a service and the delivery time is a is a corner. Stone that you must take into account, right? As I mentioned that before, the experience I had with some teams waiting for months to have the first environment, the delivery lead time of releasing from when I requested the environment to when I have the environments in my hands can make the difference between a company that will win And release a new feature to a company that will be the last one releasing that feature in the marketplace. So the last part of this talk is, helping you to understand what kind of tools you can use or what tools I have investigated and tried to implement environment as a service. The first one is crossplane. I had the chance to. Talk with, Victor Fabric and the last KubeCon Satellite CD to discuss a bit about the environments, ephemeral environments. Well, cross plane is, control plane to connect, to manage, providers of infrastructure providers of configuration. It's super useful because you can define your. On APIs, and it's highly extensible, so you can manage the back end and configure some controllers to manage this environment, ephemeral environments that I mentioned that before, or even generate connections with some kind of providers that are not Available by default in the tool, definitely it will help you to generate everything you need for an environment as a definition and orchestrate everything for you thinking on those environments that are that are related on where you're going to offer a service later, deploy an application, release a service, to, network service, The other thing you have is, that I think it's important is the technology agnostic that some to some platforms provides like a test cube test cube. It's a platform that enable you to orchestrate testing throughout the software development life cycle. And for testing, you also need environment. Right? Environments as a service and test cube can help you to generate these environments as a service to do testing to ensure that you can move this feedback of, if your unit, functions are working as expected, if your user flow is, working as expected, if the load is the expected for your application. So with test cube platform, you will be able to, radiate information. Generating environments to on demand to test your applications, your solutions, your it products with the execution on demand. As I said, with reusable assets, some of the things we already discussed before, right? As part of the environments, everything I need to make my application work and fully integrated with the whole software development cycle life cycle, something that the people is just, putting too much focus like CICD, but also something that people maybe is not doing too much, which is continuous testing. After deploying the production, I can keep testing my application. And with TestCube and the technology agnostic that this platform offers, I can cover most of the technologies or almost technologies I have inside our organization to implement continuous testing. And finally, the open cost, because it's something I reinforce with the takeaways, which is the FinOps visibility of the costs to generate the shared responsibility over the dispensers I have when I are working with when I'm working with the environment and be able to have this, this option to work with any vendor and see the costs in real time. Right. So joining all these three platforms, I thought it's a good way to start implementing every environment as a service. But if definitely if you need some other solutions to complement this, it depends on, on what technologies you already have, but if you don't have, One technology for one specific requirement. You can find a lot of these options in the cloud native computer foundation landscape from where I took this three important and amazing products, or platforms, projects as you want to call. So at the end, we're going to have something like this. It's my proposal, right? Have a platform team with a product called environment as a service platform. Where are they going to provide different, APIs where the teams will be able to use to request their environment using platforms like crossplane, testcube, open cost to cover all the different aspects I mentioned it right to generate an environment, not only releasing resources, not only generating a virtual machine for a team, but also Put in there, the certificates, the network configurations and everything that is needed. Same thing for a Kubernetes namespace. so all these artifacts will be part and will be needed to generate this environment as a service solution and, using automation, using platforms like cross plane test cube and open cost, the delivery time will be reduced, but definitely you need to tell. Think in the in the whole architecture of your product, considering this aspect, because I have seen teams that are providing Kubernetes namespaces as a service, and they are delaying a lot on generate the environments due to the resource management. This is another thing that must be considered. finally, to Take to have success. My let's share my, my success keys for platform teams. The first thing is focus on customer. That's why I have this sign. The first sign here, this is coming from another talk. If you want to, go deeper on this, you can see. Find that talking in YouTube. the three practices I recommend to have success with platform engineering. The first one is focused on customers. So the platform team must understand who is their customer and how to generate environments for them. Because I mentioned it before, the environment for one team maybe will be different Of, environments to other team in another company, right? Because each company has different standards, different, providers. So that's important to understand and identify your customer, identify their needs and generate a platform of environment as a service based on that. The second thing is measure and try to implement the practices you are releasing as a service. So if you use a tool, you will be a customer as well and will be better for you to get your feedback if you are using the platform and you have the same pains that other teams. And finally, form a team. Champions inside the platform team where you have different platforms totally integrated with each other with artifacts specifically created for your own company or your specific customer. You're gonna need expertise inside and one person cannot be expert in everything. So form experts inside your team to support each other with a T shaped format. and, have a platform team that can grow together. So my closing comment is do not just replicate what others did think out of the box and discover the continuous improvement never that continuous improvement never ends. Right? And why I'm saying this because a lot of people is just focused on On the implementing the DevOps adoption journey with CICD agile adoption journey with scam or scaling with safe platform engineering, generating the DevOps platform engine, a DevOps platform with a lot of tools, everything connected, but they forget. about these other aspects that can heavily impact on the time to market, right? Just imagine, reduce the whole team stress to go from idea to first touch in a matter of minutes, in a matter of hours, right? So let's say a team was requested to generate a new product. Amazing product. And they want to test deploying the first feature, and they just remember that they require an environment. So they go through this platform and request the trial, right? And they deploy some pieces of software there and they can start receiving feedback, celebrate. That will be amazing. I have seen a lot of stress on teams do they don't have access to their environments in the time they are expecting. So thanks for joining. I hope you will keep enjoying this com, 42 20 25. I love to have this space to share this idea with you. And if you wanna want to go deeper on this, you wanna talk about this with me or some other people, feel free to reach me out, in linking and or in the chat of the event. and see you soon for a next another talk.