 Good morning evening afternoon wherever you are welcome to is that even the second stage of this amazing app modernization day modern app development actually so yeah would suggest it's like 3 30 ish p.m. in Germany right now but it's definitely earlier in other places in the world my name is Marcus and I'll be births at us host today so getting you all ready for an amazing keynote by a lifelong developer advocate Mr. Burr Sutter himself is gonna present everything you probably always wanted to know about becoming the developers developer I'm already pretty excited so I'll be hanging out in the background watching the chat there's not a lot of housekeeping that we need to do I just encourage you to use the chat feature if you have any questions reach out Burr also shared a couple of links already make sure to join the definition slack if you have any questions he also shared his slides so if you want to follow along live please feel free to do so and here he comes Mr. Burr Sutter well hello hello hello all right good morning fantastic I hope everyone's excited because we got a lot of fun things to talk about today and we're going to basically hit you with a lot of funny images a lot of fun slides maybe in few demos but talk to you about all things let's call platform engineering platformers product being the developers developer that's part of it so I'm going to be watching the chat feel free to throw comments there I'll try to hit them as I can and we're going to move really fast as I said I'll probably drop some URLs into the chat and let's go into screen share though so actually I'll give you a survey in a moment so look for that survey share screen here let's get this one okay okay okay so you now you should see my nice big unicorn there so we're going to talk about becoming the developers developer the idea being that there are developers who develop for developers hopefully that makes some sense right developers who develop for developers I know it sounds kind of funny but you'll make sense as we get through the presentation so let's dive right on in here boom boom boom boom we get the mouse on the right spot okay one thing I'd like to mention though is when it comes to dev ops or specifically dev nation and the icon that we use there we gain we came up with that icon for a reason so I like thinking in terms of dev ops right you've heard that from me before and some people might think of that as dev greater than ops some people might think that as ops less than dev hopefully they don't think that way but I've heard things of that nature but what about dev raised to the power of ops right that's what I like to think about there so that's why I have that little carrot there and that is what became part of our dev nation icon right so that just keep it in mind for people here for dev nation today that was why that was there that's a little bit of history and I think we're going to talk about dev sec and ops today all right so let's talk about your journey to awesomeness you've seen this kind of slide from me before but we're going to focus a little bit more today on what it means to be a platform engineer offer platform as product and think about what it means to offer an IDP and all the elements that might go into that we're going to talk about a lot of things in a fairly short period of time and this is not meant to be a deep dive into any one of these areas it's more a high level set of ideas that hopefully will inspire you to go do more things now we're going to have a little survey here let me copy and paste the survey URL into the chat so you can either grab that QR code off my screen I'm also going to put it here in the chat there we go you should see it there I don't see anyone on our public slack but you know for anyone on our public slack was that there also and so if you're on the dev nation slack you now have that link if you're in this session you have the link also jump on that item right there and then you're going to be answering a couple simple questions for me okay so let me get out of here and show you what this thing looks like as you respond there we go so let's go here so we just need a few people to answer the questions our goal is to better understand her audience is and for those people who are in fact managers claim it own it be proud of it right I'm in management these days myself not necessarily a day-to-day program any longer and that could probably be a good thing looks like we have a lot of architects here I love that word architect because it can cover so many different roles within an IT organization nobody claiming the business analyst role and surely there's got to be another somewhere in here meaning you know I don't like any of these roles I think they don't really fit me very well but please put that into the session it'll have don't give me a better feel for who we have with us today and also I think for our developers or ops or architects you're going to see some things you like in today's session our loan security person here do not feel that you're all alone right we're going to talk about some security things and hopefully hopefully you'll find that I I got it right for the security person you can tell me if I got it wrong and you can do that via the chat feel free to yell at me and chat as we go throughout the session okay you can see we have a pretty good crowd here now let me ask you one more question there's another question on a little survey and I want you to think about this for a moment because I find this to be a massive challenge within an IT organization so when I go out and speak to large customer organizations when I go out and speak to large entities I'm talking to big branded guys right that you know the Fortune 500 the S&P 500 the global 2000 they will tell me that once they once they discover what what it means to make a developer wait right they have developer wait time well here's the scenario a new developer was just hired they got their laptop they got their VPN they got their access to the system how long or how many weeks does it take for them to become productive or let's say you're a developer already working at the company right how long does it take for you to get access to a computer access to a virtual machine you file a ticket and you wait right so think about that for me and let's go to this next slide here if it will go there we go so I'm just kind of curious to know for anybody who has to request from central IT how long does it take to get access to a virtual machine access to a computer basically because if I have a great idea and I want to build my next generation cool thing and I might need a virtual machine with that Kafka running on it or maybe I need access to a Kubernetes or OpenShift cluster or maybe I need access to whatever resource I file a ticket and I wait and I wait and I wait how long does it take you to wait and I'm just kind of curious to know what that is for the audience here and you can see we have some people saying less than a day I'm wondering if those are people who actually are the VMware administrators and the big organizations you know who have access to those virtual machines as the as the ad bins the cluster ad bins as an example and it's funny too we see some people here at 10 plus days I've actually found that many corporations are in that three week plus world right one actually told me six weeks so I make this point because this wait time that we're talking about here any wait time at all if it's longer than let's say 50 seconds or longer than let's say an hour or two the problem is you have people who need access to resources sitting on their hands and waiting would that be their getting started experience as a new hire or I have a new idea where the business has come to me with this amazing idea and I want to start on it right now so wait time is part of our traditional IT world and I think that's highly problematic okay so KVM there Christian fantastic so if you got access to KVM you can launch your own virtual machines rather rapidly but I do wonder Christian if you work for big old corporation you know how many VMs can you launch without them noticing and or asking you to wait for them okay so thank you for that information that just kind of gives me a little feel for what we're doing in our world let's get back into our little presentation and get rocking here okay so let's talk about the world of dev versus ops you notice my little programmer here on the on the left hand side my programmers rocking the headphones and at 445 on Friday they think they can just check their code into their get repo get commit get push and their high five in each other they're out the door they're heading for the pub at 445 on Friday while the ops person often Friday night if you work in a big bank or maybe out throughout the weekend has to figure how to make that thing run and I have had this personal experience working with a production team both the development side and the operation side I was the owner I own both sides of that equation and I had to get the system up and running the new changes in production by Monday because that's when the business started back at their jobs now this is eons ago before we started 24 by 7 businesses but that concept bothered me greatly the idea that the development team just thought they could hand off whatever garbage to the ops people and the ops people have to suffer accordingly and that had to change and in this specific case I actually brought all the developers in on Saturday and this only had to happen a couple times by the way so in order to help the developers understand empathy we brought them on Saturday where they just simply watched the operations team struggle with the deployment of their code base into production you do that two Saturdays in a row the developers write vastly better code and this taught me a valuable lesson this is actually 20 plus years ago right they taught me a valuable lesson when dev understands some accountability and has some empathy for their code running a production where it sees real business value they fundamentally change their ways they write better code so I'm one is thinking about that basic concept can developers write better code once they understand having said my accountability some responsibility and seeing what it looks like in a production environment because in many organizations it might look like this right the ability push code to production might be this amorphous blob much like you've heard the story right before I think it's the Greek story where I forget the fella's name to basically kept pushing the stone the boulder uphill and it kept rolling back down on them and crushing them so push the boulder uphill roll back down and crush them that idea here was what I what inspired this image and I like to think of software development not as a nice boulder right boulder would be awesome that has structural integrity software is like this amorphous blob of stuff with a gang of people trying to get it over the finish line push it uphill and you can see right here we have this person standing in this direction and you might be thinking well who is that well I know what some of you are saying right now you're screaming at your laptop you're yelling at your microphone that's the security team or that's the operations team the compliance team right Sisyphus there you go thank you Joseph right so you you have the idea as to who's pushing back who is basically saying this cannot go this shall not pass it's not Gandalf by the way all right how about this person up top here you might be looking at this person going wow okay they're on top of the thing they're on top of the game here but they're facing their own direction ah that's our architect we had so many architects earlier right so we know our architects they're on top of their game well hopefully they're facing the right direction most often than not but they're trying to surf the blob we're trying to ride the wave hoping to get over the finish line and make this magic happen and how about this person down here at the bottom well this in fact if you actually are from my world of dev sec ops dev ops that is my operations person so I'd like all the developers here to think about who is being crushed under the enormous weight of this blob that we've created all right so yep so you can see right there where someone's in that situation you basically are feeling that pain now here's the part that's really funny about this to me if we are successful at pushing that blob up the hill and into production once we have to do it again in three more months in three more months again and again and again and those three months in deployment intervals why they seem long at this point in time they're actually fast by javie standards we used to be six months twelve month deployment intervals but still it doesn't matter what the deployment interval is the problem is it's inhumane we have to do this again and again and again so think about that it's not fun because what we don't want anymore is the concept that the developer can throw their stuff over the wall and hit the other person in the head this is no longer the fun way to do things the developer and the operations team have shared responsibility from this point forward they have to go hand in hand to deliver the software to production together now I want you're thinking about security now right we're going to talk about dev sec ops more today and guess what there's a third party in our love triangle so think about that for a second there's not just these different development teams that run and are out there associate with different lines of business and there's not this central it ops team or platform team responsible for the infrastructure there's also the security compiling and compliance team the people that are basically producing all these controls they use the term controls they use the terms evidence they have people taking photos with their smartphone of people's laptops to show that people did a certain task we're you know they're kind of living this weird world they have their own weird language but they are part of the equation and we have to embrace them we have to include them and also teach them English because I have noticed whenever you speak to them they speak almost like they have their own jargon and it's still related to the software that we build an architect which I think is very interesting so let's talk about dev second ops for a moment and this is actually important and a subtle message that I want you guys to pick up on here okay so if you think about developer right the developer the security officer the security compliance engineer right the ops engineer the dev ops engineer whomever you how are you titled those folks and there are definitely more than three people in the equation but those two C's three whatever the three of them have to articulate and think about a problem they probably all have their own unique right their own unique way of thinking about that problem in other words we might all be looking at the same thing and if you've seen some of my other presentations I love talking about the five blind men and the elephant right if you've ever heard that metaphor or seen that parable this is the same problem it's all about communications and the idea here is that we form different images in our head based on hearing the exact same words we can all interview the same user and come up with a completely different conclusion we can all read the same document and come up with a completely different idea an image in our head and so that's a very important point and I want us thinking about that because these folks have different motivations they have different incentives developers want to rock out their innovation knock out new capability here's new feature new feature new feature operations of course values stability resiliency reliability they want to make sure this thing doesn't just get ripped down by you know just simple load of all the people coming in and hitting the system and then a security team wants to make sure hackers don't camp out in your code base and run their crypto miners on your infrastructure or steal all your data right that's an important aspect of this also so how do we actually get more collaboration on these folks how do we actually get it so that they have the same image in their head with greater collaboration a shared understanding and shared responsibility this is tricky and the ultimate goal is to make it so they all love each other now you might be thinking this is a very funny image how in the world can we love these people they're not like people well I've had this discussion with developers and architects before I actually had someone challenge me years ago bird you don't understand I can't deal with that person over there they always tell me no they never will let us do anything innovative and interesting and introduce a new software a new open source capability whatever might be and and I'll say wait what was the last time you took that person to lunch and you can tell I had blown their mind their face was like shocked like what do you mean take the person to lunch and I said they're human too and I bet they eat lunch or at least they eat food so maybe you can have food with the person and act like they're human and that was a game changer I could tell that moment they're like oh they are human yes these these folks are humans and they behave like humans they just use different jargon all kinds of funny nomenclature they'll talk about computers and talk about software which I always think is interesting because it's still software and computers I don't know why we have to have funny jargon but the point is we actually all want the same things is so important so important okay all right let's keep going the ultimate goal here is to have shared goals share responsibility dev sec and ops all working together as a unified team to push that boulder up the hill by the way I didn't mean here that dev is pushing security team just pushing the ops team that's not really what I was going for the goal here was that they would all be working together there's also that free ebook there that you want to get access to and if you have access to the slide deck you have access to all the links by the way I published a slide deck URL in the chat earlier but you want to make sure that you can get access to everything and we have been using our our our our research tools to basically discover more information about app security developer gilly observability consistent configs so if you go get that free ebook you'll see where our UX research team has specifically sat down with developers interviewed them and platform engineers by the way to understand better what their shared responsibility model looks like what their underserved needs are and what that means to live in this new dev sec ops world so there's a savannah they're published the deck one more time feel free to grab access to the deck and then go download that free ebook okay so here's the ebook cover make sure you go grab that get a copy of that right there you can see call in dash and marcus all worked on that marcus as you saw earlier in our introduction go grab that book it'll give you some really nice information about how to secure the software supply chain or the needs therein when it comes to dev sec ops a quick history lesson and we'll keep moving pretty fast here because we don't need to spend time on the all the history for some of us here we've lived through this history in my case i live through more than this history but i think it's pretty interesting to understand that java in the case of for those java folks out there it was back in 1996 and htp 1.1 was 1997 so think about that for a second we've been building htp based applications since nine you know actually before that htp 1.0 back in 95 you know we've been building web-based stuff for a while red enterprise linux over there in the year 2000 okay so so many things have happened the agile manifesto in 2001 i actually found myself quoting the agile manifesto to someone just this year so yes it was a document published in 2001 but people still don't know what it means and sometimes we have to talk about it with them so look at all these amazing things that happen in our journey to becoming cloud natives you can see where spring boot happened and docker and microservices and kubernetes and all that came to a massive big conclusion in 2015 at that moment is when redhead launched redhead open shift specifically based on kubernetes and we showed the world these things called containers and pods we launched a thousand containers and launched a thousand pods live on stage and that link right there will get you access to that demonstration but that's from 2015 it's 2023 eight years later what has happened in the last eight years and i think it's important to think about so over the last eight years we introduced some new things like helm and spinnaker and istio and git ops was born git ops by we works in 2017 argocd born in 2018 the accelerate book where we learned all about the dora metrics over in 2018 those four key metrics of course by thoughtworks they recommend the trial of them but now we're talking about things like team topologies the trialing of platform engineering the adopting of platform engineering so a lot has happened since that 2015 moment okay and so we i just wanted you to think about that and by the way i mentioned corkis here that was born in 2019 some of you just saw some of that today for the first time but this is an example of all the innovation that is occurring and you should note that it's occurring ever faster than ever before okay so let's talk a little bit about what thoughtworks says about these things they're talking about applying product management to internal platforms they're talking about trialing platform engineering teams so in other words there's these new phrases that are showing up in our vernacular right this concept of platform engineering this concept of product management around the platform and this is super critical and for many of our architects and developers this is the space you might want to play in going forward at least if you work for a large organization that it serves a large number of developers and i think it's important for us to be thinking about it and talking about these things and some of you might know that i have spoken to many of you over the over the last couple months about these specific topics i know christian and i spent some time together wolf gang and i spent some time together so perhaps some of you and i have already talked about say these same things because what our goal is now is to practice platform as a product so it's more than just platform engineering platform and what do we do to create the developer experience it is about actually productizing it thinking in terms of being a product manager and what it means to deliver that product to our user base okay so what is the platform all right a digital platform is a foundation of self-service apis tools services knowledge and support all arranged as a compelling internal product we're going to break this definition down and show you some very interesting things about it okay so we're going to get into this so apis tools services and knowledge this is so critical self-service apis tools services and knowledge so right here i tried to identify maybe some of those apis and tools that we're talking here and services that we're talking about now in your platform you don't have to do all these things you might have to do some of these things and you of course have to choose tools across the software development life cycle that meets the needs of your organization you can see right here based on the stack that some of these things are lower level like we need to figure out what our compute network and storage look like our infrastructure looks like are we using kubernetes and namespace as a service or does everybody get their own kubernetes or does everyone get their own virtual machines how do we deal with configuration management etc and then the very top of the stack is something like backstage the portal all right the portal being the user interface that people would engage this entire layered cake of opportunities here but it should be noted that right away this is not a trivial thing to go do organizations have been working on this for several years i've and then again if you've spoken with me over the last several months i've spent time with some of the world's largest organizations talking about this stack and the way they've implemented parts of it within their organization so much has happened within the space uh and burr still has hair and that's true i still have some hair left on my head it's getting grayer by the day okay all right all right so let's get into this i want to kind of do it from this perspective all right so think about the pipeline think about what it means for the decoder to write some code and get it all into production right so we've been talking about that a lot today and the reason i focus on this topic is because i'd like to tell all the programmers out there the developers those programmers i talked about those developers right depending how you think of it the if you write a bunch of cool code it doesn't matter how cool your curly braces are and how great your semicolons are and what your spaces versus tabs are and how elegant your algorithms are and the fact that you use go rust or c sharp or java or javascript the issue is until it runs in production it adds no value so it is value less until it makes it to production and serves the need of the organization was meant to serve whatever that might be so let's talk about that for a second and think about the pipeline okay so the developer is going to be doing their edit save refresh if you've seen a corkis presentation these days you've seen edit save refresh write a low code save it the id control s refresh that browser boom we see that java code now running instantaneously it's kind of like magical because we're not used to seeing that in the java universe maybe if you're javascript or python you're a little more used to that sort of behavior but the idea of edit save refresh edit save refresh fresh using your favorite id using your favorite tool like intel aj or or maybe you have another jetframes id or you have vi or emacs it doesn't really matter notepad plus plus it's still pretty popular i think okay all right and so you're gonna run the test you're gonna run your debugger you're gonna do a get commit and get push right so think about that get commit get push it's like the magical moment because you think i'm ready i'm ready for the world to see my creation i built this amazing thing got my curly braces semicolons all sorted out and the world should see it so this point the next phase kicks in the pipeline kicks in a web hook kicks in maybe it's all based on your git lab or your github but the web hook kicks in kicks off the pipeline and it runs your jengens your azure dev ops your tecton right whatever it might be your rennet trusted application pipeline and it's going to do a get clone it's going to do a maven clean compile test it's going to run those same tests that you ran on your laptop in some cases it's going to compile in a package it's going to create the fat jar if it's a java application and this is of course maven if you have an npm install or you might have a pip install things like that and it might even run check style it might even run sonar cube so you're going to wrote a series of tools within the pipeline to do the basics of checking everything out seeing that things are okay as an example and that's part of what people think of as the development stage then there might also be an integration phase or a performance testing phase soak test smoke test phase but typically we might use selenium we might scan things with sneak we might use cucumber for additional you know testing we might push to repository maybe that's our artifactory by jfrog or maybe it's quay but we're going to basically do all these things in the context of the pipeline and then of course when we're ready to roll it out and employ it we might update a get ops repo we again might have a web hook associated with that we'll do a get clone maybe but argo is going to basically do a diff and sync and it's going to basically move those bits into that production environment by syncing what it sees in the get repo into what is the live running system so argo is a key piece of that and of course we have our monitoring solutions like for metheus cabana and pager duty and data dog and we're going to basically just ensure that everything's all good everything's all green we're going to have our different analytic tools to identify that okay so it's important to understand who owns what the app developer kind of owns these things like the edit save refresh the right they have their laptop they run their local test they run their local debugger they use get command line or get gooey from their visual studio code or intelligent so they have a lot of control over those kinds of things including what goes in the palm xml or the package json or the requirements.txt and then this other group of things right is often negotiated or collaborated with uh with the platform team the platform engineer the architect the security influenced aspects of this the security team wants to say hey run the sneak scanner or run the you know uh sonar type you know scanner whatever the scanner it is that they've selected so all these things happen within the context of the pipeline that glues all this together but it's actually a collaboration of multiple parties working together so one of us all thinking about that because it's important to understand it's not that the developer controls everything and it's not that the operations the platform to be able to control everything or the security team it's a collaboration where we all work together okay also let's not forget about our end users out there those accountants and nurses and bank tellers the people who use this stuff at the end of the day i think we tend to forget that as an industry and i know i often forget it as i'm out there talking with developers and operations folks and security people so like at the end of the day what matters are are the end users who wanted the thing right whatever the organization is are they benefited and positively impacted by the change that you made you fix the bug you close the back door of the security flaw you added a new feature did they have a positive experience we've got to forget uh remember that more often okay so let's talk more about self-service and some support ideas compelling internal product there's some interesting ideas here now in order to be compelling and self-service we got to know for whom who is our target and i think this is so important because if we're platform people who is our customer so our customer if we think about it and we understand the book team topologies a great book and i have a whole group of book recommendations at the end we would basically say that they stream aligned team is the customer of the platform team the stream aligned team is the team that's producing the value that lands on the end user mobile smart application smartphone application right it's the mobile app that lands on the smartphone it is the api that they consume in a b2b business business sense it is the web based application that the refresh in the browser and see the change based on what was changed them so the value stream aligned team is a customer of that platform team and so let's talk more about those platform people because let's understand who our customers are a little bit better so if you look at the annual survey from 2021 the Kubernetes annual survey you'll see that the Kubernetes ecosystem is claiming 5.6 million developers and 31 percent of all back-end developers that kind of blew my mind when i saw that statistic so they're estimating that they've already penetrated the market of 31 percent of all back-end developers that's kind of amazing to me and we'll see some other numbers in a second to show that that's actually a fairly deep penetration when it comes to the technology adoption lifecycle so developers feel like they're they're learning that Kubernetes thing they're knowing what a kube control api dash f is they know what yaml is they know what deployment service and pod is that's interesting to me because at the end of the day what we really need to do for that value stream aligned team is reduce their cognitive load so let's think about cognitive load for a second now this is an important slide that we should talk about for a moment for those folks who've been around the block a little while and i'll tell you a little story right i actually started back in the days of wiffle see that wfl there not the jcl the jcl was for the cool kids that's job control language they had the expensive ibm mainframes the company i worked for didn't have that kind of money we had the inexpensive unisys mainframe and we had wiffle wfl workflow language but at the end of the day it was all cobalt or some derivative of cobalt for gl generation language and there was a built-in ide right inside your green screen terminal and you had a terminal and you worked on that it was mostly batch-based applications as a matter of fact if you were a programmer back in this time frame you might actually write some code and that would spin up a tape drive write it to a tape drive you would then carry the tape drive to a little set of cubby holes because the cubby holes were where you would input the tape drive just lay it there with some instructions maybe some written instructions for the operations team who wore white lab coats and sat in a really cold room that might actually gas them with argon in case there's a fire and they work with these machines that were the size of you know wash machines and refrigerators and they would load that tape and they would run your program and this is all just to debug your code by the way and then they might give you a big green banded paper report out the other end and put it back in the cubby hole and you know the the next day you come back get your tape back get your green banded paper back and know if your application worked or correctly or not that was how you're in a test now some of you are a little bit motor schooled not you're thinking wait I had I actually had punch cards well I am a little bit I'm talking post punch cards here okay so the idea is that things have changed dramatically for the developer the days of actually building a tape and running and getting a paper report just to run a test and a debug right is changed dramatically but it has changed in such a ways that it's so complicated now if you think of the person in the modern era has to know something about what serverless is and of course they have the cloud they got this Kubernetes thing they got Node.js and Java you might be learning Go and Rust and Python because you're doing a little data science right you got to figure out what to do with gRPC at this point and View React and you know Next.js and Angular there there's an amazing amount of things to be learning at this moment in time and it is a bit overwhelming I imagine just looking at the slide right now it's giving some people a little anxiety as they think about being overwhelmed themselves okay so Mark there has basically been part of the Wiffle language also so there you go so I actually had this question came that came up in an email thread and I know it's too small to read on the slide that's why you have access to the slide deck and this was a basically the summation of an email conversation that I had with a group of people within Red Hat and some people were asking why is it so damn complicated why is it so hard and I had to think about it for a second but this was our response and I kind of put it right here on this slide because I think it's super important for us to understand why is it so complicated because 20 30 years ago when we built applications and software developers those applications went to our brother and sister employees right in other words we built apps for employees of about one to five users at a time about 20 years ago the average user count per application was a little bit more than one user okay so that the world was one user per application instance back in the day primarily because we ran everything on desktops we did this thing called client server right we basically had microsoft office and access and fire uh fox pro we basically use things one user application right one user and maybe we had five users if we had a multi user system in the new world we're living in right we have an application that basically is using ai real-time video streaming to do a tiktok dance move analyze it real time for a million users or consumers with their smartphone so the world has changed dramatically and because of that dramatic change of user count user volume and also a tax service and security concerns because guess what if you're making an application available to the world at large via tiktok and the api well that's got a different security profile than if you were just giving it to a single employee within your business within your organization and on your vpn so we have to constantly figure out how to relieve that cognitive load relieve that pressure because we're always improving we're scaling we're more better securing making things more reliable and reusable okay now look at this for a moment this is the kubernetes ecosystem again why is it so complicated why are there so many things i might have to learn and i know there's just far too many i can't learn them all i don't have time to learn all these things either so we at redhat try our best to basically educate you on the ones we think are important and are interesting to us so we do that sort of thing hopefully and curate this for the rest of you okay now cognitive load can be overwhelming i like this particular set of animated gifts it's like uh there's just too many things happening at the same time so now we got to reduce cognitive load but let's talk about compelling and this is actually the most important part part the platform you create for all the other development teams to be that developer's developer to be the architect is to make it compelling and i think this is super critical and this part i want to focus on for the remaining part of our session this part that super excites me if this is not obvious so digital platform but all the self service api's tool services knowledge and support arranged as a compelling internal product internal product and it's got to be compelling because it's not mandatory no longer are you going to be the draconian boss who says you must use this tool because we say so you must use this capability this portal this uh this ci solution this task this uh security scanner because we say so because it needs to be compelling because what you want is a greater solution that makes the developers ever happier and ever more productive and we as a whole work well together so i want to talk about this thing called the technology adoption lifecycle the tlac the talc i call it technology adoption lifecycle a lot of people may not have heard of this but it's an important element that was invented i think back in the 60s at this point i came to learn about it back in the early 90s based on the book called crossing the chasm if you never read this book i highly recommend it there's a bunch of other book recommendations later in the slide deck but this was one of those moments uh where i read this in early part of my career i also took a bunch of classes around tqm and learned the deming model for manufacturing back in the early 90s between this book and learning about deming and total quality management and how the Toyota process worked i taught me a lot about how i think about software fundamental game changers for how my brain worked at the time so i like thinking about this technology adoption lifecycle a lot and it breaks down into these major categories from innovators early adopters early majority late majority and laggards now i'll tell you right now you as a large audience here on the public internet have not i've not really given this presentation outside of red hat before so there's going to be some things in here that might be controversial and i want you guys to yell at me and chat if you feel i've offended a group or not or someone like that uh you know it'll be interesting to see how people react to what they're about to see so if you believe that the technology adoption lifestyle does have this five buckets if you will and there is this bell curve of where the majority sit versus the people at the uh the various ends it's important to think about what psychographics motivate these people what might they do how might they behave and who in my organization that i'm seeking to serve might fit these things the fit these uh psychographics fit these characteristics so like the ubergeeks the hardcore innovators the some of the folks right in this chat right now you might go out the github find the source code and you're happy to get cloned and build from source to use that new component that new library that new capability and check it out you might even fork that project on github you might even start your own project on github but you know how to go direct to github and and direct to source to understand better what that capability might use you would actually read the sources to learn the api you might look at the read me file the markdown file but by default you can also dig into that go code and i've had to do that myself or dig into that java code or that javascript code to understand it and you might also be a little bit of a disruptor you might be a change agent you might be a catalyst and you tend to work at dot coms or startups or maybe you're an innovator within you know the big bank or the big insurance company but you're an innovator you're a super ubergeek okay now what about the early adopters now the early adopters are still going to be looking at some of those same things but they would prefer to download a zip file or npm install or basically you know use a go module while they can certainly go to source they you know would just rather consume the thing that's already ready for them to consume maybe they brew install it on their mac or they basically use chocolately and install it on their windows machine or they might use a sass based api and they'd like to have documentation they'd rather not have to go to the source code and figure it all out they'd rather read their markdown file that nicely lays out exactly how they should get started and what they should do and what this capability involves that's a key element of it they will participate in forums they will also contribute and write and speak at different conferences like at this one today right now they work as consultants or maybe they work in vendors maybe they work for red hat as an example and i like this when i put this one on here they own their own laptop this is a lesson i learned many years ago if you're a professional software developer operations person architect etc etc you should never be beholden to your employer for computing hardware let take that crap and toss it off your desk because we all know that the the uh the stuff that they give you at your corporation is normally junk and five years old or three years old that's true red hat by the way too we give a lot of crap to our people go buy your own real good hardware and keep it where that be desktop building your own little lab building your own data center buying your own macbook if that's what it was required because they won't give you one buy your own hardware if you fall in this category of early adopter then there's the early majority now the majority is where we get the meat and potatoes of the people right this is 34 percent as you read the crossing the chasm we are now crossing the chasm right and getting to that majority and these folks want tools they want wizards they want examples and tutorials they want patterns and practices they want obvious productivity gains and they might go to the conference given by the talk given by the early adopter they might actually read the books and blogs written by that early adopter and they might even go to a user group and they might even deliver a brown bag lunch within their organization okay could be could be a thing that they do now let's look at the late majority so the late majority tends to move when the boss is sold the late majority will always use google and go stack overflow to copy and paste they would prefer our formal training class okay they might want a mentor who can they find to be a mentor for them and they tend to adopt a technology when it starts to impact their career in other words they're not going to be super proactive they're going to learn that thing called java now because you know what their Pascal skills are running out of gas they'd like to keep working for a little bit longer so so even though they made a good living for the last 20 years on Pascal now they're learning java for the first time because they'd like to keep working for a little bit longer before they retire so if you're a java person you might be thinking now i gotta learn a little go or a little ruster a little python or something else or a little java script so it the point is that they tend to be motivated when they're forced to be motivated this person by the way it's the same person that the boss okay think about this in your old office before the pandemic we had all our cubicles we had our chairs the boss might actually print out a blog or print out an article and leave it on our chairs so when we came in the next morning we might find that article and go oh the boss wants us to look about look at this new technology or new technique or new idea like continuous integration for the first time now the laggards of course they demand training so the late majority they'd like some training formal training laggard say i need training if you don't train me i won't move as a matter of fact i love the training because it gives me a week off from work okay i love the brown bag lunches because i get free lunch give me that free pizza that's an awesome thing so i make i make these points because guess what i have no problem talking to you guys here in this conversation about these things because you are not laggards if you are here you're probably not late majority if you are here because you would not be here if you had the attributes of a laggard even like majority you are here and therefore you're probably early adopter early majority okay but this is important because if we build platforms we build tools we build capabilities this is true of red hat or true of anybody out there in the platform engineering game you have to understand the audience you have to sell to okay i like refer to this concept of pathfinders and builders i put them in two big groups to make this a bit easier the pathfinder as a pre are the influencers you must motivate that you must capture if you can and you if you have them in your organization if not you get to be the pathfinder for your organization and then the builder are the people the worker bees the people who have to bang out that code you know kind of that nine to five experience if you will doing the work they're given here's another way to think of this if you worked in a manufacturing organization there are the engineers who designed the productization pipeline meaning the people who designed the assembly line make sure all the tools are in the right location make sure all the blueprints make sense that's the engineer and then there are the assembly line workers the people come in every day and punch out the square peg into the square hole you've got to have both types of people to be productive and successful in today's world okay so the pathfinder you got to think of them as your marketing target the builder is your production target your product target you have to build tools and capabilities for the average builder while at the same time making sure the pathfinder to be successful all right so think about it like this though we're not talking about unicorns here we're talking about horses all right i like this little book and i thought the image was great go get it go that link there and get you a copy of the book to read it to your child now this this developer game is important to understand because there's 31 million developers according to idc as of 2022 now this number used to be 20 million i've been saying 2020 idc up the number on me i want paying attention so it's 31 million that's a lot okay and it's grown from 20 to 30 just in the last few years and it's expected in the next few years to grow to 48 oh my wow so where are all these people coming from it's like they're coming out of the woods here and everybody wants some new ai train model they want some new you know web based api they did a web app they need something they need a mobile app well it turns out that growth is coming out from uh coming from the low code or no code world so that might impact the way we think of our platforms too am i building for the command line developer the hardcore developer with vi emacs skills who knows how to write that java code or i'm building for the person who likes to point and click and that's could be a very way a very different way of thinking about it okay all right so how do you do this how do you figure out who your users are and how do you speak to them this is important you got to think about how to build a collaborative environment around apis and your entire ecosystem should be api driven your entire platform infrastructure should be api driven because the goal is to make this plug and play customizable very reusable and they in turn your developers are going to build apis themselves so this important thing to understand another thing that's important to understand when it comes to being the developer's developer is you need three additional roles if you're a platform team without these roles you're going to struggle all right so one is a product manager who it owns this platform this platform as product and wants it to be awesome for their customers otherwise known as application developers right might be the low code might be the high code i like low code versus high code might be the vi versus emacs it might be the you know point and click it doesn't matter the product manager basically wants to learn their customer base and make sure their product is awesome for their customers the ux person this is the person who's going to be doing that research and understanding exactly what the user experience ought to be they might be a design person might be a research person might be all the above and then here's the developer advocate the person who's going out there and evangelize make sure those golden path templates are awesome the documentation is awesome that you can get on board it and they're right there in the slack channel with you every day to say hey guys here's how you do our new cool thing i'm here to help well this can all be one human it's a little hard for one human to do all these things but it can be one human and but these roles are important when it comes to understanding what it means to have that platform all right so here's an example for senior product manager for developer platform and i just put this in here you can see into it as a company more and more big organizations are hiring product managers to be associated with their internal platforms so if you don't have this person yet you really ought to find this person perhaps it's you right now in this call you can volunteer to be that person and take yourself on a whole new career career trajectory all right if you're going to be a product manager though you got to at least understand a couple basic things read the book by um read the book here at sv svpg right this is a guy named kagan he basically talks about the four risks the four risks include feasibility usability viability value so is it technically feasible meaning can we even engineer this thing is it usable can the user even consume it all right can they even do what they need to do with that api that web application that mobile application whatever it might be can they read the readme file and the markdown uh the markdown readme file and the github repo is it viable can we afford to do this as a business can we invest with all everything we need to invest and the most important one and the hardest one is does it add considerable value considerable value to offset the cost whether that be the learning curve or dollars associated with that new innovation that you hope to put out in the market so think about this for a risk and one thing i'll tell you and we got to wrap up here in a few moments and you feel free to throw questions at me in the chat i do see those things going by in real time i also see some of the stuff happening over there in slack looks like jack there responded to my mentee meter uh sounds like a brand name for lie detector that's a good one good one jack okay so here's a little special sauce i'll give you when it comes to being that great product manager being that great platform engineer being that platformers product person i want you to think about this basic thing focus on the story and i'll tell you a secret for those folks who are still with me and didn't get bored at this point in time the story is so important and it has to do with this very simple thing a human cannot protect themselves from a great story your program since birth to receive great stories let's let's talk about the first second i learned about this by the way with a lady named nancy duarte she wrote several books i learned about nancy duarte because at redhat we once paid her a hundred thousand dollars to consult with us to teach us this basic principle i didn't learn she wrote it all down in books which i didn't ask people hey let's just go read the books so that's what we've done she got this basic idea of the hero's journey which was identified by joseph cambell and his book and these links are all here very important you can actually then go find the uh the george lucas link there is actually where george lucas the guy who invented star wars thanks joseph cambell for the invention of his book because there would be no star wars without joseph cambell so the idea of the hero's journey is a powerful concept is programmed in all of us at a dna level you as a human when you watch and hear these stories cannot protect yourself from them all right so it's important to understand a basic thing here when we are the platform team we are the product management team we're the developer advocate whatever we are we're not the hero of the story we are the mentor all right so let's kind of dive into that a little bit so one thing when i interview people and i've often used this before some people here in the chat might also remember this i ask people do you love lord of the rings or do you love star wars or which one which story do you know better did you did you watch lord of the rings did you watch star wars and people will pick one or the other there's always the occasional person like i hate all fantasy and sci-fi i don't do any books okay for for those people do no books and no movies i don't know what to do with you there's gotta be something else that you like like knitting or something but the idea here is pretty straightforward are you luke or obi-wan kanobi are you luke or are you yoda and this is an important understanding of the role if we're building a platform if we're the product management team we're the platform engineering team we're the platform as product team we're yoda we're not luke okay that's an important idea as a matter of fact we're not frodo we're gandalf frodo has to carry the one ring to mordor okay and put it in the volcano and destroy it to save the world gandalf provides mentorship tools and ideas and education and encouragement just like obi-wan kanobi did just like yoda does so that's an important element you know and star trek doesn't have as much of this idea right so dj maddie there star trek doesn't have as much of this idea doesn't tell this kind of cohesive story though i bet it's in there someplace i have to go find it uh if i at some point there's some other examples in the slide deck you can have access to like rocky and karate kid so how do you understand those developers those those uh luke skywalkers those yoda sorry those um those uh frodo like people how do you basically think about them well they are creators they are the people who can do this magical thing by putting their fingers on a keyboard typing in what looks like arcane gibberish to the rest of the world like just this weird sing you know sometimes english with curly braces and semicolons or weird spaces if it's python right or maybe it's capitalized or not capitalized no one even knows what the heck we're typing but that ability to put fingers on a keyboard and type out stuff and make it run is the magical superpower we're talking about here and the way we think of it when we are developers you're thinking i made this thing i created this thing my favorite is i bent it to my will i made that damn thing work it didn't work at all but that script that bashell script that i wrote works now it does what it's supposed to do my answer will play book does what it's supposed to do it doesn't matter what the technology is if it's a playbook if it's a bashell script or a piece of java or go code it's the same idea it didn't exist in this world i typed it in with my my fingers and magic is now happening and even when i go out and talk to children about these basic concepts i talk about being the producer not the player the creator not the consumer because think about the little kids you know these days they're all playing on their tablets and smartphones you give them when they're two years old they're playing you know whatever the current game is fortnite etc and i talk about being the maker be the builder because that's the magic is when we can do that sort of thing all right so your ultimate goal is to empower energize educate and enable you got to figure out how to make those creators excited you might offer something like this which is a dev rel way of thinking of the world what is the developer advocate to they want to make sure that those people those developers that you're working with can get on board easily they have a golden path they have newsletters and getting started they have video tutorials they have an faq whatever it is you're making sure they are ready and i'll just show you this one little thing real quick and that is we have a a let's go here i'm going to actually give you this url so this is our online little example of a portal okay and you can see right here so let's i'll put that there so this is backstage as a portal and this is janice this is specifically our version of it and you can see i can basically come in here and say i want a template for a new ansible job or i want to use i want to create a dotnet front end application with ci i want to know js with ci the idea is that you offer these templates to your developers so they can get started easily remember i talked about that developer and that wait time how long are they waiting before they can be productive how long are they basically sitting there on their hands waiting for a virtual machine or trying to figure out how many days or weeks it takes to making their first pull request with code that matters with this sort of tool the portal allows them to basically find all the documentation figure out what they need to know get started rapidly that is the magic of the portal and that sits atop the stack that we talked about earlier so this is what people are all excited about this concept of golden path templates of course there's things like docs and apis and other aspects okay so let's that's just a quick little thing there are other things that i could show you when we talk about securing the software supply chain that includes the runtime side of it with things like acs which is now available to cloud service or maybe you're interested in our new red hat trusted application pipeline i'll give you that url also if you hit me up on slack we can get you approved and into that system but that is a brand new software as a service we have out there today and of course you can do some really fun things with it like run things through a salsa compliant pipeline uh and of course there's a lot of things a lot of capabilities there all right i know we're nearly out of time here so let's kind of wrap things up okay so let's remember a bunch of key things we talked about today in a very short period of time hopefully it was kind of fun but i want you thinking about focusing on that team focusing on all those folks that are involved in the creation of software because it is a team effort we need the developer who can do the magical typing thing we need a security and compliance officer who's going to make sure that we build things that are more secure more compliant and actually adhere to all the rules of the industry whether that be cis kubernetes cis docker pc i dcs right think about all those compliance requirements we have today in a big enterprise they are critical they are important and most importantly they should be shifted left and automated we've got to think about our ops team whomever is responsible for qa project management peos right product owners everybody's involved with this and by the way my dba there even though they look like a zombie it's because they love the walking dead it has nothing to do with the fact that i think they are the walking dead they love the walking dead so i like to basically make the point we are all geeks together and you can take these geeks to lunch you should and spend some more time with them all right so it's all about continuous improvement here is a list of phenomenal books that i'd recommend these are all fantastic books and so marty kegan inspired for how to be a product manager along with trisa torres and continuous discovery habits of course everyone should have read accelerate devops handbook investments unlimited the phoenix project lean startup so if you have to go back in time and i wouldn't recommend that so like going all the way back to crossing the chasm though that's a pretty interesting one but if you want to just go back about 10 15 years check out lean startup check out the phoenix project there's also the scrum book is fantastic i went through the scrum book again recently and i just realized how great it is but all these books will help you better understand what it means to build better software within your organization and help you achieve your goals your outcomes uh with your dev teams your product teams your platform teams and that is the end of my story and i finished up just in the nick of time i believe let's see if there are any specific questions we think i first of all i need to do something that we usually don't get to do in these kind of virtual settings man that was awesome i really enjoy your presentations and speaking of all the chat comments everybody else did too so you delivered as usual um last call for questions folks uh anybody you want to like jump in here if not um burr do you still code like i know that what you've been doing the last couple of months but uh do you still go these days i primarily write documentation on what coders want use cases and diagrams but i still will write a little bit of code and i still have a lot of fun writing some bash shell scripts as an example too because you got to automate all these kubernetes things so just a little java code a little bit of javascript code is the world i try to uh be close to wonderful perfect um i i can only extend what everybody said in the chat so thank you so much for your amazing presentations all the amazing work you're actually doing um everybody else go check out all the links and all the books and all the free downloads especially on developers.redhead.com um our next sessions will probably start around let me take a look 10 30 a eastern time which is like 4 30 p uh central european summertime and uh i did take a look through the stages that we have so like you can go and pick your your stage but if you want to have a couple of recommendations so one is definitely a must which is the hitchhiker's guide to application connectivity by marc so you can't let that slip um and just because i'm highlighting a couple this is because these people bribed me um so just to let you know right so another one is quacas for spring developers so if you really want to go deep into quacas make sure to go to the java and app modernization stage and listen to eric um whom else did i find here oh yeah we also have something about fuse eight so if you're interested in like more specific topics uh also available to you and we'll have a ton of stuff around modernization coming up including a lot of open chats and breaks so check out all stages and make sure to enjoy the rest of your day er thanks again so much thanks everybody for being here and see you in a next session yes thank you so much you guys have a great day