 Hello everyone and welcome to from Kubernetes to PaaS to developer control planes. My name is Daniel Bryant I'm the director of DevRel at Ambassador Labs, and you can find me on most of the interwebs at Daniel Bryant UK Now I'm going to discuss over the next 20 minutes these high level key points I believe as a cloud native community as a dev x days community We need to focus more on treating our platforms that we deploy applications onto as a product I'm going to argue we should realize that you can't have good dev x without good UX and when I say good UX I mean proper UX not just like back-end engineer UX that I typically do proper UX And we need to focus on the workflows and the tooling interoperability And this is where this notion of developer control planes will come into the focus more clearly Now we're being told Increasingly to shift left as developers right now This is not a new thing. I started my career from a Java development JavaScript development back in 2001 2002 time frame and we were being asked then to think about the illities early on in the process We used to call them non-functional requirements. Not a great name, right? Really it's cross functional requirements It's things like reliability scalability security all this good stuff, right? The challenge was back then there wasn't great abstractions. There wasn't great API's There wasn't great tooling to help us and this led to Fragmentation, you know devs doing this this thing ops doing just this thing In Vosek doing just this thing and it kind of meant for a lot of handoffs and a lot of muddles All the good stuff you've heard in books like Accelerate dev ops handbook. These are real challenges back in the day, right? Now I think we've got a lot more options, you know massive hat to appear to the CNCF There's lots of projects out there now The only challenge we've almost gone the other way in that tool sprawl is an issue for shifting left We all know the value of thinking about security early, but there's lots of different tools We all know the value of thinking about deployability reliability early But again, there's lots of tools and it's easy to poke fun right at the CNCF landscape We all like to do a cheap shot a coupon, right? Let's be honest though This is a sign of a healthy community Lots of divergence lots of innovation going on it does mean it's challenging for us to pick which tools are going You know are going to be useful to us, but it's still a sign of a healthy community The only slight snag with you know, kubikons and I am missing not being there in person in kubikon Hopefully soon right but each kubikon doesn't help with this tool sprawl and CEO of ambassador labs Richard And I was a regularly jerk on this kind of thing that every kubikon brings innovation brings conversations brings discussions Brings more tools and tools are somewhat like tribbles in the Star Trek, you know for a universe, right? So let's take a step back for a moment Look at my career and the control planes I was used to using as a developer How my cognitive load varied over times and how difficult I found the job basically I think this relates very much to the developer experience that I had available to me at the time So looking back at my dev career and apologies for a bit of a data dump table This is the best way I could find to animate it but very briefly I'll step through in the early 2000s I was working on Java monoliths Deploying in-house actually for the UK government when I was working there for a bit and I just thought about coding, right? 2005 time I was doing more enterprising kind of development a classic sewer service oriented architecture Moved into racket and stacking some of the tin There's even cloud emerging around this time, right Amazon with AWS with SQS and S3 were popping up on the scene and I was excited by this I started learning more and only that coding but at shipping and even limited degrees of running applications How to pixie boot service how to use chef to deploy, you know Java the JVM on the machines And I don't 2010 time. I actually went into a bunch of work in Ruby and rails Heroku doing some Java work on cloud foundry and this was a very different experience proper You know classic platform as a service my life as a developer was super easy, right? It was literally CF create route or you know get push to Heroku and that was all I had to think about You know, maybe I looked in a new relic dashboard to do a bit of observability Maybe you look at the logs if something was going wrong, but as a developer I didn't think too much about the CI CD aspect of what I was doing Marcus's services came along right 2012ish time pick pick a date and but then New options were available to us modularizing our architecture designing for a place ability Docker popped up kubernetes popped up suddenly as a developer, you know, I was working as a consultant in London There was suddenly a lot of things to learn as a full stack engineer Everything from new languages all the way through to databases to queues and distributed logs to terraform To chef to pop it, you know, there's a lot of things to learn as a developer and in 2020 Now we sort of come full circle, you know, micro services plus plus We're looking for that Paz like experience once again kubernetes is the foundation But maybe we're missing that sort of top layer to make it easier for developers to provide that good developer experience Right, and again, I think a lot of engineers now would recognize themselves as full life cycle developers We'll cover that bit more in a minute, but you're responsible for you know Taking the business ideas coding them shipping them and running them as well You know, you build it you run it Verde Virgals famously said I see this in many organizations We work with ambassador apps Now if I'm going to map on my cognitive load Over the years of developer. It's an interesting graph. I think right you can see in my early years You know, I was obviously learning a lot fresh out of college fresh out of university, but it was pretty happy Right, I've created my Java app packaged it in a jar or a war artifact Put it into a portal or handed it off to ops and you know stuff happened right happy days As I got into more so I was spinning up tin I was racking and stacking but even if I didn't want to go that deep in the infra I kind of enjoyed it, but even if I didn't want to go that deep I was still having to think about things like application service enterprise service buses more kind of infrastructure You kind of components and I was like, you know, this is kind of a lot more complicated, right? Go into the world of Heroku and Clyde foundry was a breath of fresh air Right, you know so much simpler as a developer focus more my code more on you know When things are going wrong in production having to look around the logs and things I really enjoy using these passes Now obviously applications user demands got more complicated more complex This is when I think you know the cognitive load to shop for the roof granted I didn't have to learn all the tools, but the consultancy I was working with at the time is a fantastic team Open credo. I'll shout them out. We were deliberately going in helping folks embrace new technologies So we're having to learn all these new things, but yeah again as a full stack developer The DevX was not there the developer experience is not there. I was constantly context switching between all the different tools So what did I learn through my time, you know my 20 year journey in IT? Treating platform as a product is key. Now. I saw this obviously in Heroku I saw this in cloud foundry the folks behind those platforms clearly invested in things like UX Product management project management all this good stuff and even companies. I worked at my shout out Not on the high street UK online marketplace myself and Nick Jackson the ones rather awesome folks worked there and built a platform on Maysos at the time We really thought about our platform as a product and it really showed in terms of Adoption and user experience. It wasn't perfect, but it was a lot better than other places I've worked where the platform was an afterthought or it was just ops Responsible for it and developers had to put up with what we were given. I Also learned you can't have good DevX without good UX I mean Twitter bootstrap was a miracle at time right me as a back-end engineer and Twitter bootstrap came on as a UX tool as a CSS collection on JavaScript and things made my life designing UI is much easier, but still I was a back-end developer Right. I wasn't a good user experience developer I worked as an amazing UX folks and I really dialed into the value of UX and again We're treating the platform like a product good DevX requires good UX And I learned to focus on the workflows and I think hashy core to be honest like Michelin I'm on the whole team been very lucky to see their journey right from day zero pretty much They really taught me this you know when I first bumped into Terraform as an example I was a bit confused. You have different stanzas different conflicts for different clouds Where's the value? But I soon learned the magic was in the workflow the Terraform plan the Terraform apply The general modular structure that emerged over the time that a consistent workflow is the key here There's only a little bit extra cognitive load to learn the different conflicts Now tooling interoperability was really key to I saw this in my Java days You know things that worked well in mice in my world that plugged into my IDEs And we're of course seeing this with VS code these days, right? This tooling interop is a really key thing for reducing the friction for developers There's always a Kelsey Hightower tweet for any occasion in Kubernetes, right? And because he's awesome basically and this tweet I thought was perfectly relating to what we're just discussing now And this is you know, it's a couple of years old this tweet now But Kelsey was saying the delta between Kubernetes and a developer friendly pass is where the next layer of value is and where things They tend to get opinionated a require a requirement for reliable end-to-end workflows And I think we still even though this is like a 2019 tweet We still haven't really got that developer friendly pass yet Some folks are clearly on the path trying both internally and as a product But I think this tweet captures what I'm trying to say today like thinking about platforms as products as passes that we all want So let's look at the three things I mentioned platform as a product now Learned a lot from Dave studio videos. Dave's awesome. He's done various CTO roles He's key noted at KubeCon in the past and I know there's a lot of text on this slide But I'll just paraphrase by saying I had some great chats with Dave at previous KubeCons And he came up to the ambassador labs booth one time and said, oh, you know fantastic talk by Pinterest They were using the spinnaker tool and they created a wrapper around spinnaker to make it easy for their engineers to deploy code And then he said, you know, they had a UX designer. They had project managers they had back-end people front-end folks and poor Dave at the time I had a couple of engineers to run a platform in his company and Dave and his team were doing a great job But they were simply limited by the resources they had, right and it really made me think, you know With the limited resources Dave had he focused on centralizing processes Building in more standardized and opinionated ways of doing things to reduce friction and improve DevX I thought that's awesome, right proper lean startup approach limited resources But thinking about standardization opinions and trying to decentralize some of these efforts to The go-to book in my mind in this space is team topologies. I'm very lucky to know Matthew Manuel I've worked with them on various projects in the past. They are legit folks. This book is, you know, it's not a massive book It's quite a very readable book, but it is the best resource I think for thinking about how to build teams to offer platforms as a service Not necessarily paths but platforms as a service within your organizations Whether they're big or small and it gives you lots of great jumping off points to understand how to treat Platforms as products as services and how to actually manage those as well I always say start small get big, right? And I've definitely worked on a few projects kind of as a consultant We're brought in to try and save the projects and these are platform projects in big companies I won't share any names But we'd often join the project and I'd realized there's been no iteration The platform folks building the platform would not even talk to the developers. Oh chaos ensues, right? So this book is a great reference for how to start small iterate learn get big Can't recommend it enough if you're you know wanting to understand the use cases developers have in your organization to help craft the platform that you should build Just almost great timing, right Nikki. I've learned a lot from Nikki over the years. Nikki writes and FT comm sky scanner recently and she was saying as she quote tweeted a really interesting thread about building platforms And then she was arguing and I strongly believe that companies need to invest heavily in platforms and the platforms need to be staffed Properly treat as products, right? And I get a folks like Nikki and get a little here are talking about this Dave other folks, right? There's smart people talking about interesting things. I'm always interested in I think treating platforms as products is really really key Staffing them accordingly setting goals iterating accordingly Point number two you can't have good dev ex without good UX, right? Now shout out to the Argo project I've been lucky enough to play around with Argo for a couple of years now Argo is growing all the time as many things But in particular Argo CD is a fantastic UI for understanding your current deployment state in Kubernetes And embracing GitOps to deploy things, you know defining git Reconciled into Kubernetes. I've been lucky enough to chat to many of the Intuit folks the black rock folks the red hat folks behind Argo did a great podcast with Alex M on the Argo project So put the links down there you can check out and Alex really helped me understand about the value of the UI of Argo You know almost put aside the GitOps Benefits put aside some of these other benefits that he said the UI is really useful and big enterprises for helping them build Their mental model of of how deployments work. What is a node? What's deployed where when we're doing canaries rolling upgrades? What's going on? It's a great tool to help developers build their mental model and that is key in dev ex Following on from this, you know, not just you I write the CLI of Argo rollouts is fantastic I constantly uses my demos, right? It's like a watch command as the canaries are going out You see new pods spinning up You see traffic being rerouted and you see pods being spun down when the canary successful and the UX of it It's just fantastic, right? It's a CLI tool, but it's fantastic People have clearly put time and energy and iterated on this user experience. It's great developer experience So good UX for platforms. I bumped into this book quite a few years ago now It's a great read. It's a chunky read in some ways, but it talked about Affordances personas a bunch of things. I've really used I've helped teams build platforms now The classic or Steve Krug don't make me think us. We still discuss it in ambassador labs quite a bit It's a great book again for thinking about personas and many of the good UX things that perhaps we as back engineers back end engineers Don't always think about So do think personas User research is key can't reiterate that one enough too many times the consultant brought into save a platform build and then You know students ask the question like what do your developers actually want from the platform? And if the lead engineer on the platform team said, oh, we haven't talked with the developers or we're going to give them what they need I was like, oh, this project's probably doomed if you're not listening to your customers your users You're never going to deliver value for them. It'll simply get sidelined or people will work around it and Do what's your users in their daily tasks using your tools? constant surprises ambassador labs people you know going through and using our tools in ways We never thought possible and things that we thought were simple and obvious and not to them and vice versa So actually watching people jumping on a zoom in our case and you know asking folks to step through quick starts and tutorials Look at telepresence. Look at emissary ingress. We learn so much from doing that and we're humbled all the time, right? So I thoroughly, you know encourage you to think about developer experience by actually watching some developers experience your tools Workflows and interops. So this is an interesting one, right? I've learned a lot from the Netflix folks over the last sort of few years on this and yep I know we're not all Netflix, right, but they're often at the vanguard. They're often leading the way I like to look at what they're doing sort of in a few years time The rest of us might be following suit, right and they talk a lot about this full life cycle Developer notion not every developer at Netflix is full life cycle But a lot of them are and they own the idea all the way through to code delivery and production and there's clear workflow steps There's clear interoperability between their tools and nice separation of concerns on the different steps And I they've really put a lot of energy into thinking and iterating on this Workflow and how the tools are pluggable and how the tools interoperate very successfully other great blog posts there by Gallo Navarro here fantastic write-up of building a pass for 1500 engineers similar kind of such discussions, right? It's always about trade-offs. You've got to balance that DevX with you know Flexibility of platform governance security these kind of things But it's a great discussion of thinking about all these trade-offs. We as platform engineers we as developers, right? We want to think about when we're building and using platforms And I've got a quote SVP of engineering at Ambassador Labs I had some great chats at Bjorn over the years and we did a podcast recently and he pulled out this really key Thinking point for me. You know, he's seen many things in his time at New Relic and vision He's been working in the industry for many years lots of great experience running teams of all sizes remote on-prem these things as well And he was saying the industry is going through waves of expansion and waves of consolidation It wasn't certainly sure where we're at and in the cloud native space at the moment But he did say in times of consolidation You end up with products that integrate with lots and lots of tools Specifically the tools you use and that made me think back to my Java days where we had World-defined workflows tools that interoperated tools that we could swap out because there was common standards in this space, right? And I was like, I think you're on something Bjorn This could be where a lot of innovation is going on within the CNCF within the cloud native space at the moment Right with standards emerging, you know custom resources and various sort of interop standards like cloud events as a kind of Standard way of defining events in a cloud native system So where are we now? Well, it's interesting, right? I'm totally standing on the shoulders of giants in this presentation I've been lucky enough to chat to Cheryl Hung, Mario Loria, Casper Nissen Just to mention a few folks here and there's a few key themes I wanted to pull out that they all seem to mention now Cheryl kind of in looking at the developer experience of cloud native She talked a lot about the value of having service catalogs Having a good UI and she mentioned Spotify's backstage, which we've got many of us heard of I'm sure Mario talked about Enabling self-service for developers being opinionated But you know allowing them to break out if necessary, but that self-service is key And Casper talked about things Thinking around the mechanics the workflow kubernetes is almost a given he was saying it's the next layer up of Managing promotion of code through environments Implementing githops in a way that developers can understand and manage these kind of things So I put links there all the all these links go into the podcasts more details. I've learned a bunch from these folks So thank you very much to them to help build my knowledge key insights Successful organizations are investing in platforms and platform teams YAML pretty much the lingua franca of cloud config Although I think we're seeing more and more auto generation for YAML now Something we're looking into a lot of ambassador labs because YAML's rather verbose to keep constantly writing yourself, right? I'm going to say a good UI paints a thousand CLIs You know, I'm not saying don't show the CLI any love, right? I'm a big CLI user But particularly in large enterprise context a really good user experience a really good portal dashboard service catalog Takes you a long way in terms of developer experience. Some folks are just simply happier in a UI Githops is sort of becoming I think the protocol the standard workflow best practice for deployment the reconciliation mode Massive hacktip, of course to the weave works folks for all the great work They're doing cornelia davis has done some great presentations talking about this reconciled loop That you know is in Kubernetes and that githops builds on and so this I think is key to a lot of future devx This notion of githops for deployment And lastly, you know adopting the kubernetes resource model enables interop using things like custom resources Defining your own custom resources and treating the entities within kubernetes as they should be used Just the other day jason morgan from boy in tonight. We're doing a demo of integrating two cncf projects link d and msre ingress and because both the projects treated all the kubernetes entities as you think they would like msre ingress writes the services link d augments services It was literally a one-line piece of config to get the tools working well together Whereas in the past there's been you know when we've used different service meshes or different ingresses There's been a lot more config needed to work around different ways things were using kubernetes or or not using kubernetes as the case I'm not saying that's necessarily bad, but it wasn't a great developer experience when you had to kind of do all these patches and Worker work work arounds. It's sometimes provided more flexibility But it's always a trade-off right good developer experience easy integration versus that more power So this I think in some ways the role of the developer control plane right I talked about coding shipping running I think you know we ops have had their control planes for a long time I think it's now time where we need this developer control plane probably a thin ui on top service catalog that kind of thing Some kind of protocol mechanism. I talked about githops being that I think git is pretty much like being accepted as the single source of truth now Regardless of whether we're in the coding stage the shipping stage or the run stage, right? You think code is obvious in git ship, you know, you're in your rgo cd your rgo rollouts all in config in git and even run defining mappings to your back end services via ingress or service mesh That's all crd's right. That's called code config stored in git Triggered through with githops to actually being deployed So I think this developer control plane is a powerful concept It's similar to things like you know open application model are probably worth exploring or definitely worth exploring too If you sort of squint, there's a little bit of developer control plane here I think many of us are converging to this kind of model if you like of how developers should interact with platforms So wrapping up What's next for platforms? I think we as you know devx days community as a cloud native community Really need to think about treating platforms as a product This is exactly what I said at the start, but if you resource them set the goals accordingly iterate on them Platforms this built this way provide so much more value Minimize the friction provide better developer experience And you do have to realize that you can't have good developer experience without good user experience, right good ux I learned that the hard way, you know, don't learn from my mistakes. Don't follow my mistakes Invest in getting expert opinion on user experience engage with your target users your your keepers owners And I think focus on the workflows and the tooling interoperability This is where like, you know, lots of interesting thinking around developer control planes at the moment How things interop this I think is going to be an air of active research active products and consolidation of things over the next few few years I'll say thank you at that point. You can find me on the interwebs here email twitter Also on the ambassador lab slack. You can find the references to the podcast I mentioned down below and of course I've got to mention we're hiring right if you'd like what you've seen today Please come and join me. Thanks a lot