PlatformCon 2023 Preview – Brian Douglas, Open Sauced, Jay Pathak, Razorpay, & Susa Tünker, Humanitec

This Is techstrong tv. Hi everybody. Welcome to this really special event.

We're talking about Platform Con, what is happening, what's hot in platform engineering. And, uh, we have some very special folks here, uh, talking about the conference in the event Platform Con is happening on June 8th and ninth. com/register, uh, to register for the e event, find out more information, check out the agenda, all the great things that's gonna be part of that.

My name is Mitch Ashley, I'm CTO o with Techstrong Group, the folks that are helping put on this video. And, uh, we're gonna be kind of doing a little bit of a warmup event here. Uh, and we're talking about some of the topics that are happening, uh, at the conference, some things that we're excited about, talking about, um, maybe wanna learn more about, you know, we're bringing our own expertise and experiences, uh, but we're also coming to Platform Con to, to learn from other people too.

Uh, so we're, we have a great panel together. Um, I'm going to ask each of the folks to introduce ourselves themselves, and then I'll, we'll talk a little bit about what, what do we mean by platform engineering, if that's a relatively new topic, and we'll kind of dive into it from there. So, great.

Um, I'm happy to have our panelists introduce themselves. Uh, SUSE, why don't you introduce yourself first? Yeah, I'm happy to, um, nice to meet you guys.

I'm, I'm happy to be here. Uh, so yeah, my name is Suza. I'm a product manager at Home Tech.

Um, among other things, I'm involved with the developer experience aspect, so essentially trying to get to the bottom of pain points and bottlenecks that developers face in their day-to-day work. And of course, also as part of that, exploring ways of reducing friction, um, along the application delivery lifecycle. Um, so that's my main focus at the moment.

Fantastic developer experience. What a great, what a great topic, title, et cetera. So, very cool.

Good to be talking with you. Hey, Brian, how about yourself? Would you, uh, introduce yourself?

Yeah. Yeah. So, Brian Douglas, uh, on the internet, I go by B Dougie on places like GitHub and, and Twitter.

And, uh, most recently spent five years working at GitHub, um, helping with their developer experience and develop relations as well. And then, uh, back in September, started running my own company, uh, called Open Source, which we're providing business intelligence and the open source software. And, um, yeah, my talk is actually around this getting to release as fast as possible.

So C I C D has had a lot of evolution in the last few years, and I've come to become a consumer of all this evolution and, uh, mostly a front end JavaScript developer, but when I need to choose a platform to help get releases cut, um, always looking to, to the word knowledge, but also share, uh, my experience, which is, I wouldn't say expertise, I just happened to be a great, a great consumer. It's nice when you're speaking from practical experience as well as knowledge, right? Yeah.

Which I think all us bring to the table. Very cool. All right, Jay, last but not least, introduce yourself, please.

Yeah, sure, sure. Yeah. Thanks for having Maich.

Uh, I'm Jay. Uh, I'm from India, currently working as a software engineer at, uh, we cater, uh, as one of the largest payment gateway, the leading women gateway in India. I work for the platform team and, uh, basically what we do here is to manage the API gateway for, uh, we have our own, uh, sort of a custom customized API gateway on which we do, uh, our tooling on.

Uh, and my talk, uh, for platform is based on similar topic, like how we are managing, uh, the edge at Razor. So really excited to be here. Uh, eager to learn from all of you.

Thanks. Fantastic. Uh, Susan, I don't know if you mentioned what your talk was about, did you?

So I didn't, I didn't actually. Um, my talk is about configuration drift and how to eliminate it, um, so that it's kind of the problem space I'm diving into. And as part of that, I'm also touching on score, uh, which is an open source project that, uh, aims to eliminate that exact problem Configuration drift, who has not had that problem.

Okay. Exactly. Exactly.

Well, you know, um, so platform engineering, maybe it's a relatively new term, uh, to folks. It's something, you know, we've talked, been talked a lot more about in the last, you know, couple of years. Uh, Gartner kind of defines it as this idea of, you know, I set a tools, capabilities process, is that really helps.

I, I think of it as developer productivity and kind of reduce, um, get back to the, the core of how do we support our developers and their productivity and the technologies that they use, cuz things like DevOps and cloud and everything. We have a lot of people involved in our software processes now. And, uh, platform engineering kind of brings that, that, uh, that focus there.

