 Hello, everyone. Welcome to GitOps.com Europe. I hope you are all right, and I hope you are ready to go on a journey with me. But before that, a little bit about myself. My name is Jamsu. I'm a senior architect at Redhead, and I help our customers to form high-performing teams and help them to build and adopt good practices like automation, everything as code, GitOps, obviously. Please feel free to drop your comments and questions to the chat channel. But if anything comes to your mind later on, please do reach out. Okay. What are we going to talk about this next 20-ish minutes? Well, I'd like to open up it with a platform engineering concept, and not just because it's super-high, but mainly I want to talk about why it is super-high these days. And then I would like to talk about some discovery practices to understand our organization's current practices, sorry, current processes and challenges, ambitions when it comes to this platform space, like what our users, developer needs, where are they in terms of practicing GitOps or other good practices. And of course, I would like to talk about these based on some examples from the field, based on the work that we've done in diverse customers. And then I want to talk about what we're going to do with all these informations that we discovered, and how can we use these informations to improve the adoption of good practices across the organization. Does that sounds good? Okay, let's start. So, I saw this picture on Twitter, I think it's like one and a half years ago or so, I love using it. Just to show that platform engineering is super-high, and also already started to get it wrong, just like it happened to DevOps. I'd like to sit down and talk, discuss this state one day with you, but we are short on time in here, so I'm just going to share my take. DevOps is a mindset, right? So, it is a still very valid mindset. And I see that platform engineering like a natural next step to DevOps, like a next evolution of DevOps. And why is that, and why we started to talk about platforms all of a sudden is, is a really simple answer to that, because technology is getting complex and complex each day, and the responsibilities of developers are getting increased and increased, which leads to an ever-increasing cognitive load for them. They have now more areas that they need to go deep and have expertise in. They have more responsibilities, not just on the building and testing and deploying their applications, but now observing those applications and operating the applications in a multi-cluster, multi-cloud environment. So, we start to see this increasing cognitive load on the dev layer, and that's where the platform engineering and platform as a product concept started to get attraction. So, we know that we need to address this load, and it is only feasible if engineers have access to a rich platform with on-demand services like taking away this cognitive load from them, like taking away the repetitive actions of creating and testing environment just to test some small features or setting up some tools just to do some experiments, et cetera. So, this is why platform engineers actually needs to go beyond just provisioning and configuring a highly-available Kubernetes clusters, but we need platforms to provide good set of services in a self-service manner to make developer life easier. So, with that being said, also we see platforms to enable of good practices like GitOps. So, from a platform engineering point of view, we know that we are going to do GitOps for all the good reasons that you are here and in this conference. And we also want our developers to add up this GitOps, this way of working as well. So, instead of just throwing them this new shiny GitOps engine tool, we need to build our platform services in such a way that their entry point is very easy to this new world, to this new ways of deploying applications. So, for that, it's better to understand, it's better to start by understanding where are we today with our current developer services? How are the developers are using our platform? What are their ambitions? What are their current challenges? How they would like to practice GitOps? What they would like to understand the details of GitOps. I want to introduce this navigator before we start to talk about this. We use this in our engagement. So, it is called Mobius Loop, and it helps us to create this continuous flow from discovery to delivery. So, we need to start at the discovery space to answer these questions on the top and then take the answers and the results of these and deliver something that works for our developers. So, we are on the discovery space and now there's this, there are, I want to share some good practices, good discovery practices that we use in the field to answer these questions. So, first one is called Metric-Based Process Mapping, which is my favorite. This is where we usually select a scenario like from idea to production, getting an idea into the hands of our end users, mapping out this process by identifying who are the people, who are the teams and actors involved into this process, which represent by each swim lane and what are the actions that are being taken by these people in a timeline sequence, in a timeline manner. The actions that needs to be taken in order to deploy production. So, as you can see that there are handoffs between teams and you can identify, like you can easily see how we can make this process even more efficient, what kind of automation that we can introduce. This can give you the view of how you are doing the deployment production today, how you promote your applications from one environment to the other, who are involved in this decision, what kind of approvals needs to get or how can I automate that and so on. And from GitOps perfect perspective, for example, this could help you to shape your GitOps config repository structure because you want to drive the deployments from GitOps, right? So maybe instead of doing some sort of a manual actions in here, raising a pull request to a GitOps repository and adding these related actors into the pull request for their approvals could just be a really easy gain and easy efficient improvement in our processes. So that's why it is important to have shared understanding between developers platform security and understand this process in a big picture manner so that we can start seeing improved points and we can use the technology and the good practices to fit our needs. Second one, empathy maps, it is coming from UX world. It is where we do user interviews or observe our users. In our case, our users of platforms are developers. So basically like this would give us an insight about how they work, what they need in order to do their work better, how do they interact with the platform, what is their expectations from platform. And so, for example, if you are already practicing GitOps, this could be a good opportunity for you to understand how your users are, if your users are happy with the current implementation, do they find it flexible or easy to get on board? Or if you are not using, not practicing GitOps yet, this can be important to discover their expectations around the deployment phase, that what can be the good improvement points when you are introducing GitOps, for example. And another one, so we talked about platform engineering. Let's bring the topic back to there again. We said that platforms should lower the cognitive load of developers. It should address the challenges that we hear during the developer interviews. It should help us to streamline the onboarding process that we laid out during metric-based process mapping. And it should do all those while enabling developers to do good practices like GitOps. So however, one might ask, should platform really cover all edge cases, every single scenarios in our organization? Or should it provide, when it comes to GitOps, should platform only practice the GitOps capability but not like configuring the GitOps engine for developers and give that power, give that responsibility to developers or should it provide a fully configured secure GitOps engine instances and so on? So it is really important to align around what we mean when we say platform across the organization and what are expectations from the platform. So for that, there is this quite simple, yet very powerful exercise coming from Team Topology's authors. So basically bringing diverse background people like developers, security people, ops, et cetera, who will interact, consume, shape the platform, bringing them into one room and it's done this simple foreclosure and it's like what the platform is, what it is not, what it should do, what it should not do. So uncovering the expectations here and aligning on the language will have huge impact on the services that platform will bring to the table. And GitOps is one of them, right? So we have some examples here. These are from our platform as a product workshop, which we use with our customers to help them to understand these concepts, which you can learn more by scanning this little QR code. So there are some good comments in here like platform is not just Kubernetes, it enables the organization by providing some services. And things like that open up for good conversations like what kind of services, like what to mean by it's not just Kubernetes and uncovering these kind of services together and aligning on them, it's really, really powerful. So there are lots of lots of good discovery practices and you can see more about them in openpracticelibrary.com. I just picked my favorites to share. So all those discovery practices would give you a lot of work to be done to like areas to dig deep more. So before you go and start actually, start implementing some stuff, you need to do a look to a prioritization based on those works that you just discovered. And there are really good prioritization practices in openpracticelibrary.com as well. So please feel free to check them as well. So after you prioritize, you start basically, you are now on the delivery phase. So what you do is you start building your platform services. So at this stage, maybe you don't know exactly how to set up your GitOps engine maybe, or maybe even don't know which GitOps engine you would like to choose. But you start bringing some good technologies, good tools together to deliver something. And I will go through the examples with Argo CD because as Red Hat, this is our preferred GitOps engine, but also, and also that's the only one that I have experienced with extensively. So it's just gonna make things easier for me to share. So up until now, we shared good practice, good relationship. We started good relationship with developers. We have an idea of what kind of things would make their life easier. What are their current challenges, et cetera. And based on my experience, I usually see the onboarding applications to a container platform is a very high on the list as a challenge to address. So with that in mind, that brings technology, Argo CD to the table again. So we know that we want to practice GitOps for all the good reasons that you guys hear in the conference. We want the whole organizations to follow. However, it's a new tool. It's an amazing, it's a shiny tool, but it's a new tool to learn for developers. And we already discussed that there is an increasing load. So maybe you want to keep things simpler. So what you can do maybe is like a quick experiment to see that how we can bring GitOps to the mix in your pipelines, in your deployment phase. Maybe you could just have one Argo CD to start that looks after all the deployments and instead of like a build in a shiny dashboard on top of Argo CD, on top of Kubernetes cluster, maybe you can have this just one YAML file that developers come and raise the pull request to add their name or maybe the service name. And when it's committed, Argo CD will do its magic and do the deployment. And maybe you'll just, there's some golden ham charts in the back to help make things easier. And this would just work to start, to verify things, to experiment things. So what does this mean on the Argo CD lands? You'll have bunch of different Argo CD projects maybe per team with some good Arbecker guardrails in place. And it's a simple implementation from Dev's point and Devs are not aware of things. Many things are provided and they just work out of the box. Until maybe there's some different requests coming in or maybe it comes to update something and you realize that this can be hard to maintain. Maybe you become the blocker by holding the keys to the kingdom, so to say. And what I found is that, this is a good approach to start as long as you are keeping things transparent and start holding some sort of enablements for teams that are actually using Argo CD under the hood. So they are aware of what's going on and that they are getting ready to handle their own HK cases when necessary. So maybe you need to go back to the discovery phase if you feel like this is getting challenging, understand more what kind of challenges that you are having and understand what kind of challenges developer are having and the onboarding phase. And maybe you want to experiment with different approaches. And there's another common practice to get the benefit of Argo CD's multi-tenancy. So why not give them their own Argo CD instance with the right guardrails in place and of course let them do their own thing. But, excuse me, we just said that we don't want to increase their cognitive load by giving them yet another tool. But also we don't want to become blocker by not letting them to play around with Argo CD to maybe test this new plugin that they think that it's going to be useful for them. So that's the right approach. So we said platform engineering should provide some set of services that just works out of the box. So maybe what you can do is that you can just create a little bit of an automation around onboarding that creates these environments for developers, like giving them an Argo CD, has all the basic configurations in place and also providing some sort of a GitOps repository out of the box that things would just work. But since also they have access to the Argo CD, they can configure stuff based on these pre-configured GitOps repositories, pre-configured initial application of applications things. So this screenshot shows that when there's a new team has gained an access to Kubernetes cluster based on their LDAP group, maybe you can trigger a pipeline to give them what they need. It is more of a mix of hand templates plus pipelines, but in the end, it's just a simple automation for you to validate ideas before you go and learn the implementation of full-blown IDPs. So we were working with this customer that they were new to the container ecosystem and GitOps, we discovered their needs with going through the discovery practices and how can we make their life easier by providing like what we need to provide to make this their life easier basically. And we've discovered that if you provide some golden templates, if you provide a golden pet pipeline, some ready to GitLab repositories, et cetera, things will get easier for them to provide and things that just work will help them to hit the ground on Kubernetes on the first day. And since we are holding these like enabling on the side with them and some sort of hand holding until they feel comfortable, they get to own the tools and they feel comfortable each day. So this is just to think that maybe you can also think about that. So it doesn't have to be my Argos CD to rule them all, but maybe there are multiple Argos CDs for the teams. So in the end, let's say we had a platform Argos CD that is responsible for platform related things like, I don't know, OAuth configurations and logging, image registry, et cetera, plus providing their own Argos CDs and Arbex and environments and such. And we also had these multiple namespace Argos CDs per team that are responsible to deploy application teams, their applications and tools that they need. And such shared tools like kits, like Argos CD, the same implementation, same approach help us, help them to speak the same language which help us to collaborate and communicate easier and easier. So in the end, you have the empower development teams that are getting benefits from platform services like ready to use Argos CD with pre-configured GitHub repositories, but they also have the knowledge to modify them as they need. And we also need to encourage, let's say that they modify something, they build a new plugin, they did some configuration that is gonna be useful for other teams as well. You need to encourage them to bring these changes, these additions to the platform back so they help you to improve the platform so they own the platform as well. And then you create this really nice whole feedback loop and inner sourcing maybe it's in your organization. So tie in all things back. Know your users, know where you are, discover enough to just get starting and keep things simple to verify, to experiment and collaborate to find more suitable ways to practice GitOps and other good practices as well within your organization without bringing the additional cognitive load to the other. So start from discovery phase and go through the loop and verify if you are on the right track by engaging with your developers frequently. So that's what I all want to say. Thank you for listening and remember, always have your head over your helmet. Have a good one everybody.