 It's good to see you all here. I can tell you at this time of night where I'm from, it's time for me to go to bed. So I'm going to be a little bit drowsy, but we're going to have a lot of fun and talk about some fun things over the next several minutes or so. Let me see what time is it here. We've got plenty of time. We're going to have some fun. I'm going to talk about being the developer's developer. And one thing you want right away is this QR code that will get you access to the entire slide deck. It's an open slide deck. You can get on Google Slides right now, so take a picture of that with your phone or grab the bit.ly link here at the bottom where it says bit.ly dev of devs. There's some interesting content in there that you're going to want to have later on. And you don't really want to take notes. You just want to grab that QR code. There will actually be another point in the presentation for you to grab a QR code because I'm going to need your help with driving a particular application. See if we can overwhelm it. Probably we can. Let's see if we can actually beat it down a little bit later on. Now, I'm here. It's actually been about three years since I've been here. Pre-pandemic, we actually did a dev nation specifically in this room with perhaps some of you from before. How many people actually saw us three years ago for a dev nation? Anybody? Two or three of you? Four? Fantastic. Well, welcome back. I got to tell you I'm very excited to be here. I love coming to India and I love coming to this city because it's such a vibrant city with so many brilliant people and you don't find that anywhere else on the planet. I can tell you this is the one place you can come and easily spend time with 50, 100, 500, 1,000 of your best friends in the software development industry and that is not common in any other city you go to. So a little bit about me, that's my email address if you want to reach out to me. You can also find that I do a lot of different things. Maybe I found conferences, maybe I found user groups. Basically I start lots of things and then move on in my life in some cases. I've written some books, been a Java champion. So I'm a Java guy, don't hold that against me, okay? Because Java's still cool. It's not, you know, it's still cool, right? Exactly. Okay, let's get into this. Red Hat has a lot of open source projects. One of the things I like to say is Red Hat spends over a billion dollars a year funding open source projects so you don't have to. And that means that we take all our products from that open source upstream and of course we have things like Red Hat Enterprise Linux. We have things like OpenShift based on Kubernetes. We have things like CoreOS or we might have the Ansible Automation Platform. And you're gonna be hearing about a lot of these things throughout the day. In my case, I'm gonna mostly keep things very high level but later on in the day I'll talk about some things like Argo CD and GitOps or maybe we'll talk about AIML and there are presentations around various developer tools. There's Ansible, all kinds of interesting content that you'll wanna check out throughout our day. And do take advantage of the fact that the folks wearing these t-shirts are the people here to interact with you and have a Q and A session, answer questions and that includes myself. I'll be here all day. I have multiple presentations throughout the overall day. Now, this is my evolutionary slide. If you've seen my presentations before, I've been using the same one now for 23 years, I think. I just changed the words underneath the characters and I love it because this means we're all on a journey. An evolutionary journey, if you will. We have to embrace things like DevOps and self-service on-demand elastic infrastructure and automation and CI CD pipelines, deployment techniques and of course, you too can now become a platform engineer. So when I use the phrase developers developer, I mean the developer who develops for developers. Okay, I know that sounds like I've overloaded the term a little bit but we're gonna talk about that throughout today's session. So the new term, the new buzzword for 2022 is gonna be platform engineer and I call that the developer is developer. All right, because this is the old world. In the old world, we thought developers could throw it over the wall to the operations team. We thought developers were no longer accountable. We thought developers were no longer responsible. Anyone here from the upside of the house? Can we see some hands? Look at that, all right, fantastic. Do you know what I'm talking about? Somebody thinks they can just go here. It might run, it might not run. Logging may be completely messed up but you run it. And I think that's incredibly unfair. As a matter of fact, I've worked on different application development teams where we had to fix that sort of behavior because developers need to own their code even in production. They may not be in a managed production but they need to know it runs well because your code has zero value until it lands in production. Now if software development looks like this, now have you familiar with the old Greek tale of the fellow that had to keep pushing the stone uphill and it would roll back down and crush him and he'd push it back up and roll back down? This is kind of how I think of software development and software delivery in the modern world. It's no longer a stone, it's this amorphous blob. It's just a big blob of stuff for trying to get this big old Java-E ear file out the door. Every three months we ship that thing. Every six months we ship that thing. It's a gang of people collaborating and how we will ship it. Now look at my person over here. Who's that person? All my developers in the room are going, that's Ops. They think it's someone's job to say no and come on, we know it's really the security team, right? They always say no. Or the database administrator, they like to say no. Someone's job is to say no and stop progress and that is unfortunate and we need to go beyond that. We want to use the concept of shift left, maybe bring those responsibilities and those tests earlier in the process of the application development life cycle. How about this person up top here? I know we have some of these folks in the room are architect, right? They're on top of this game, they're on charge, they're surfing this wave, right? They're in charge, they're facing the wrong direction though, but that's okay, right? They're in charge, they got it figured out. How about this person down here? I like to say that this is our operations person crushed under the weight, just trying to keep this big blob afloat because in many cases software, unless it's written well, does not operate well and that's a critical thing to understand and the people who know how to make sure their software operates well will be the winners at the end of the day because only they can ship quickly and know that when the software lands in production it will work well. Now, look at this here. If it takes several, a whole gang of people several months to ship software and it's painful and maybe you have to spend the entire weekend to make it run or you're up 24 hours for three days in a row trying to make it work, you have to do that again and again and again. That's a painful world. We gotta get out of that world. What we want is a world that looks like this one. It's a small cohesive team pushing all in the same direction, a nice cohesive piece of software, maybe we call that a microservice, call it whatever you like, it could still be a monolith. You might have heard of the phrase majestic monolith but the whole point is we work together to deliver better software together. And that's the key thing at the end of the day. Dev, Ops and the entire team related to the software development life cycle work hand in hand to develop better software, build better software, deliver it to production ever faster. That is the mission we're all on because I have to tell you guys one special thing about yourselves. You might not know this. Maybe if you've seen one of my presentations you may have heard this before but one reason I love spending time with all of you is you guys have a secret superpower. You may not, you might take it for granted especially in this city you might take it for granted but you shouldn't. There's approximately 30 million people on this planet of which you guys are part. They can put fingers on a keyboard, type in arcane commands and no one else on the planet understands and we call it code, we call it bash shell scripts, we call it PowerShell, we call it, you know, VI VIN, call it whatever you like and guess what? We can create something from nothing. That is a superpower. Don't take it for granted and the other 8 billion people on this planet want what you have. They want the mobile device in their hand to give them their accurate banking information. They don't want to find out their checking account is empty at the end of the day. We have to do our job as well, okay? One thing about the DevNation logo I want to mention the DevNation logo that you'll see and you'll get the t-shirt a little bit later you see this little symbol right here? When we designed this that was actually a little hidden secret, a little hidden symbol, you guys are gonna be in on the secret. When we designed that it's because I used to use this phrase right here dev raised to the power of ops. It's a multiplier effect, okay? In other words, if we build better software that's ready to be operationalized then we're gonna actually change the world more rapidly. Now let's give you a little history lesson. There's a lot to be said here we're not gonna have a lot of time but the concept if you look at my timeline here you can see where Java was born in 1996 but a lot changed in that process and if you go to the far right side of that slide you'll see things like Docker right there, Docker and then Spring Boot, Kubernetes and microservices. This was the perfect storm back in 2013 and 2014 that basically created the microservices cloud native movement. When that all happened Linux containers were a thing Docker was the thing Spring Boot was the thing. This fundamentally changed the world we build software in it all happened back in 2015. Also what happened in 2015 the Red Hat launched the first Kubernetes distribution to the world at large. We basically did it at Red Hat Summit and we basically launched a thousand plus application servers in two and a half minutes live on the stage. And by the way with the QR code you had earlier you have access to this link and go watch that presentation. And so that was a monumental moment for the world at large. We showed you that Kubernetes could change the game and how you orchestrate Linux containers. Also at that event we did this. We actually ran one of the very first IoT experiences. So we gave Bluetooth beacons, little Bluetooth tokens to over 300 people that participated in the event and we tracked them around the entire conference throughout the entire day. We collected millions of transactions based on the fact that those little Bluetooth tokens would issue a check, right? So basically with a UUID and a little signal strength indicator it would issue a check about two times a second and we had Raspberry Pis staged all over the building. So we could actually see what rooms people were going to that were breakfast and of course they came to the keynote room. So that was all part of that same presentation. I make this point right now because I want you guys to help me test something. We have a new application that we want you to play with. So you have a few seconds here to grab this QR code grab that QR code for just a second. We won't have a lot of time here but this is going to give you access to this little new interactive application I want to show you real quickly. Okay, okay, okay. Anybody get in yet? I still have to go get in myself. Let me actually double check this with my phone and here and we're going to see how much our network latency burns us here. All right, so let me get out of here and let's see, let's see. Looks like it's still hitting. Just double checking. There we go, all right, good. And here and here. So what this is, is a little game where when I hit go, okay, so there's my version of it here. Let me double check by hitting refresh. It's a little game where we put you into different teams. You also can see we actually gave you a name. So I'm Ramsar here and so I'm not on this list. It only shows the top five right now but there will be a top 10 at the end of the game. So when I hit go, you will basically contribute your energy by hitting the screen to your car on your team. So if you're on the gray team, if you're on the yellow team, like on my phone, I'm on the yellow team. So let's try that real quick. Let's hit go and see how this works out. So now you're going to see this little windmill. This is, you provide energy to the game. So I'm playing both right now. I'm playing left-handed and right-handed. Oh, okay. Let's see. Okay, you guys are driving pretty well. That is fantastic. Come on, now you got to hit that phone a little bit harder. Don't break the screen though. I'm not paying for that. All right, so I've got to tap, tap, tap, tap, tap. But this concept is incredibly powerful because what you're playing is a simple little game but it's actually backed up by a corkis application that then in turn is working with a Kafka broker and of course, Infinispan is an in-memory data grid. Looks like I got to catch yellow up here. Let's see if I can help yellow out. Nope, the summary's in the yellow team. It's always a little slower. Does anyone know why? Almost, almost, almost. Oh, whoop, whoop, whoop, whoop, whoop, whoop. And you get a little network latency there and you can see the blue team won. Okay, look at that. So HOSHA. Look at our winners right there. Okay, now we're going to tell you more about this application later in the day. I just wanted to get a chance to see how it feels but let's actually make a change real quick. All right, as I mentioned earlier, the whole point is to get code in production. So what I have here is a fully automated system and if I'm an application developer, I'm gonna bring up my Visual Studio Code and let me see, right now you see there it says Jumbo right there. Let's actually make it say Namaste and I'm also gonna make a change that you'll see on your phone. We're gonna enable shaking equal true. So right now you're tapping but you're gonna have an accelerometer featured in a little bit where you can actually shake it. We're not gonna turn on the blowing option because we just did survive a global pandemic. So we'll leave that one off but let's make that true hit save. And so get status. So as a developer, I just make my code changes. Of course you saw me run my test locally, right? Okay, you know I didn't. But normally I would run my test and I'd say get commit and let's see. So I said Namaste and shaking equal true. Just make it a nice little get commit there, get push. And let me double check one thing to see if all is well. Let's go here and like I said we'll come back to this and work on it later this afternoon but I just wanna get you to feel for how this works. So from a developer experience perspective all they have to do is get commit, get push. The rest is fully automated out to production including what you'll see on your phone hopefully in a few minutes. Okay, let's come back to this now and we'll wrap up some of the slide where. All right. Now, as I mentioned, 2015 we actually showed you that application where we had all those Kubernetes pods coming to life, 1,000 plus application servers. Now the world has changed since then again, all right? So that was 2015. Now the world has changed again. If you look here we have this thing called Spinnaker and Helm and Istio and Argo CD, the book called Accelerate. If you've not read it, came out in 2018, told us about these new metrics we should be capturing and of course Quarkus was born in 2019 but Team Topologies was the key milestone along the way because it taught us some new principles. If you've not read that book, I highly recommend it. And you can see right there ThoughtWorks basically said trial and adopt the concept of platform engineering. So we're gonna talk about platform engineering a little bit more because it has fundamentally changed the way we think of software development. So if you look here you can see it's on the ThoughtWorks radar, applying product management to platform engineering, internal platform teams and look at platform engineering product teams. So you hear a few key words there, platform engineering, product, product management. Those are some key words to understand. So what is a platform, all right? A platform, a digital platform is a foundation of self-service APIs, tools, services, knowledge and support arranged as a compelling internal product. The developer's developer builds a platform for developers. You get the title of the presentation now? So let's look at APIs, tools and services. In this case, this is what the developer's developer, the platform engineer needs to do. There's a lot. So don't think this is a trivial job. This is not for somebody who's like, oh, they're just an ops. No, this is someone who is king of that hill. This is someone who's queen of that city. This is someone who's gonna make sure things are ready to rock. There's a lot of activities in this category. Just to kind of call out a few here and kind of mention them, something as simple as, okay, are we gonna use namespaces as a service, clusters as a service, configuration management? How am I gonna get the environment stood up for that user is very, very critical? Because guess what? You don't want developers having to wait, filing a ticket, waiting days, if not weeks for a virtual machine. They should be able to self-serve whatever they need right when they need it. Based on quota, based on some form of internal charge back, that's fine, but they should be able to self-serve without tickets. Also authorization, source control. Do you use GitLab, use GitHub, use BitBucket? We gotta know, okay? What about your artifact builder? Is it a Maven package? Is it Gradle? Is it MPM? Is it PIP? Image builder. Do I use Builda? Do I use Docker? Do I use Docker build as an example? Podman build? Do I use Continuous Integration Solutions? Oh, Lord, there's so many of Continuous Integration Solutions. How many people here use Jenkins? Look at you all what Jenkins love, fantastic. But if you do use Jenkins, you might be tired of Jenkins also, right? I see one head nodding back there. So there's different CI solutions that are part of the system, different security systems, different artifact storage. Maybe I use JFrog, right? JFrog's Artifactory, maybe I use Sonotype Nexus. Maybe I have some form of Continuous Delivery Solution and what we'll see later in the day is Argo CD doing Continuous Delivery. Observability tools are super critical. I need to figure out what my CLI, Command Line Interface, API is, my DBaaS, my Kafka as a Service. I guess one of the things I have running at this moment in that system you guys were just interacting with is a Kafka as a Service. We could talk more about that later today. You gotta think about your developer environments. You gotta think about your tutorials, your golden path templates, and finally, you put a portal on top of this, and you might have heard of the Open Source Backstage Project. But you see there's a lot there, okay? So a lot there that we have to talk about. So the Digital Platform is a foundation for self-service APIs, knowledge, and support, and a range as a compelling product. So compelling is gonna be a key word we get to. Now, who do you do this for? Who does the developer's developer work for? Well, a developer's developer works for developers. The platform engineer works for developers. They work for those streamlined developers. They work for those application developers, those Spring Boot developers, those Node.js, those Python Flask developers, and also you might work for these developers, these 5.6 million developers that are part of a CNCF, the Kubernetes ecosystem, representing 31% of the actual back-end developer workforce. So already there's a ton of people who know Kubernetes. How many people here already know Kubernetes work with Kubernetes, touch Kubernetes? See the majority of you. Fantastic, you're in the right place today, because that's where we'll be talking about a lot today. Okay, as a matter of fact, the thing you were just messing with here, over here, QCTL, get pods, all right? So this is my Kubernetes running right here, including those Tecton tasks and Tecton pipelines that got executed to completion, and you can see, and actually it still says jumbo there, let's go back over here, and let's go here, and here, and let's go just kick it, make sure it's gonna get pushed out, there we go. We'll let that go ahead and push out. But over here, you can kinda see, I do have this complete Kubernetes environment. I can look at how many nodes I have, I can look at how many pods I have, and I can interact with it, and you can see my Namaste is rolling out, doing the rolling update right now, right? So it's taking down those jumbo, if you're familiar with Swahili, and I like going to Kenya, so say jumbo instead of hi. Now Namaste, you can see Namaste rolling out there right now, caught that just in time, look at that, I didn't even plan for that. Okay, so 31% of the backend developers are interacting with Kubernetes at this point in time. The reason that matters though, is think about all that YAML you have to edit. It is actually 20 steps, two zero steps, to get a cluster up and get Hello World deployed in a brand, when it comes to a brand new code base. And then if you wanna add CICD to it, is dozens of lines of YAML that's incredibly error prone. So we're gonna be working on some things like that, and you're gonna see some of that later today. Okay, let's talk about one other thing for your developer. Remember, as a platform engineer, you build as a developer for developers, and one of the things you wanna do for those developers is reduce their cognitive load. Because as an application developer, specifically in the Java ecosystem, if you're a traditional enterprise developer, back in the day, we did this thing called Cobol, and no one knows it anymore, but we did this thing called Cobol, and we did this thing called JCL, Job Control Language, and that was only if you're kind of the IBM universe, and you're cool, I wasn't so cool, I was in the Unisys universe, we had Wiffle, workflow language, we just weren't, we just were cheap. We didn't have the money for a good IBM big iron, but then we learned maybe things like C++, and 4GL, relational database technology. This was easy back then. Life was easy back then, because I've been through all these generations of these technologies. Look at up to 2016 there. The average application developer who's in the Java ecosystem now needs to know a ton of things to be successful in our ecosystem, and there is no front-end engineering there. There is no React, and Angular, and View, and all the server-side rendering, and all these progressive spas, right? Are you building single-page applications? And there's no Kubernetes. So we have to reduce the cognitive load on these people, because they're suffering from all this change in their ecosystem. And if you had to learn Kubernetes, it is an amazing ecosystem of technology at this point in time. It is overwhelming. And this is important because our goal, as a developer's developer, is to make this easier for them. Because guess what? Our developer is not a unicorn. Our developer is a horse. You know the difference? One is a mythical creature. This doesn't exist in the real world. The horse does, and we need to make sure they're fully enabled. Now let's talk about compelling, and then we gotta get out of here, okay? So compelling, becoming the developer's developer, is about platform as a product. When it comes to platform as a product, you need a product manager, a UX designer, and a dev advocate. If you're producing a platform as a product for a team of developers, I don't care if it's 10 developers, or 500 developers, or 50,000 developers, you need some folks to have these roles. Product management, UX designer, dev rel, dev advocate. And we'll explain why. By the way, here's a job posting I just found last night for Intuit, trying to hire one of these people. So if you're familiar with Intuit, the people who do those checking and accounting kind of things, all, and one other thing, yo, this is a good point. When it comes to being a dev advocate, you are a cheerleader. This is me 35 years ago, and more than 35 pounds lighter, obviously. So here's the point that I'd like to make about being a dev rel, being a dev advocate. Your goal is to be the cheerleader for those other developers. And there's a reason why. Your goal is to empower, energize, educate, enable. You want to help them with their superpowers. They want to build new applications, and you want to make sure they're building applications ever better, right? More secure, more reliable, more compliant. And when it comes to policies and regulatory checks, at the same time, more CVE free. When it comes to the tip of the iceberg, you have to think about all these different deliverables. As a platform engineer, one key thing I'd love to ask people is did you welcome the developers? I can tell you from a Red Hat perspective, we have a lot of communities out there, a lot of Linux out there amongst the biggest corporations in the world. And sometimes we find whole teams of developers not yet using that technology. I'm going to ask the platform engineering team why those people aren't using it. It's real simple. There was no welcome. You got to welcome people to your platform. And you got to do things like provide great chat and you got to provide for help, right? Help desk kind of things. You got to do things like MongoDB as a service, Postgres as a service. You got to do things like making sure you have nice video tutorials. If you don't have any video tutorials, are you welcoming people? Well, really you're not. Brilliant documentation is super critical. This is what backstage looks like. So this is the portal that can sit on top of all of this and then provide self-service when it comes to the developers. But this doesn't come for free if you remember the layers we showed you earlier. And then I want to actually see if our application changed and we're going to play one final version of this game with you. We do see Namaste rolled out. And if I look here, let's see if you guys could hit refresh on your mobile browsers. Let's see if we did this correctly. Yeah, there we go. So you should have a little red thing. So we actually just made a change to your application. As it's enabled shaking, go ahead and tap that because in iOS, you do have to approve it. And now we can play the game one more time. Doo, doo, doo, doo, doo. Let me find the right screen here, here and here. And let's see, let's rewind. Oh, so let me see my thing. My desktop got disconnected. Let me hit refresh. Yep, we want to log in and log in. All right, you guys are here now. Here we go. All right, there we can see all our players. And now you can enable the accelerometer and go. So in this case, I can shake with the phone. You can't shake with the laptop. If you pick up the laptop, it doesn't like it too much. All right, come on. You guys can work a little bit harder. You can also use the John Travolta move, right? I can't do that dance anymore. You guys kind of come to the demo we did about three years ago. We did all the dancing demo. The accelerometer is actually really easy to work with. Oh, there we go. I won this time. No, I didn't. But you know, I did pretty well. Okay, but that's an example of having a fully automated pipeline with a developer experience is nothing more than a simply editor code, run their test and do a get push. And the application rolls out into a production environment. Like I said, we'll be talking more about that later today. I need to get out of here and get this thing done. So let's see here. Come back here. Got a couple more things to tell you about and we'll wrap things up. All right, so remember, when it comes to being the developer's developer, you're building a platform that is compelling and interesting and it gives the developer, the other developer, everything they need to build better business applications. Your role is the architect, platform engineer, platformer's product, product manager, UX designer, dev braille, dev advocate, is to make sure they have all the tools they need. You got to focus on the team because guess what, software development is a team sport. We build better software together when we work together. It's a collaborative sport. Please do keep in mind there's a vast array of characters involved in the software development process. And the reason I use all these kind of fictional heroes here is because we are all geeks together. I'm not saying that ops is a wizard. I'm just saying they like Harry Potter. I'm not saying DBA is a zombie. I'm saying they just like the walking dead, okay? That's a TV show, by the way, right, you know. So, you know, and you look right there, I have my Star Wars and Star Trek people standing side by side. We're all geeks together and we can build better software because at the end of the day, what we want is continuous improvement. We want to build better software ever faster. We want to increase our speed, increase our velocity, increase our output, and most importantly, have better outcomes for our business that we're building applications for. And one quote I love from Victor Franco here. If you've not heard the story of Victor Franco, he's a Holocaust survivor, Holocaust concentration camp survivor. He has many brilliant philosophical statements, one of which I love. I love this one so much. This is when I teach my children. When we are no longer able to change a situation, we can simply change ourselves. We can change our attitude when we can change nothing else. So keep that in mind. If you're kind of stuck in a rut, you're basically saying, you know what? I heard some fun things today. I would like to do all those cool technologies, but my boss won't let me. I hear that a lot from people. Someone's gonna walk up to me at the end of the session and says, my boss won't let me. And you know what my answer's gonna be? Find a new boss. In this city you can, okay? Easily. All right. A couple of key book recommendations. These are amazing books. You can learn a lot about DevOps principles with the Phoenix Project. Lean Enterprise is very, very valuable when it comes to financing things. Continuous delivery by Jess Humble, of course. Super critical. The DevOps handbooks and Accelerate talk about the key form metrics for DevOps. Things like deployment interval, things like time to value. The Lean product handbook for product managers and people who wanna think about building that next generation product. Team Topologies, which is what we've been talking about today, the concept of a Streamaligned team versus a Platform Engineering team and Inspired, another book for product managers and people who are looking to build that next generation product. All right. Was that enough to wake you guys up? Well, I thank you all for your time. At this point, I need to turn it back over to Ignacio to carry you through the rest of the presentation. Thank you so much. So thank you so much, Bar. That was a great intro. I'm the keynote, and by the way, you saw the demo. One of the demos, this demo is going to be completely explained, the full workload during one of the sessions that we will go through CICD.