Um, the first platform con, I guess happened in 2022, June. And, uh, you know, uh, we were, at the time we were thinking about, uh, puppet the field, c t o, uh, Kirsten kind of guy, the community urged them to come up with sort of a descriptive model of what platform engineering, uh, really entails. And I'm, I'm curious about your thoughts on platform engineering definition.

It's like everything, there's multiple definitions, right? There's rarely one definition to rule them all. Um, but, um, how, how would you put some terms around it?

We'll kind of use it as our working definition. Do you want, do you want to jump in first, Jay? Sure thing.

Yeah. Uh, but I, on, on, on to begin with, like, I totally agree with you, right? Like, there is no definitive sort of description around if we can define platform engineering into one or two sentences, right?

It varies on the use case that we have, uh, on, on day-to-day basis, right? Uh, I would like to just quickly give an example. Let's say there can be emerging startups or companies, right?

Uh, where they have simple sort of their and structure defined, and, uh, they have, uh, fairly using any sort of product for the tooling. Uh, on the other hand, there are large organizations having, uh, you know, like fairly large size of developers. Uh, at the end, uh, according to me, what I would see platform engineering working for both of these cases would be like to create a set of reusable tools or let's say services and infrastructure, uh, which at the end of the day help developers to build and deploy applications more quickly and efficiently.

That is what, according to me, platform engineering ma majorly lies about. And that is what, uh, we also try to utilize work and cater for the teams that vote here is, Makes a lot of sense to me. Good perspective to take two.

How about, uh, how about you, Susan? Yeah, I mean, I would totally agree with that. It's, um, similar to other terms like DevOps, for example, right?

Like if you Google it, there's just, uh, so many, uh, definitions and articles you can read into. Um, in terms of the, the definition that I usually go by, I'm of course also a little bit biased, uh, coming from hok. Um, we typically describe it as kind of the, the discipline of designing and building internal developer platforms.

So that, uh, contains tool chains or workflows that essentially enable self-service, uh, for software engineering organizations and specifically also developers, uh, which is quite a, like, high level, um, definition. But as you mentioned, uh, Jay, like, once you dive deeper, it's like kind of dependent on the use case. So I feel like to get a basic understanding, it is quite helpful to, to keep it as high level.

Yeah. And Mitch, if I could jump in too, I imagine you're probably gonna go to me next. Yeah.

You, You read the room, right? Yeah. Um, so I mean, I've professionally been coding for about nine, almost 10 years.

Uh, I've been copying and pasting code for longer than that, but, um, always been able to solve a problem in code. Uh, and when I started working professionally, I didn't know, you know, all these pipelines and servers and how to orchestrate that. And I've, my career's benefited from platforms and like using tools where I could just focus on like writing the Ruby JavaScript pipeline code.

I need to get the job done and not worry about how to orchestrate an entire platform. So like, uh, we've all touched on this and you'd mentioned, you know, getting us back to, as developers, get developers back to doing what they do best, uh, is how I'd, I would describe this. It's interesting, uh, just my own mental model of this is kinda remember thinking of the world as the IDE and all the plugins and everything that I can access through my id, whatever your favorite, favorite or favorites are, right?

In the languages that you're using in today's world, that plugs into a whole tool chain workflow platforms that we're, we're doing development on maybe different deployment environments. We're doing this in the cloud, doing it on our computer. Um, you know, we're multiple things, right?

And we have, uh, you know, requirements, documents and GitHubs that help set up our environment. Poof, we're ready to work and go. It, it's, it's really amazing to me how more productive we can be to bit today with the tools and capabilities we have.

But it also can be really daunting if you're like, stepping in and that, and that's not just set up for you to go, I mean, is that, is that anybody else have that experience too? Jump in? Yeah, it was the same for me.

I mean, shortly after my studies, I worked, uh, as a JavaScript developer as well, and our team, we had more of the issue of like classic siloing. So I had absolutely no clue what was going on, um, when it came to actually deploying my code. Mm-hmm.

Not great either. So I feel like bridging the gap there and like making that part accessible, so in terms that I can like self-serve as and understand what's going on, because when something broke, uh, back then I was absolutely lost. So, um, I mean, we know that siloing is also not the way to go in terms of just throwing code over the wall, um, but kind of like passing it through the fence, uh, is I think what, what platform engineering is, uh, aiming to do.

Yeah, I was gonna say that I, I, I've, I've got a lot of friends who went to school in, in Canada, and when you're an engineering Canada, you get the sort of special ring and like a lot of folks already know about the, the story about engineering in Canada and the bridge that fell down, but like that symbolism of the ring, which is like a part of that bridge that fell down, it's like to remember, oh yeah, this is why we do this today. Like, we don't have to understand how bridges work or how pipelines work or how servers work, but this note that someone solved this before you, and that's, that's the, that's what I see as far as like, again, going back to my story, uh, I just want to ship code some code that I know is gonna work. I don't know how it gets to the cloud or how the cloud works, uh, but I do know that there's a platform I can that's gonna be supporting me, like from, it's supporting me, but also the next engineer and the junior engineer team, they're gonna figure this out without need to know every si single intonation of how this works.

Yeah, I mean, uh, we agree with Ryan on some points, but, uh, there's one point where I would like to back to defer is like, uh, even though there is lot of tooling available, or let's say we have a use case, we Google it out or we check out like what are the tools available for the same, uh, not doing the internals might can backfire on the problems itself. Let's say, uh, previously while I was working at a different firm, we had two euro sort of an on-prem deployment. That strategy I cannot utilize sort of utilize on the setup that we have now.

So Verizon, as I've said earlier, it Verizon use case to use, know, not at least the entire of internal structure of the tooling that is available. But, uh, you know, like, uh, if we have the gist of what needs to be used, Ben should be really helpful with the, uh, with the, uh, products that are available right now in the market market, mark. And I would say that we're, we might be saying the same thing too as well.

Like, I, I think when there's a team and a structure, like definitely no, I in team, but there's like a, there's definitely a, there's a me, but there's, there's us. And like if there's someone on the team that does be, that can transfer that knowledge through documentation, uh, and like really good guides, then we could all now solve harder problems. Uh, and that's like, that's more of my, my statement is like, I, I agree, you should know what you're using, um, but we should also like document and be able to move forward and solve, I guess, whatever comes out.

Ai. Mm-hmm. Well, you know what the, the, the concept of flow comes to mind too, right?

It's keeping ourselves in the groove. I mean, it takes a, it, it takes a lot of work to context shift to get ourselves that cognitive load of getting back into the head space of what we were working on. And, you know, we're maybe in halfway through understanding it or writing it or whatever.

And those disruptions to that, I mean, they have a big impact. And people who are not writing software don't always appreciate it. They may have their own challenges that way, but you know, at, at least for me, you, you really dive into it, you know, mentally, and you gotta have your head in there.

So in a way, platform engineering is increasing flow, helping people do what they do well, spending their mental cycles working on those things. And then, and probably along with that, this is something I think you mentioned, Brian, is, is we're software people. So we, we also write things to make things better for ourselves, right?

Which is part of, you know, our own world and, and platform engineering seems to be, encompasses providing that environment, um, as well as helping us improve it, improve it over time. I, I, what do, what do you think of as, as tools? I mean, there are literally thousands of people that will be part of, um, platform Con again this year will be part of the livestream.

And kinda like, you know, in the DevOps world or s r e world or platform engineering, there's no one tool that says, this is, if you got this and plug this into your id, you got platform engineering. But how would you put some ideas around what assign some of the capabilities that you can use through tools, open source, commercial, cloud, others? Uh, you want to start first, Brian?

Yeah, I mean, so my, my talk is it's focused around, it's not meant to be a product talk. I just happen to have a lot of experience in GitHub actions. Um, and I see that tool as like a base layer.

Like it's, it's a, a great way to get started. Uh, but it's like not the end all. Like there's now a lot of good evolutions of C I C D where like continuous integrations, it's a bit commoditized now.

So, um, I'm seeing tools like Dagger, which gives you a better local environment to test your, your ci cd pipeline if you choose to use GI of actions or Jenkins or anything else. And that flexibility, uh, to be able to say, okay, well, it works on my machine, but also works on this cloud and it works on this server. And like, you could repeat that experience, um, is again, like it's, I still, I hark on this one, this one notion of like, I remember two jobs ago, I, I sat down and someone showed me what Docker was, and they showed me how that touches Kubernetes and that this is how we get stuff deployed.

And it was just the intro first day on the job, and I never had to look at it again. I just knew it worked. Um, and that's what I love about like this figure out this sort of base layer tool so that way we can go reach for a dagger.

There's a new tool called Cicada, similar to Dagger, you can write rust or whatever language you want, and it converts in the web assembly to build out your, your, uh, your pipeline, uh, yourself. So that way the next person doesn't have to worry about all the ins and outs, Web assembly, a whole, a very cool thing about, um, you know, runtime environment. Okay.

Come speaking of your Java background, right? Sort of the next evolution of maybe that idea for distributor environments. Jay, jump in.

I'm be curious your, when you think of kind of tools and the things involved in, in a platform engineering environment, what comes to mind? Yeah, So first thing that comes to mind is definitely something, you know, like that enhances developer productivity, right? Uh, with, with, with the increase in the number of developers across organizations working on different microservices, right?

As we, uh, look at the architecture systems, right? Uh, every developer has its own set of requirement needs a different, uh, deployment architecture or something like that. Uh, so the tooling around neural kit podd or, or something like that where we can have our own micro set up or micro capability set up that is just there, uh, that replicates the product environment and helps us out to test the things as well as, you know, like, uh, enhances the confidence of the developer before any sort of deployment.

Uh, that is one of the great advancement that I do see in the field of platform engineering. And that is helping us out every day, uh, while we are shipping code, uh, multiple times a day to production. So yeah, that is one of the things that I do look forward to looking out to some of the interesting talks around the same in the platform com.

Very nice. Just a, your, your, your thoughts. Yeah, I think those are all great points.

I mean, when it comes to tools, I think, um, two big areas are different, definitely configuration management and ensuring, uh, like a standardized approach when it comes to that. Um, that also touches on what I'll be talking about, right? Like you don't only have different configuration per environment.

Like you want different, dunno, database credentials to be, uh, in injected on development, staging and production, but you also have different tech and tools you work with, right? You might be using Docker locally and then you deploy to Kubernetes with Helm, for example. I think, um, having tools kind of focus on the developer experience here and understanding that, like using all of these tools can be quite complicated.

And building these abstraction layers is definitely a trend that we're seeing. I mean, the, the backlash there is that people might feel abstracted, so it's like abstracting without feeling abstracted and finding like the right level there is, I think what we have to have to figure out, right? Um, so that, again, uh, the complexity is compartmentalized in a way that things are actually accessible to everyone while maintaining that flow that you mentioned before.

Um, so yeah, I think that we're, we're seeing, um, like those things emerge across the board, a lot of movement in the open source community. Uh, an example is score, uh, which I'll also be talking about, which, um, aims to do that, put the developer experience first, um, when navigating with like, jungle of, um, tooling that teams often work with. And, um, yeah, I think those are the, the focus areas, uh, when it comes to actually wanting to adopt, uh, according tooling, You know, and, and people have different, what they enjoy doing.

Some of us, like, I'm gonna dive into Kubernetes and the depths of it in becoming the expert that I can be in Kubernetes and, and others of us. Like I use Kubernetes, I want to know what I need to know, but in, that's not my thing to be the expert on that. I'm going to kind of be, be expert at maybe to a reasonable degree on multiple things or maybe pursue something else.

So we each have our own interests, right? And, uh, I know there's times that like, I want to go learn that and then I move on to the next thing. And if, the reason why I bring this up is, I think one of the cool things about platform engineering is that it's not just a, a tool or a set of tools, it's an evolving set of tools.

We might use Docker and Kubernetes for a long time, but we also will be introducing new stuff. You know, we've already mentioned, you know, dagger were talking about earlier, Brian, and new tools that come along and we wanna wrap into, and, and of course that's what talks that, uh, platform Con are about right. To hear about those new things, um, what people are working on and solving some of the to problems like configuration drift, you know, things that we, we all combat and, and battle for a long time.

So, but that's what keeps it interesting, I think, and exciting, exciting for all of us. Um, I'm curious, you know, we're, we're all experienced here, right? You know, we've been been doing this kind of work for a while.

Um, what do you think are some of the positive advancements or improvements that we've made through this focus on platform engineering, uh, in, in relatively short time? It's not like we've called it platform engineering for 20 years. We may have been doing some of those things, but yeah.

What do you see as some advancements or improvements? Um, suse, do you wanna, you know, start first? Yeah, sure.

I mean, I think a first great improvement is that the idea is spreading, so it's like it's trending, it's a hot topic. Uh, we talk about it, it even has a conference now with Platform Con. So I think that's a, a great first step and, um, that also then the, the next step is logically putting things into practice, uh, which comes with trial and error.

And I think having that discussion going on, that experimentation on how to implement things on, like agreeing on that working definition that we talked about initially, um, like this wave of interest and experimentation, I think is, uh, great to see. And, um, uh, a great first step. And I think, um, we're, we're on the right path there as a community.

Very good Jump in folks. Yeah, I was gonna say, maybe this is tongue in cheek, but the centralization around yaml, uh, is actually, I know a lot of people have like, you know, visceral reactions when you say yammel, but like, just by making a decision that, okay, this is how DevOps tooling will be built around, and I know like Hash Corp has, uh, their own hcl l but like now we can sort of centralize our tooling around similar structures. Uh, it's easier to sort of pick and choose, uh, across ecosystems.

So yeah, as was just mentioning like, this decisions have been made, we can either choose to build a next new thing or we could use whatever the pace layer, which is, for me, it's yammel, uh, and then as long as I have a consistent thing I can go back to, I can build on top of that and it's predictable. Mm-hmm. Yeah.

I also would like to utilize sort of at at few more points earlier on top of what Susan and Brian has said, right? Uh, with, with agreement in adaptivity of platform engineering or platform as a culture, right? Uh, we have been doing a lot more experimentations around tooling, uh, than what we were doing before.

So now, uh, with, with the available number of case studies that we do have on a daily basis, right? I can, you know, like, check out for my use case or maybe, uh, someone can check out what we are doing over here through the means of this conference, right? That we can see.

So, uh, as far as a platform engineering is considered, knowledge is spreading on at a really, you know, like fast pace. And this will not only help us out to solve our problems, but with, it'll also create a reflection to other people on how, uh, challenges can be taken up and solved at a last grade. You know, I, I, one thing I want to kind of bring back up that I mentioned earlier is, uh, the fact that we're focusing this on, uh, as a discipline, uh, and kind of getting back to the pro productivity, efficiency flow, helping people who are creating software, uh, be able to spend time doing what they're doing, that to me in and of itself is a positive huge step.

And sometime having too many options is actually a disadvantage cuz now you can spend all your time figuring out the right way to do it or what way you wanna do it and how to make it work, versus just kind of picking up like, okay, we're doing it that way, great, I can do it that way and maybe I'll help make it better later. Or I'll just, you know, crank on with my job now. But I think that just having it as a discipline and a focus and the fact that, you know, you all independently say, well, you know, I'm focused on developer experience or developer productivity, and that tells me we're working on some good things, some people who can appreciate having that help.

So it's awesome. I, I'd like to dig a little bit more about your talks. Um, Jay, maybe you could just give us a little bit deeper kind of Richard, what you're, what you're gonna, what you're talking about, but I'm also curious why you chose that is what you want to talk about.

Definitely. So, yeah. Yeah.

Uh, as I've mentioned earlier, right, I'm working for the team which manages the API gateway repay, uh, I'll be speaking for the topic, uh, edge at repay, uh, which is the API gateway for DTO protected high skill environment, uh, being one of the leading API gateway or, or payment gateway, I'm sorry, payment gateway for the country. It is important for us to ensure availability and also, uh, that should not the scalability of the product that we are serving over here to the customers, right? So that comes up as its own sense of, uh, sense of challenges, right?

So API Gateway being a commonly used tool for API management, right? But the reason is the customization for the learnings that we did based, or, or the challenges that we've faced by, you know, like building API gateway, our own set of custom tooling on what whatever the available solutions are, that is the major reason, uh, to, you know, like pick this topic up to share our learnings and also to get feedback upon like what improvements are there, uh, that can be taken up, which can help us at, in, in our future use cases also, right? Uh, on top of it, like there have been several challenges also that we have, uh, product card or achieved, uh, with, with the talk that I'm trying to present over here.

So, yeah, looking forward to that API security API gateway is all huge, huge, huge important topic. Uh, Susan, how about you? I wanna hear more about, so what, what, what caused you to get to the front of the keyboard and say, yeah, I gotta I gotta talk about configuration drift?

Yeah. Just because, uh, it turns out to be a problem that a lot of developers struggle with. Um, so maybe it's helpful to clarify what I mean by configuration drift, because it is also one of these buzzwords that can mean a lot of different things depending on, on your context.

So, um, I'm talking about configuration drift between environments that run on different platforms. Uh, so what I mentioned before, you might be using Docker composed locally and then deploying to a remote environment that runs on an orchestrator like Kubernetes, for example. And, um, the problem here again, is to keep configuration in sync, um, across these tools.

Um, so what I mentioned before as well, um, making sure that the right, um, values, uh, are injected, but also that, um, for example, resource dependencies are provisioned in the right way. Um, so, uh, dependency on a Postgres database, uh, is resolved differently locally with Docker or compared to Kubernetes, where you might rely on a tool like, um, Terraform, for example. And, um, that's what kind of causes the risk of, of translation gaps, essentially.

Um, so that configuration changes essentially don't make it to that next environment that runs on another tool. Um, so working with different environments that run on different platforms is kind of the, the problem space I'm, I'm diving into as part of my talk. Um, and then against the background of that, do I wanna, um, introduce score this open source project that essentially, um, tries to provide, uh, an an answer to that problem, um, by essentially introducing a workload specification file, um, that lives with your workload.

It's platform agnostic, it's environment agnostic, um, and thereby allows you to kind of generate the configuration you need without being so involved with that exact environment your workload runs on, or that exact tooling, uh, that runs underneath. So, um, I don't wanna get into monologuing here, but, uh, that's the, that's the, uh, grand idea. And, um, I mean, I, I chose the topic because I, yeah, just think it's a problem that affects a lot of developers and teams struggle with it.

I also think it's highly relevant for the platform engineering community, uh, simply because it ties directly into the discussions that, that we're having right around configuration management and self-service when it comes to resource provisioning. So, um, I think that's why it's just super interesting to discuss it with that kind of audience. Um, and then lastly, adopting score or essentially eliminating config drift is, in my opinion, only possible if you have that platform engineering mindset in place already.

So there's like that work that has to be done initially. You can't just, um, download score and you're good to go. Um, as always, there's just like a, a lot of work that has to be done inside of that.

Yeah. Now I'll mention my talk, which is, uh, yeah, re repeatable release management. Um, uh, started my career as a full stack dev develop developer and increasingly became more of a front end developer more and more as the years gone by.

Um, so we in open source, we have a, a build system that we use at every single project. So repeatable builds in every time we start a new project, we have the same build system, uh, that's built on top of get of actions to produce a tarball or a zip, uh, for us to go host and and deploy other places. So whether it's a, uh, a, a server side project or M p m package or just a static website, uh, we have the same build system that we were able to reproduce and reuse.

Uh, and for, because of time, I didn't actually go into detail on the, all the in ins and outs of, uh, of the tool, but everything that we've done is open sourced and, and viewable within our, our GitHub repo. Hmm. Fantastic.

What was great is all of you very passionate about what you're talking about, which is, that makes it easy to have a talk. Um, so just a heads up, I'm gonna ask each of you if there's a topic or a talk, uh, set of talks that you're really kinda, you've previewed and on the agenda, really interested in checking out. Um, so before you do that, um, just kind with with the organ org organizers, um, of, of the event, uh, Kathleen and, and other folks, the ones that kind of stood out, jumped out to me just to name a few.

So, you know, some of the things that are happening, there's a talk on platform as code simplifying developer productivity design with reference architectures coming from a couple folks from, uh, McKenzie, uh, a person for Gartner, I'm gonna not mention names cuz I'll, I'll butcher their names. But, uh, how to communicate the business value of platform engineering. Hey, how to get funding a k a, that'd be my interpretation of that.

I talk about building the perfect platform in the midst of everything else. I talk about the journey into internal developer platforms. So these are all people who are, have gone through going through this process of implementing platform engineering.

There's also a couple of other interesting talks. Dev DevX, uh, developer experience is not DevOps, investing in developer enablement to reduce barriers to continuous delivery. Again, I think this is kind of on that theme of getting back to developer productivity, which is another talk dev, uh, DevX, what exactly drives productivity?

com, uh, n dx, a bunch of companies nesto to name a few. So I thought I really liked those that, that we picked out because it's talking about what it's about to, to create the, a developer and, uh, platform engineering environment to support your developers and also what we mean by developer productivity and and experience. Um, Brian, any thoughts?

Any, any particular topics or you're like, I'm going as a speaker, but I'm going to learn a bunch of stuff and there's A couple. Yeah, that's the, the fun part is like when you're a speaker, you focus on your talk until it's done and then, then you get to relax. Um, so the beauty of a pre-recording all these talks is that I can actually relax from the start.

Uh, but I, at the current, like we're a team of currently four, uh, at Opens sauce. So, uh, the world, this conference is remote, so everything about culture and working with remote teams and handoff and information sharing, like, that's the track that I'll probably spend the, the most of my time with. Uh, cuz I want to be able to grow and scale a team and folks in different time zones.

And I think what's the beauty of this is like, it doesn't matter what time zone you're in, um, as long as we can, we overlap sometimes in our asynchronous meetings, uh, or sorry, with our secrets meetings, but how do you build a a really strong asynchronist culture, um, is stuff that I'll be, I'll be looking for on the schedule. It can be tough to get going, but once you get it going, man, it's awesome. Yeah, great topic.

Uh, how, how about you, Jay? Yeah, I'm also looking forward to some of the use cases that you have mentioned, right? Uh, how, uh, platform engineering is evolving as a culture, how different teams are using platform engineering in there in their org and you know, like what, what are changed from the last year or what are the new advancements that has been going on, right?

Ensuring all the, uh, perspectives that are there in from engineering. So, uh, yeah, as, as Brian mentioned right now that we have prerecorded and submitted the talk, uh, it would be, it would be good for us to like focus on all the, uh, all the talks that are being scheduled for the topic. And also we would like to connect with the folks over there at the community.

So, you know, like can, can learn and share my learnings also. Yeah. Fantastic.

Su Yeah, uh, I mean, I'm excited for, for all of it. It was super fun last year to just like have the stream open on the side and like, uh, click through individual talks. I think I'm gonna keep a close eye on the cultures and stories track, um, just from a product management perspective.

I, I find it super interesting to hear more about like, hands-on experience report and like real life use cases. I feel like, um, specifically when you're involved more of the like, theoretical side of things, you talk about definition and concepts and ideas, um, it's actually super interesting to hear how things play out on the ground. Um, and like hearing about real life pain points and success stories.

Uh, it's a good reality check and of course a, a learning experience also for me. Excellent. You know, I just, in addition to the sessions that I mentioned earlier, one of the things that I always enjoy is the new people you meet, you've not heard from before, uh, you get to connect with and, uh, I don't know if I can meet all 7,000 plus I can't, but if I could, I would.

But there's so many great people that you, you know, more people you, you learn from, connect with say, Hey, I have that problem, can you, let's talk a little bit. I wanna find out more about what you're doing there. Um, it just, it kind of enriches, enriches our work and just as a whole nother resource for us to learn from each other and grow and share with each other.

So it's a way of giving back as well as getting so much from it. So, well thanks to all three of you, uh, for spending this time. Most importantly, thanks for, for your talks and the topics and the commitment to do that, uh, to share with everybody else at Platform Con.

Uh, it's been a real pleasure talking with our global audience here. We were talking before, kinda represented by several places around the world just with this team. So, um, one, one I'll just close by say, saying to folks, whether you're new to platform engineering or maybe you're, you're trying to build it from scratch or you want to go find out what folks are doing, how can I kind of accelerate my adoption of platform engineering?

There's so many reasons why you might attend, uh, platform Con, but please check it out. com slash register. In this video in the description, we'll also put a link to a, uh, nice Gartner article about the, uh, top 10 strategic Technology transfer 23, talking a little bit about some, uh, topics relevant to, uh, platform engineering.

So thanks to all three of you. Look forward to your talks. Can't wait to hear the dive in and hear more about it and, uh, we'll see everyone else there.

Thank you everybody. Thanks Mitch. Thanks.

Thanks.