Abby Bangser of Syntasso geeks out with Adriana Villela about the increasingly vital role of platform engineering. From its relation with DevOps and SRE to its significant impact on the developer experience and business delivery, Abby makes compelling arguments about its importance. They delve into discussions about tooling, creating internal services for businesses, and how we can shift from merely creating new solutions to effectively using existing ones. They also touch on "Thinnest Viable Platform" for maximizing business efficiency. Finally, they discuss their recent collaboration on using Kratix, an open source tool that Abby works on, to deliver both OpenTelemetry and VCluster capabilities to developers.
About our guest:
Abby (she/her) is a Principal Engineer at Syntasso delivering Kratix, an open-source cloud-native framework for building internal platforms on Kubernetes. Her keen interest in supporting internal development comes from over a decade of experience in consulting and product delivery roles across platform, site reliability, and quality engineering.
Abby is an international keynote speaker and is co-host of the #CoffeeOps London meetup. Outside of work, Abby spoils her pup Zino and enjoys playing team sports.
Find our guest on:
Find us on:
Show Links:
Additional Links:
Transcript:
ADRIANA: Hey, y'all, welcome to Geeking Out. The podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host, Adriana Villela, coming to you from Toronto, Canada. And geeking out with me today is Abby Bangser. Welcome, Abby.
ABBY: Hello. Thank you for having me. Super excited to talk about all of those subjects, actually.
ADRIANA: Yay. I'm so excited to have you on. We had you for on call me maybe, and that was like a real treat. So I'm really happy that you're able to come on to geeking out. So, Abby, where are you calling from today?
ABBY: I am calling in from London. Despite this accent. London, UK.
ADRIANA: It's so cool to see where people are calling in from because there's always an assumption that it's like a North American focused podcast or probably American focused. And here we are. Super international.
ABBY: Yeah. I've learned from living abroad that if people are speaking with the English dictionary, I'm just super content that I can understand what they're saying. And I actually find myself completely missing accents all the time where someone will say, oh, the Scottish person. I'll be like, oh, shoot. I actually don't remember what accent they had or South African or wherever. And it's just. I'm just really happy when I can speak the right language with people.
ADRIANA: I can definitely relate. So are you ready for our lightning round questions?
ABBY: I think I have to be. Let's go.
ADRIANA: I promise they will be painless and fun. Okay, first question. Are you a lefty or a righty?
ABBY: Righty.
ADRIANA: Okay. IPhone or Android?
ABBY: Absolutely, Android. All day.
ADRIANA: All right. Mac, Linux, or Windows?
ABBY: I have all of them. I've been on Mac most recently with software development stuff.
ADRIANA: But which one do you like better?
ABBY: It depends on how fiddly I am being. So I did the Linux desktop thing for a few years, and it is fun to get into all the configurations and setups, but sometimes you just want to print something. So in that world, I'm a big fan of the Mac.
ADRIANA: Yeah, I feel you. I went through a Linux desktop phase and I was like, this is awesome. And then I'm like, oh, shit, I can't do anything. And this was back, I want to say, in 2007, where it was the.
ABBY: Year of the Linux desktop. Just like every year is the year of the Linux desktop.
ADRIANA: For me, the deal breaker was like, when I had a BlackBerry at the time and I couldn't use the BlackBerry app for syncing, I'm like, fuck. So then I ended up having. I had a Windows VM for a while. I ended up doing a Windows dual boot and then I moved to a Mac and not looked back since.
ABBY: Yes, I understand that.
ADRIANA: Okay, next question. Favorite programming language.
ABBY: Oh, favorite programming language. So I'm working in Golang right now. I've always been someone who looks at code as a problem solving thing. So I haven't really gotten too esoteric about the most perfect language I've written in. So yeah, I just like to work. I guess this comes from my roots as a consultant of that I've written C sharp, Java, JavaScript, Python, Ruby, and then lots of infrastructure as code languages. And so I just sort of want to solve problems in the languages that people are working in.
ADRIANA: I love it. Yeah, very nice. Cool. Okay, next one. Dev or Ops?
ABBY: Got to be Ops. I guess if you make me choose. I love the impact you can have in Ops. Like just the scale of impact within an organization that you have when you have a really nice operations to the process. So I've been on platform engineering teams for, I don't know, the last eight or nine years, so it's hard not to pick.
ADRIANA: I guess. Last week I recorded with Tim Banks and I asked him the same question. He's like, well, Ops runs the world.
ABBY: I suspect we'll get into what is the true difference between Devon Ops at some point later today. But if you make me have to pick, I'll pick my roots in Ops.
ADRIANA: All right, fair enough. Next one. JSON or YAML?
ABBY: I really like comments so I think I have to pick YAML, but oh boy, those spaces. That's a tough one. I'll go with YAML for the comments.
ADRIANA: Yes, I do appreciate the comments. Until someone pointed out that you can't do comments in JSON, which I knew but consciously was like, I think I've gotten angry at it before for not being able to do comments, but I'm like, oh my God. Yes. Two more questions. Do you prefer to consume content through video or text?
ABBY: Ooh, I'll go with video. But I will say that what I do is I keep a folder of different content on my phone of what I want to bookmarks or whatever to watch or to listen to or to read. And I just use them at different times. So I separate them not by content topic but instead by way of consuming. So if I'm going for a bicycle ride, it might be auditory something, and if I'm sitting on the train it might be reading. And so I do like a bit of both.
ADRIANA: But yeah, fair enough. Yeah, that's a really good point. Yeah. I was telling someone today, I love the audio stuff for when I'm doing busy work chores around the house or what you might call it, like going for a walk or for a run. Especially when I'm running. I hate and love running and it makes the time pass faster.
ABBY: I can answer that one much faster than all these. Hate, hate running. That'll be the quickest of all these lightning round questions.
ADRIANA: Final question is, what is your superpower?
ABBY: What is my superpower? I'm going to go with being able to energize other people if I'm going for a real one. I'm coming off the back of a very exciting tag rugby win last night for a team, and I unfortunately have a bad back and couldn't play. But the team just rallies in a way that I feel like I can help bring energy to the team. And so I did my part despite not being on the pitch. Yeah, I think that's probably it.
ADRIANA: That is a good talent and very translatable into the work world as well, right?
ABBY: Yeah, I think it works out okay. I mean, I'm sure there's times when it gets annoying. I'm very sure that's what all superpowers, right? They have their good and their evil. But I like to think it's more good than.
ADRIANA: When I remember when someone mentioned, oh, check out Abby's content. And I started watching your videos and reading your blog posts, and I remember you just came off with such infectious enthusiasm and just like, oh, this is somebody I'd like to chill with.
ABBY: And then we got to. So it was great.
ADRIANA: We get to see each other at KubeCon in November again, which I'm super excited for.
ABBY: So excited for a trip back to Chicago.
ADRIANA: Yeah, yeah. I really like Chicago, and I never spend long enough in Chicago to actually see it properly. It's the curse.
ABBY: Yep. The curse of traveling for conferences is that you're always like, oh, I'm going to this great city and I will see the convention center.
ADRIANA: If I'm lucky, I'll get to see the bean again.
ABBY: Yeah, exactly.
ADRIANA: Thanks for answering the lightning questions. So onto our regular business. So one of the things that I wanted to talk to you about is platform engineering. It is the hot topic these days. So I think, for starters, why don't you explain to folks in your view, what platform engineering is and how it differentiates from DevOps and SRE, for example.
ABBY: Yeah. So platform engineering is, in my opinion, and from kind of taking together a few different quotes from other things, it's a way of building internal services to support kind of the business use cases around an organization. I think that right now there's a lot of focus on how that impacts things like developer experience for software engineers. But I'm very specifically, I feel like the definition is a bit broader than that. It's about supporting the delivery of business value at scale with consistency and security and compliance in mind. And platform engineering is the act of putting that together into services that are consumable by the organization for those end goals. I think I have a talk at DevOps Days London, where I do just boil this down to it's internal services teams done better. So it's internal, it done with more kind of product mindset in a lot of ways.
ABBY: And I think where you start to differentiate between some of the other kind of buzwords and titles and philosophies that are out there, depending on what they are, is the way I've been looking at platform engineering recently is that it's an implementation of the DevOps intention. So with DevOps intention, it's to reduce the friction between silos. You looked at silos of software development and software operations and you wanted to improve the friction between that and the quickest way to do that. The best way to our understanding, was to remove the silos, ask software developers to understand their operations, ask them to figure out how to do on call and telemetry and all of these things, and simultaneously ask operations engineers to learn about software development and to bring automation to their processes and testing and all those kind of things. But that's hard. That is really hard because you're prioritizing the removing of friction over the depth of knowledge for certain people. And that sort of specialization value that comes from someone who deeply understands an area of the business or of the technology. And platform engineering, in my opinion, is also really hard just to say, but the idea is to productize those specialties and make it so that the silos can still exist.
ABBY: But you're focusing on the friction between them that's being reduced. So you still have your specialists, but they're providing a service to end users that they think about like a product, and they provide in a way that is easy to access and easy to use.
ADRIANA: Yeah, that sounds awesome. That makes a lot of sense. Now, follow up question. In your opinion, do you think that we've achieved what DevOps promised?
ABBY: So DevOps basically promised the idea of reducing friction on the software delivery kind of process or lifecycle. I think we are achieving that. I think we have less friction than when DevOps was born 1015 years ago, twelve years ago, whatever. Do I think that we are going to get more return for the experiences and processes we've put into place over the last ten years? This is where I think we're seeing a shift in focus. So the intentions of DevOps, we are doing better, we are moving our way, but if we keep kind of trying to drill into this idea of everybody builds and runs their full stack, we're going to lose the fact that, no, we don't. First of all, we don't plug in our own hardware. Most people, most people aren't both wiring up a server and writing the CSS for their front end. Their full stack is whatever their team or their company defines.
ABBY: And I think if we continue to think about the friction between the layers of value that we're providing and we keep trying to reduce that friction, we'll keep gaining benefits on this journey of DevOps. I don't know if there's an end state for DevOps.
ADRIANA: And that makes sense because one of the things around DevOps is like this idea of continuous improvement and there's never going to be like perfection, right? We always chase it, but we aspire to it. Software is never done.
ABBY: No. And that's what we're doing with platform engineering, bringing development to operations. We're making more software and we know software is never done. It always needs upgrades, it always needs improvements, it always needs coming back to, to make sure we're not customizing things that are now commodities. Right? So there's lots of things that you may have written a few years ago that now there's public packages to lean on and so you don't want to be maintaining that yourself. And if you don't do that, you very quickly get snowed under with the amount of maintenance you have on things that are not actually differentiating for you, your team, your business, your organization and all that. We're just multiplying software everywhere. And so we absolutely need the DevOps principles of reducing friction between teams and building and running the software that you are owning so that you have that feedback loop from production into your development lifecycle.
ABBY: I think we need that as much as ever.
ADRIANA: Yeah, I totally agree. And you bring on a good point in terms of like you may have developed this on your own in house at some point in time, but if there's something better that came along that solves your problem and then some, it ends up being way more awesome. But I feel like, and I fall into this trap before as well as a developer getting into this idea of like, oh my God, I get to build something cool and new and this is awesome. And then you build it and then you're like, shit, I have to maintain this. And then the shiny and new thing kind of just wears off and you're like, never mind.
ABBY: Well, this is the problem with the average tenure of employees being like two years, right? By the time the average cycle is you come in excited about your new job, you spend then maybe a few months getting up to speed with how things work and what's going on, and then you've got maybe about six months to a year of whinging about something that you hate about the way that things are done wherever you are and advocating that something change. And then you implement that change. And then you move companies or you move teams and it's like, well, there's somebody doing the things that you're complaining about as you go to these new companies. And I would hearken to guess that the people who come in after you have plenty of complaints. And it's just that learning about what creates that maintainable and kind of experience that you want to have as maintaining software is hard to learn if you don't spend years and years maintaining the same software. And yet that's just not how our industry right now happens for many people.
ADRIANA: Yeah, it's so true. We get bored easily or we're chasing the next shiny thing. Ooh, I get solved this problem. That sounds way cooler.
ABBY: Yeah, exactly.
ADRIANA: I guess the good news though is that there are companies out there that are working to alleviate some of the problems that developers and platform engineers and Ops folks are experiencing. And we've seen that with the umpteen different tools built to support Kubernetes, various platform engineering tools and whatnot. So it's been kind of interesting to see how much the market has evolved in the last 20 years.
ABBY: Yeah, it is amazing. And I think you say 20 years and that's absolutely true. But there's been even more explosion in the last maybe handful of years, five years or so. As you say, platform engineering is everywhere. And the reason it is is because that feeling or that interest in developer experience has grown tremendously over the last kind of four to five years. And platform engineering is one way to possibly address this application software development experience. And so yeah, I think you're seeing all these tools that are building off of the PaaS experience, the platform as a service experience that was, I think, first really popularized by Heroku in kind of the 2012 ish era, but now that's just commonplace that there's lots of tools out there that act in that kind of way.
ADRIANA: Yeah, so true. And on the platform engineering front, I wanted to ask, what do you think are some of the biggest problems that platform engineering is trying to solve right now?
ABBY: So if you listen to marketing, it's all developer experience, all day, every day. It is. How can the application software developers find what their applications are doing? They need a portal and they need to make their lives as perfect and glorious as possible. But I don't actually think that is the case. I think that is a piece of things that we're trying to solve with platform engineering today. But when you talk to the companies that, I don't know, make money in things, the big organizations, they're actually not always focused on developer experience as a top reason for platform engineering. Often they have issues like compliance and security and regulation, standardization and support as a key reason. Often they have cost optimization as a key reason.
ABBY: There's all sorts of reasons why providing a centralized offering as a service can benefit the business and is only auxiliary, supporting the app dev experience. But that isn't the reason for the work being done. And yeah, I don't think that gets enough press, right, because it's not as much fun as making a developer portal and things.
ADRIANA: That's so true. Yeah. I mean, every time we talk platform engineering, I feel like developer experience is almost synonymous with it. And then all this other stuff takes a backseat. But compliance standardization, so important, especially, obviously in any size, but especially the big corporations that have to worry about regulators and compliance and all that scary stuff, right? I mean this is serious business. So being able to cater to that, cater to security concerns, having a standardized way to ensure that things are locked down to your company specifications, so important. And as you said, not talked about enough.
ABBY: You've tripped right over one of my biggest pet peeves as well, where you mentioned that developer experience is like synonymous now with platform engineering in some ways. And also developer experience at this point is synonymous with a software application developer's experience. So someone who is writing a web app or a backend app, API app, something that is like Java or whatever, running in a container or on WASM or wherever, but the software side, they aren't the only developers. As I said in the Lightning round, I pick ops like I'm a developer, even though I write HCL code, even though I write bash, even though I write whatever chef recipes and whatever else on the back end. So I think the fact that developer experience has then I would say narrowed to the point where it's only application developers is showing, I think, in that explosion in kind of tooling and activity in the industry, because you look at all these kind of products that are coming out and they're all focused on how to get a piece of software out in front of an end user as fast as possible. But when you start to dig into how do I operate this thing, how do I build in my PCI compliance and my workflows and my marketing workflows and my customer success workflows and all these other things I need around the business, it all falls apart. And I think that too many of these forget that there's a whole other side of software delivery that isn't just writing software code. And that experience needs just as much kind of improvement, if not more.
ABBY: Because again, the leverage of that across all your software teams is huge. So yeah, it's one of my little pet peeves. You chipped right over it.
ADRIANA: Moral of the story, get some TLC. Outside of just developer experience, just app.
ABBY: Dev experience still can be developers even, but yeah, even that's probably too narrow. I agree.
ADRIANA: Yeah, very good point. Yeah, and you make a very excellent point also. You're a developer regardless of whether or not you're developing the application software or you're developing code to operate your system, it might be slightly different as to some of the things that you're concerned with, but at the end of the day, code is code. Technical debt still exists in both realms.
ABBY: And the tools you have impacting what you can create exists in both realms. I think I've been on the software side for many years as well. And on the software side, I've been in a situation where an internal team provided an API that my team needed to use to create a visual front end for. And the shape of the data that came back from that API absolutely influenced and even kind of forced our hands sometimes in just what we could create on that user interface experience. Because not being able to receive the data in certain ways or access it on certain pages or whatever, I mean, the same thing goes from the platform engineering standpoint. The tools we have, the baseline kind of bash and Goling and Ruby and whatever that we're using are forcing our hands to create what I think is actually not create developer experiences. We're exposing application developers to helm charts and terraform modules and chef recipes. And it's like they shouldn't have to know what languages we write, they shouldn't have to know what tools we rely on.
ABBY: But because they're all so primitive and they're all so low level. We're working so hard to piece these bits together for our business process that that's like as far as we can get on the platform engineering side or it feels that way. And so I think getting more, as you say, TLC to those platform engineers is only going to make better experiences for the application developers because they'll start to have a bit more bandwidth to be like, hold on, how are people actually using the stuff that we create? Is this the experience we want to give them? Is it about cloning a git repository or forking a git repository or something? Or should it actually be a different experience altogether? Something as a service behind an API or something else?
ADRIANA: So here's a question. How do you ensure that you bridge that gap to raise the awareness so that it's not just this developer experience, application developer experience centric view of platform engineering? How do we shift the conversation?
ABBY: I mean, we just need platform engineers to speak more about what they need and sort of get involved in the community. So one of the things I'm doing is I'm a part of the CNCF or Cloud Native Computing Foundation working group model. So the way it works is that there are groups with different focuses and they sort of narrow as you get down the model. And I'm in one of the kind of most narrow things, which is called a working group for platforms, and this is under the umbrella of app Delivery technical advisory groups, or tAg. And the idea is you want to be able to deliver applications. And one of the ways in which an organization can support app delivery is through the creation of a high value platform internally. And this working group is having all these conversations about identifying ways to speak to business leaders, CIOs, CTOs, CEOs about the value of investing in platform engineering experience and tooling to be able to support this kind of outcomes for them. So, yeah, get involved in the community, start kind of helping shape the conversation a bit more.
ABBY: Right. There's, I think, less platform engineering voice than there is application developer voice right now.
ADRIANA: Yeah, absolutely. And one of the cool things about the working group that you're part of too is it's representation from different platform engineering vendors or I guess practitioners. So you get different perspectives, different voices, sometimes competitors all working together, right?
ABBY: Yeah, it's absolutely. I think there's a heavy number of vendors and a heavy number of kind of consulting oriented people, but there's also a heavy number of kind of end user related people as well. So people who work at these large, successful enterprise organizations and are driving these initiatives internal at those organizations come and speak with the working group about their experiences, about where they're feeling like they need more support from kind of the industry or from tooling and from vendors, as well as how they're piecing together these tools to create the experiences that they are. And we always want to welcome more people with more stories. I mean, we're working right now on a follow on from a white paper we released in the spring, which was around the platforms as a definition, as a white paper. We're now working on making that a bit more tangible, with a maturity model to talk about how you can kind of evaluate and grow your experience with platform engineering in relation to that white paper. And we've been through one round of edits already, and I think we have something like 30 or 40 collaborators already, and we're going into our final edits now, and we're only seeing new people pop up every day. So I really believe this is going to be a global vendor agnostic, business domain agnostic piece of work that will hopefully help people have these hard conversations at their organizations and get the kind of support they need to be successful with platforms.
ADRIANA: Oh, that's really nice. That's really nice seeing the community come together like that. And what are some of the, I don't want to say grievances, but I'm going to say grievances that some of the practitioners come with when they share their experiences.
ABBY: Yeah, I think that it's often just not knowing what tools to grab for and how to interrupt them all. So each tool, it's in its own right, is interesting and exciting to them. But right now, there's not enough of an ecosystem around platform engineering. Everyone's sort of fighting to be like the one tool that rules them all and says, if you use us, you don't need to worry about anything else. And the reality is that most of these organizations really, at any scale, from quite early on, will have a fairly diverse need, right? They'll have front end apps and back end apps, which will often lead to different languages, though not always. They will have applications that are more on the cutting edge and are their kind of exploration applications versus their more money making applications. They'll have ones that are compliance related and ones that aren't. And so there's just so much nuance and diversity, and yet people are trying to still sell this monolithic idea of the one platform that you can kind of buy and use, and it's just not being realistic based on the feedback we're getting from people.
ADRIANA: It would definitely be lovely to have.
ABBY: That if you can do it.
ADRIANA: Yeah, that is a lot of stuff going on, a lot of different needs to cater to, which makes it very challenging.
ABBY: Look, if you can start as a small company with using a purchased solution and keep everyone on the rails on that solution, you will be very happy. Right? That is absolutely the cheapest way of doing any of this stuff. But the way that I try and describe it is it's basically like saying that you can use another company's processes for your company, and as soon as you have chosen to create any processes out of band from that kind of platform delivery mechanism, all of a sudden you just start that fissure and you just start that divide of what can be done on platform and what has to be done off platform. But again, if you start early with a single kind of monolithic platform as a service and you can keep everybody bought in that that's the right way to go, then yes, that is the cheapest. It's always cheaper to lean on a vendor and lean on a commodity product that has its own set of engineers who are supporting and improving the feature set than to try and build it yourself and maintain it yourself. But yeah, again, we're just seeing that that isn't proving to be long term viable for many organizations.
ADRIANA: Yeah, that makes a lot of sense. Now, what about taking the angle of even though each organization is different and has its own specific needs, we often find ourselves when we're moving from job to job that we keep solving the same problems over and over and over. And that gets kind of annoying because it's like, well, but I just spent like two years figuring this out of my old and now I have to do it all over again. And that sucks. So how can platform engineering help us with that?
ABBY: Yeah, I think there's kind of two sides to that, or two things I'm seeing happen right now that might help with that. It's hard without a glass ball, right? But one is that you look at the kind of ecosystem that grew around docker containers and grew around helm charts and grew around operators and things like that, and you can see how they're solving some of those problems in a community way, in a publicly available way. And I think there will need to be some sort of an ecosystem that continues to build those business solutions that can be shared across. But where it becomes difficult is once a business has solved it, how much do they invest in being able to make that public? It's the same idea as when you really want to make that kind of utility. You created open source and your company is like, but now you have to scrub the commit history, you have to do all these, create a contributor guide, you have to do all these things. That's true for all these solutions as well. So it's not always cut and dry. But I think that we are building ourselves bigger and bigger abstractions and maybe we will get ourselves to a point where we can provide those higher level kind of business cases out.
ABBY: The other side that I'm looking at is that we've all been here with all of the things that end up becoming commodities, like the number of times we tried to recreate the wheel on creating a user facing developer portal before Backstage came around and gave us a framework for doing that. The number of times we recreated the wheel with creating web applications that could receive HTTP requests and speak to databases before we got frameworks like rails or spring Boot or pick your language, pick your framework. We see that in order to coalesce around a common problem, there have to be a lot of attempts at solving it to really understand that it is the same. And I think you're 100% right that we're getting there with platform engineering, we're getting there with the fact that hey, we want to be able to give databases as a service, hey, we want to be able to give development environments on demand per pull request. We want to be able to update the secrets that our web app depends on as a service. There are certain capabilities that I've provided time and time again across organizations and I think we're getting there where we're going to need to do kind of more of a framework approach to things, right?
ADRIANA: Yeah. And I think that's really exciting prospect, especially when you think about things like renewing certificates, updating secrets. I've heard horror stories of certificates. There's one story I heard, I don't know how true it is, but at one of the companies I used to work at, a certificate expired. The guy who was in charge of the certificates was off on a cruise. Unreachable, not good.
ABBY: And it's probably one of those ones that you have to email someone and then they send you back a login to a secure portal to go download the certificate to then SCP it to the server. I've been there, thankfully not in an emergency situation, but I have been there.
ADRIANA: To be able to have tooling around that where you can just alleviate that problem significantly, because nobody wants to have to keep remembering how to do this. It's annoying, it's stressful. And sadly we tend to wait until.
ABBY: The last minute for it's because we have so many other fires to put out. But I mean, again, your Cert example is exactly why something like Cert Manager has become ubiquitous, right? And for any organization that hasn't moved their custom bespoke process over to something like a Cert Manager is they're being tied down and they're being weighted down by this need to maintain. Something that was very necessary before and was good that they created it. But now the best action is to move forward and start to lean on the commodities. I think I'm having a whole conversation right now with a few people about this concept of thinnest viable platform that was discussed in the team Topologies book, and the fact that right now most people are defining that really as just another word for minimum viable, as in how to get started quickly. You get started quickly with great docs, I love that. Yes, get started quickly by documenting and coalescing what you have on your platform. But call that your minimum viable.
ABBY: Your thinnest viable is always having an eye towards what can you offload to a third party that you no longer need to maintain. So it's not just about starting small and growing big, but it's about starting small and staying small and figuring out how you can continue to stay at only the highest level of value that you can provide and lean on as many third parties. Open source vendor I don't care to do the things that your company is not differentiating on. Lean on the industries for that.
ADRIANA: I like that a lot. It's time and money well spent. In fact, it saves you time. Maybe not money, but if you end up having to fork money over to have somebody else deal with it, because as you said, it's not part of your core competency, then so be it. Because chances are they probably do it better than you anyway.
ABBY: And that's exactly because just to say money is time. I was just reading a fantastic thread about technical documentation writers, or technical writers versus software developers, and how it was somebody's personal experience where they witnessed technical writers being let go for cost savings because the software devs could write their own dOcumentation. And the thread was all about this like cool. So what you're saying is that these people who make not even half as much like the tech, the documentation people, do not make nearly half as much as the software developers. You're saying it's cheaper to let them go and take the amount of time they spend on documentation and put it onto the plate of people that cost twice as much and aren't as experienced and therefore are likely going to be slower at the job than this. So you're paying somewhere. It can be off of the books, out of your bank account if you've got the ability to do that. And if you don't, sometimes you have to pay in, we call it like sweat equity or something like you have to pay in engineering time, but you're paying somewhere.
ADRIANA: Yeah, absolutely. It's funny how people don't consider, it's basically a cause and effect thing, right? It's like, oh, of course it's going to be cheaper because we've got fewer people on payroll and something that someone else can already do well, that's not normally part of their job. Now you're giving them more work, you might have to pay them overtime, or you're burning them out, both of them kind of.
ABBY: Or you're getting less from them on what value you expected from them than you were hoping. Right. And that might be what, you might have made that decision quite intelligently and carefully. Or it could just be that you're learning that the hard way. The side effects of that.
ADRIANA: Yeah, absolutely agree. So, switching gears a little, well, I guess related but unrelated, tell us a little bit about Kratix.
ABBY: Yes, I probably should disclaimer it as talking about frameworks. So I am working for a startup called Syntasso and we're building a framework called Kratix. And the idea is that pet peeve of mine about how platform engineers just get completely ignored in the developer experience kind of conversation is what we're trying to solve at Syntasso, they absolutely won me over as one of the first tires after the founders when they talked about being in the platform engineering domain and thinking about how platform engineers can thrive, not how the end users of the platforms get benefit. And I just don't think there's enough of that conversation. And this is the business domain I'm most interested in right now. So when we think about how do platform engineers thrive, I talked a bit about what I'm seeing in trends and that is what we have decided, sort of our first product to start to create. So it's an open source framework for creating business capabilities. So you think about a platform as a service, as a kind of a monolithic thing you might be able to configure, but everything has to sort of be delivered the way that platform that you purchased or that you're using works.
ABBY: Why people love that experience is because they want to have something as a service. Super easy consumable don't have to think about the maintenance behind the scenes. Someone else does that. Why they have moved away from products like Heroku and others is because they don't fit their business processes. With Kratix, the idea is that you can build anything as a service for your company relying on the tools you already rely on today, but leaning on the framework to be able to provide that sort of user interface, user interaction, that automation of the workflows, that scheduling to your different destinations, your different infrastructure, and kind of remove some of that heavy lifting from your experience as a platform engineer.
ADRIANA: That's awesome. Yeah. And disclaimer, I have played with Kratix before. I wrote was a promise for installing the OTel Operator so that it sends traces to Jaeger.
ABBY: Yeah, absolutely. Our first community promise provided. So first of many. So yeah, it was fantastic.
ADRIANA: Yeah, that was so much fun. And it was fun because I got to provide feedback on the product on something that was so new because I think you were mentioning that whenever there were promises for other tools, you guys wrote them yourselves. And I basically sat down with the docs and bugged you all a bit here and there to write this promise. So that was a fun experience. And it was also like my first experience with the hotel operator. So I'm like, what should I do? Well, let's combine platform engineering and hotel, because that'll be fun.
ABBY: Yeah, it was a great example though, right? Like that OTel Collector is itself a community provided tool that can significantly help internal organizations collect telemetry and therefore have Observability. And that's great. But where do you need this thing? You probably need it in at least more than one cluster, maybe more than one namespace within that cluster. How do you manage the deployment of that? How do you manage the upgrade process of that? Often you don't just have an OTel Collector, you have a fleet of hotel collectors, and you want them to be managed as a fleet. But our current tooling doesn't do that. Our current tooling is probably customized folders or Helm charts being installed in multiple places or something to that effect. And we really want that fleet management of OTel Collectors on demand and as a service, that's what you provided through that promise with Kratix.
ADRIANA: Yeah. So that was lots of fun, and I can't wait to play around some more with Kratix. I think the next experiment which you guys helped me out with was trying to install VCluster using Kratix, which I'm like, this feels like such a fun little project to come up with. And then that was neat because it kind of exposed some stuff that I was trying to do stuff with the product that wasn't available at the time. But then it's like, okay, well now I've provided you a use case for things that people might want to try out, right? Which I thought there was lots of fun, being able to collaborate with you guys on that, just being able to be part of providing meaningful feedback to a young product that's like, it's come along quite nicely since I started playing around with it.
ABBY: Yeah, thanks for that. You definitely weren't the last person to have that use case of wanting on demand clusters. And I think we talked about that platform engineering right now is pretty tunnel focused on application developer experience, but actually there's so much more to it, like cost minimization and eco impact minimization and things like that. And VCluster is a great example of where you can use that product to try and reduce the number of Kubernetes clusters that go up with all the kind of redundancy on the master nodes and all those things. And so what we did with that is be able to make on demand environments in VCluster for people. So instead of giving people a whole new cluster, you give them a VCluster. It's sandboxed, it's safe, it's less impactful on the environment, less expensive on your pocketbook. Yeah.
ABBY: As I say, you weren't the last. And we're working with some design partners right now. We have a few open spots. If anyone else is in this space and is interested in working with us on the product development stuff, it's all open source, Apache 2, licensed. We're not building in private here. We're trying to build for you and for the industry. So yeah, come have a chat with us anytime.
ADRIANA: That's awesome. That's awesome. Well, before we wrap up, do you mind sharing with some folks some of the things that are coming up?
ABBY: Yeah, so I'm not sure exactly when we'll be airing. So some of these things might be in the past, but over the autumn I'm speaking at a few events around London, which is really fun. I love being able to not have to travel and so I'll be at a AWS day and SiVo navigate and DevOps days London. I will also will be traveling to Hungary for a Housteff, which is a Hungarian testing forum, which is a nice return to my roots. I was originally a software tester and so it's nice to be able to go and connect back with that community and then I will be in November in Chicago, as we said, for Kubecon, which is super exciting. So definitely looking forward to connecting with people there.
ADRIANA: Very nice. And the thing you're doing in Hungary, that's the tutorial with TraceTest.
ABBY: It is. Speaking of an amazing kind of feedback loop with a great new tool. It's not that new actually anymore, but they still are just so responsive to any questions and ideas that we have that I have. And so yeah, I'm doing a keynote about observability and have created a new tutorial around using observability with trace test for the testing audience because I think that will really kind of connect people who aren't typically in the observability space but are in the testing space with connect those two dots together. So yeah, really looking forward to that.
ADRIANA: That's awesome. Yeah, I can't wait to catch the recording for that. I hope they'll be recording.
ABBY: I don't know if they'll be recording the tutorial, but I am doing it on instruct so I can definitely give access to it. It's all kind of open source tech that we're going to be using. So the team at Instruqt have been so good about providing access for the community driven activities like this, and they just have such a great platform for creating content and so really makes it a pleasure to deliver.
ADRIANA: That's amazing. Good to know. Thanks so much. Well, we're just wrapping up, but before we do, do you have any parting words of wisdom or hot takes to share with our audience?
ABBY: Parting words of wisdom, I guess when it comes to platform engineering, just remember it's an engineering, it's software. What do we need to make great software? We need to think about how to build and run that software, and we need to think about the end users because it's a product. And so whether our end users are our colleagues or our friends and family or someone else, they're still customers. And yeah, it's a product. So I think that's really the shift in focus with platform engineering in my opinion.
ADRIANA: Awesome. I love it so much. Well, thank you so much, Abby, for geeking out with me today. Y'all don't forget to subscribe. Be sure to check out the show notes for additional resources and to connect with us and our guests on social media. Until next time...
ABBY: Peace out and geek out.
ADRIANA: Geeking Out is hosted and produced by me, Adriana Villela. I also compose and perform the theme music, Trusty clarinet. Geeking out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento.me/geekingout
ADRIANA: Hey, y'all, welcome to Geeking Out. The podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host, Adriana Villela, coming to you from Toronto, Canada. And geeking out with me today is Abby Bangser. Welcome, Abby.
ABBY: Hello. Thank you for having me. Super excited to talk about all of those subjects, actually.
ADRIANA: Yay. I'm so excited to have you on. We had you for on call me maybe, and that was like a real treat. So I'm really happy that you're able to come on to geeking out. So, Abby, where are you calling from today?
ABBY: I am calling in from London. Despite this accent. London, UK.
ADRIANA: It's so cool to see where people are calling in from because there's always an assumption that it's like a North American focused podcast or probably American focused. And here we are. Super international.
ABBY: Yeah. I've learned from living abroad that if people are speaking with the English dictionary, I'm just super content that I can understand what they're saying. And I actually find myself completely missing accents all the time where someone will say, oh, the Scottish person. I'll be like, oh, shoot. I actually don't remember what accent they had or South African or wherever. And it's just. I'm just really happy when I can speak the right language with people.
ADRIANA: I can definitely relate. So are you ready for our lightning round questions?
ABBY: I think I have to be. Let's go.
ADRIANA: I promise they will be painless and fun. Okay, first question. Are you a lefty or a righty?
ABBY: Righty.
ADRIANA: Okay. IPhone or Android?
ABBY: Absolutely, Android. All day.
ADRIANA: All right. Mac, Linux, or Windows?
ABBY: I have all of them. I've been on Mac most recently with software development stuff.
ADRIANA: But which one do you like better?
ABBY: It depends on how fiddly I am being. So I did the Linux desktop thing for a few years, and it is fun to get into all the configurations and setups, but sometimes you just want to print something. So in that world, I'm a big fan of the Mac.
ADRIANA: Yeah, I feel you. I went through a Linux desktop phase and I was like, this is awesome. And then I'm like, oh, shit, I can't do anything. And this was back, I want to say, in 2007, where it was the.
ABBY: Year of the Linux desktop. Just like every year is the year of the Linux desktop.
ADRIANA: For me, the deal breaker was like, when I had a BlackBerry at the time and I couldn't use the BlackBerry app for syncing, I'm like, fuck. So then I ended up having. I had a Windows VM for a while. I ended up doing a Windows dual boot and then I moved to a Mac and not looked back since.
ABBY: Yes, I understand that.
ADRIANA: Okay, next question. Favorite programming language.
ABBY: Oh, favorite programming language. So I'm working in Golang right now. I've always been someone who looks at code as a problem solving thing. So I haven't really gotten too esoteric about the most perfect language I've written in. So yeah, I just like to work. I guess this comes from my roots as a consultant of that I've written C sharp, Java, JavaScript, Python, Ruby, and then lots of infrastructure as code languages. And so I just sort of want to solve problems in the languages that people are working in.
ADRIANA: I love it. Yeah, very nice. Cool. Okay, next one. Dev or Ops?
ABBY: Got to be Ops. I guess if you make me choose. I love the impact you can have in Ops. Like just the scale of impact within an organization that you have when you have a really nice operations to the process. So I've been on platform engineering teams for, I don't know, the last eight or nine years, so it's hard not to pick.
ADRIANA: I guess. Last week I recorded with Tim Banks and I asked him the same question. He's like, well, Ops runs the world.
ABBY: I suspect we'll get into what is the true difference between Devon Ops at some point later today. But if you make me have to pick, I'll pick my roots in Ops.
ADRIANA: All right, fair enough. Next one. JSON or YAML?
ABBY: I really like comments so I think I have to pick YAML, but oh boy, those spaces. That's a tough one. I'll go with YAML for the comments.
ADRIANA: Yes, I do appreciate the comments. Until someone pointed out that you can't do comments in JSON, which I knew but consciously was like, I think I've gotten angry at it before for not being able to do comments, but I'm like, oh my God. Yes. Two more questions. Do you prefer to consume content through video or text?
ABBY: Ooh, I'll go with video. But I will say that what I do is I keep a folder of different content on my phone of what I want to bookmarks or whatever to watch or to listen to or to read. And I just use them at different times. So I separate them not by content topic but instead by way of consuming. So if I'm going for a bicycle ride, it might be auditory something, and if I'm sitting on the train it might be reading. And so I do like a bit of both.
ADRIANA: But yeah, fair enough. Yeah, that's a really good point. Yeah. I was telling someone today, I love the audio stuff for when I'm doing busy work chores around the house or what you might call it, like going for a walk or for a run. Especially when I'm running. I hate and love running and it makes the time pass faster.
ABBY: I can answer that one much faster than all these. Hate, hate running. That'll be the quickest of all these lightning round questions.
ADRIANA: Final question is, what is your superpower?
ABBY: What is my superpower? I'm going to go with being able to energize other people if I'm going for a real one. I'm coming off the back of a very exciting tag rugby win last night for a team, and I unfortunately have a bad back and couldn't play. But the team just rallies in a way that I feel like I can help bring energy to the team. And so I did my part despite not being on the pitch. Yeah, I think that's probably it.
ADRIANA: That is a good talent and very translatable into the work world as well, right?
ABBY: Yeah, I think it works out okay. I mean, I'm sure there's times when it gets annoying. I'm very sure that's what all superpowers, right? They have their good and their evil. But I like to think it's more good than.
ADRIANA: When I remember when someone mentioned, oh, check out Abby's content. And I started watching your videos and reading your blog posts, and I remember you just came off with such infectious enthusiasm and just like, oh, this is somebody I'd like to chill with.
ABBY: And then we got to. So it was great.
ADRIANA: We get to see each other at KubeCon in November again, which I'm super excited for.
ABBY: So excited for a trip back to Chicago.
ADRIANA: Yeah, yeah. I really like Chicago, and I never spend long enough in Chicago to actually see it properly. It's the curse.
ABBY: Yep. The curse of traveling for conferences is that you're always like, oh, I'm going to this great city and I will see the convention center.
ADRIANA: If I'm lucky, I'll get to see the bean again.
ABBY: Yeah, exactly.
ADRIANA: Thanks for answering the lightning questions. So onto our regular business. So one of the things that I wanted to talk to you about is platform engineering. It is the hot topic these days. So I think, for starters, why don't you explain to folks in your view, what platform engineering is and how it differentiates from DevOps and SRE, for example.
ABBY: Yeah. So platform engineering is, in my opinion, and from kind of taking together a few different quotes from other things, it's a way of building internal services to support kind of the business use cases around an organization. I think that right now there's a lot of focus on how that impacts things like developer experience for software engineers. But I'm very specifically, I feel like the definition is a bit broader than that. It's about supporting the delivery of business value at scale with consistency and security and compliance in mind. And platform engineering is the act of putting that together into services that are consumable by the organization for those end goals. I think I have a talk at DevOps Days London, where I do just boil this down to it's internal services teams done better. So it's internal, it done with more kind of product mindset in a lot of ways.
ABBY: And I think where you start to differentiate between some of the other kind of buzwords and titles and philosophies that are out there, depending on what they are, is the way I've been looking at platform engineering recently is that it's an implementation of the DevOps intention. So with DevOps intention, it's to reduce the friction between silos. You looked at silos of software development and software operations and you wanted to improve the friction between that and the quickest way to do that. The best way to our understanding, was to remove the silos, ask software developers to understand their operations, ask them to figure out how to do on call and telemetry and all of these things, and simultaneously ask operations engineers to learn about software development and to bring automation to their processes and testing and all those kind of things. But that's hard. That is really hard because you're prioritizing the removing of friction over the depth of knowledge for certain people. And that sort of specialization value that comes from someone who deeply understands an area of the business or of the technology. And platform engineering, in my opinion, is also really hard just to say, but the idea is to productize those specialties and make it so that the silos can still exist.
ABBY: But you're focusing on the friction between them that's being reduced. So you still have your specialists, but they're providing a service to end users that they think about like a product, and they provide in a way that is easy to access and easy to use.
ADRIANA: Yeah, that sounds awesome. That makes a lot of sense. Now, follow up question. In your opinion, do you think that we've achieved what DevOps promised?
ABBY: So DevOps basically promised the idea of reducing friction on the software delivery kind of process or lifecycle. I think we are achieving that. I think we have less friction than when DevOps was born 1015 years ago, twelve years ago, whatever. Do I think that we are going to get more return for the experiences and processes we've put into place over the last ten years? This is where I think we're seeing a shift in focus. So the intentions of DevOps, we are doing better, we are moving our way, but if we keep kind of trying to drill into this idea of everybody builds and runs their full stack, we're going to lose the fact that, no, we don't. First of all, we don't plug in our own hardware. Most people, most people aren't both wiring up a server and writing the CSS for their front end. Their full stack is whatever their team or their company defines.
ABBY: And I think if we continue to think about the friction between the layers of value that we're providing and we keep trying to reduce that friction, we'll keep gaining benefits on this journey of DevOps. I don't know if there's an end state for DevOps.
ADRIANA: And that makes sense because one of the things around DevOps is like this idea of continuous improvement and there's never going to be like perfection, right? We always chase it, but we aspire to it. Software is never done.
ABBY: No. And that's what we're doing with platform engineering, bringing development to operations. We're making more software and we know software is never done. It always needs upgrades, it always needs improvements, it always needs coming back to, to make sure we're not customizing things that are now commodities. Right? So there's lots of things that you may have written a few years ago that now there's public packages to lean on and so you don't want to be maintaining that yourself. And if you don't do that, you very quickly get snowed under with the amount of maintenance you have on things that are not actually differentiating for you, your team, your business, your organization and all that. We're just multiplying software everywhere. And so we absolutely need the DevOps principles of reducing friction between teams and building and running the software that you are owning so that you have that feedback loop from production into your development lifecycle.
ABBY: I think we need that as much as ever.
ADRIANA: Yeah, I totally agree. And you bring on a good point in terms of like you may have developed this on your own in house at some point in time, but if there's something better that came along that solves your problem and then some, it ends up being way more awesome. But I feel like, and I fall into this trap before as well as a developer getting into this idea of like, oh my God, I get to build something cool and new and this is awesome. And then you build it and then you're like, shit, I have to maintain this. And then the shiny and new thing kind of just wears off and you're like, never mind.
ABBY: Well, this is the problem with the average tenure of employees being like two years, right? By the time the average cycle is you come in excited about your new job, you spend then maybe a few months getting up to speed with how things work and what's going on, and then you've got maybe about six months to a year of whinging about something that you hate about the way that things are done wherever you are and advocating that something change. And then you implement that change. And then you move companies or you move teams and it's like, well, there's somebody doing the things that you're complaining about as you go to these new companies. And I would hearken to guess that the people who come in after you have plenty of complaints. And it's just that learning about what creates that maintainable and kind of experience that you want to have as maintaining software is hard to learn if you don't spend years and years maintaining the same software. And yet that's just not how our industry right now happens for many people.
ADRIANA: Yeah, it's so true. We get bored easily or we're chasing the next shiny thing. Ooh, I get solved this problem. That sounds way cooler.
ABBY: Yeah, exactly.
ADRIANA: I guess the good news though is that there are companies out there that are working to alleviate some of the problems that developers and platform engineers and Ops folks are experiencing. And we've seen that with the umpteen different tools built to support Kubernetes, various platform engineering tools and whatnot. So it's been kind of interesting to see how much the market has evolved in the last 20 years.
ABBY: Yeah, it is amazing. And I think you say 20 years and that's absolutely true. But there's been even more explosion in the last maybe handful of years, five years or so. As you say, platform engineering is everywhere. And the reason it is is because that feeling or that interest in developer experience has grown tremendously over the last kind of four to five years. And platform engineering is one way to possibly address this application software development experience. And so yeah, I think you're seeing all these tools that are building off of the PaaS experience, the platform as a service experience that was, I think, first really popularized by Heroku in kind of the 2012 ish era, but now that's just commonplace that there's lots of tools out there that act in that kind of way.
ADRIANA: Yeah, so true. And on the platform engineering front, I wanted to ask, what do you think are some of the biggest problems that platform engineering is trying to solve right now?
ABBY: So if you listen to marketing, it's all developer experience, all day, every day. It is. How can the application software developers find what their applications are doing? They need a portal and they need to make their lives as perfect and glorious as possible. But I don't actually think that is the case. I think that is a piece of things that we're trying to solve with platform engineering today. But when you talk to the companies that, I don't know, make money in things, the big organizations, they're actually not always focused on developer experience as a top reason for platform engineering. Often they have issues like compliance and security and regulation, standardization and support as a key reason. Often they have cost optimization as a key reason.
ABBY: There's all sorts of reasons why providing a centralized offering as a service can benefit the business and is only auxiliary, supporting the app dev experience. But that isn't the reason for the work being done. And yeah, I don't think that gets enough press, right, because it's not as much fun as making a developer portal and things.
ADRIANA: That's so true. Yeah. I mean, every time we talk platform engineering, I feel like developer experience is almost synonymous with it. And then all this other stuff takes a backseat. But compliance standardization, so important, especially, obviously in any size, but especially the big corporations that have to worry about regulators and compliance and all that scary stuff, right? I mean this is serious business. So being able to cater to that, cater to security concerns, having a standardized way to ensure that things are locked down to your company specifications, so important. And as you said, not talked about enough.
ABBY: You've tripped right over one of my biggest pet peeves as well, where you mentioned that developer experience is like synonymous now with platform engineering in some ways. And also developer experience at this point is synonymous with a software application developer's experience. So someone who is writing a web app or a backend app, API app, something that is like Java or whatever, running in a container or on WASM or wherever, but the software side, they aren't the only developers. As I said in the Lightning round, I pick ops like I'm a developer, even though I write HCL code, even though I write bash, even though I write whatever chef recipes and whatever else on the back end. So I think the fact that developer experience has then I would say narrowed to the point where it's only application developers is showing, I think, in that explosion in kind of tooling and activity in the industry, because you look at all these kind of products that are coming out and they're all focused on how to get a piece of software out in front of an end user as fast as possible. But when you start to dig into how do I operate this thing, how do I build in my PCI compliance and my workflows and my marketing workflows and my customer success workflows and all these other things I need around the business, it all falls apart. And I think that too many of these forget that there's a whole other side of software delivery that isn't just writing software code. And that experience needs just as much kind of improvement, if not more.
ABBY: Because again, the leverage of that across all your software teams is huge. So yeah, it's one of my little pet peeves. You chipped right over it.
ADRIANA: Moral of the story, get some TLC. Outside of just developer experience, just app.
ABBY: Dev experience still can be developers even, but yeah, even that's probably too narrow. I agree.
ADRIANA: Yeah, very good point. Yeah, and you make a very excellent point also. You're a developer regardless of whether or not you're developing the application software or you're developing code to operate your system, it might be slightly different as to some of the things that you're concerned with, but at the end of the day, code is code. Technical debt still exists in both realms.
ABBY: And the tools you have impacting what you can create exists in both realms. I think I've been on the software side for many years as well. And on the software side, I've been in a situation where an internal team provided an API that my team needed to use to create a visual front end for. And the shape of the data that came back from that API absolutely influenced and even kind of forced our hands sometimes in just what we could create on that user interface experience. Because not being able to receive the data in certain ways or access it on certain pages or whatever, I mean, the same thing goes from the platform engineering standpoint. The tools we have, the baseline kind of bash and Goling and Ruby and whatever that we're using are forcing our hands to create what I think is actually not create developer experiences. We're exposing application developers to helm charts and terraform modules and chef recipes. And it's like they shouldn't have to know what languages we write, they shouldn't have to know what tools we rely on.
ABBY: But because they're all so primitive and they're all so low level. We're working so hard to piece these bits together for our business process that that's like as far as we can get on the platform engineering side or it feels that way. And so I think getting more, as you say, TLC to those platform engineers is only going to make better experiences for the application developers because they'll start to have a bit more bandwidth to be like, hold on, how are people actually using the stuff that we create? Is this the experience we want to give them? Is it about cloning a git repository or forking a git repository or something? Or should it actually be a different experience altogether? Something as a service behind an API or something else?
ADRIANA: So here's a question. How do you ensure that you bridge that gap to raise the awareness so that it's not just this developer experience, application developer experience centric view of platform engineering? How do we shift the conversation?
ABBY: I mean, we just need platform engineers to speak more about what they need and sort of get involved in the community. So one of the things I'm doing is I'm a part of the CNCF or Cloud Native Computing Foundation working group model. So the way it works is that there are groups with different focuses and they sort of narrow as you get down the model. And I'm in one of the kind of most narrow things, which is called a working group for platforms, and this is under the umbrella of app Delivery technical advisory groups, or tAg. And the idea is you want to be able to deliver applications. And one of the ways in which an organization can support app delivery is through the creation of a high value platform internally. And this working group is having all these conversations about identifying ways to speak to business leaders, CIOs, CTOs, CEOs about the value of investing in platform engineering experience and tooling to be able to support this kind of outcomes for them. So, yeah, get involved in the community, start kind of helping shape the conversation a bit more.
ABBY: Right. There's, I think, less platform engineering voice than there is application developer voice right now.
ADRIANA: Yeah, absolutely. And one of the cool things about the working group that you're part of too is it's representation from different platform engineering vendors or I guess practitioners. So you get different perspectives, different voices, sometimes competitors all working together, right?
ABBY: Yeah, it's absolutely. I think there's a heavy number of vendors and a heavy number of kind of consulting oriented people, but there's also a heavy number of kind of end user related people as well. So people who work at these large, successful enterprise organizations and are driving these initiatives internal at those organizations come and speak with the working group about their experiences, about where they're feeling like they need more support from kind of the industry or from tooling and from vendors, as well as how they're piecing together these tools to create the experiences that they are. And we always want to welcome more people with more stories. I mean, we're working right now on a follow on from a white paper we released in the spring, which was around the platforms as a definition, as a white paper. We're now working on making that a bit more tangible, with a maturity model to talk about how you can kind of evaluate and grow your experience with platform engineering in relation to that white paper. And we've been through one round of edits already, and I think we have something like 30 or 40 collaborators already, and we're going into our final edits now, and we're only seeing new people pop up every day. So I really believe this is going to be a global vendor agnostic, business domain agnostic piece of work that will hopefully help people have these hard conversations at their organizations and get the kind of support they need to be successful with platforms.
ADRIANA: Oh, that's really nice. That's really nice seeing the community come together like that. And what are some of the, I don't want to say grievances, but I'm going to say grievances that some of the practitioners come with when they share their experiences.
ABBY: Yeah, I think that it's often just not knowing what tools to grab for and how to interrupt them all. So each tool, it's in its own right, is interesting and exciting to them. But right now, there's not enough of an ecosystem around platform engineering. Everyone's sort of fighting to be like the one tool that rules them all and says, if you use us, you don't need to worry about anything else. And the reality is that most of these organizations really, at any scale, from quite early on, will have a fairly diverse need, right? They'll have front end apps and back end apps, which will often lead to different languages, though not always. They will have applications that are more on the cutting edge and are their kind of exploration applications versus their more money making applications. They'll have ones that are compliance related and ones that aren't. And so there's just so much nuance and diversity, and yet people are trying to still sell this monolithic idea of the one platform that you can kind of buy and use, and it's just not being realistic based on the feedback we're getting from people.
ADRIANA: It would definitely be lovely to have.
ABBY: That if you can do it.
ADRIANA: Yeah, that is a lot of stuff going on, a lot of different needs to cater to, which makes it very challenging.
ABBY: Look, if you can start as a small company with using a purchased solution and keep everyone on the rails on that solution, you will be very happy. Right? That is absolutely the cheapest way of doing any of this stuff. But the way that I try and describe it is it's basically like saying that you can use another company's processes for your company, and as soon as you have chosen to create any processes out of band from that kind of platform delivery mechanism, all of a sudden you just start that fissure and you just start that divide of what can be done on platform and what has to be done off platform. But again, if you start early with a single kind of monolithic platform as a service and you can keep everybody bought in that that's the right way to go, then yes, that is the cheapest. It's always cheaper to lean on a vendor and lean on a commodity product that has its own set of engineers who are supporting and improving the feature set than to try and build it yourself and maintain it yourself. But yeah, again, we're just seeing that that isn't proving to be long term viable for many organizations.
ADRIANA: Yeah, that makes a lot of sense. Now, what about taking the angle of even though each organization is different and has its own specific needs, we often find ourselves when we're moving from job to job that we keep solving the same problems over and over and over. And that gets kind of annoying because it's like, well, but I just spent like two years figuring this out of my old and now I have to do it all over again. And that sucks. So how can platform engineering help us with that?
ABBY: Yeah, I think there's kind of two sides to that, or two things I'm seeing happen right now that might help with that. It's hard without a glass ball, right? But one is that you look at the kind of ecosystem that grew around docker containers and grew around helm charts and grew around operators and things like that, and you can see how they're solving some of those problems in a community way, in a publicly available way. And I think there will need to be some sort of an ecosystem that continues to build those business solutions that can be shared across. But where it becomes difficult is once a business has solved it, how much do they invest in being able to make that public? It's the same idea as when you really want to make that kind of utility. You created open source and your company is like, but now you have to scrub the commit history, you have to do all these, create a contributor guide, you have to do all these things. That's true for all these solutions as well. So it's not always cut and dry. But I think that we are building ourselves bigger and bigger abstractions and maybe we will get ourselves to a point where we can provide those higher level kind of business cases out.
ABBY: The other side that I'm looking at is that we've all been here with all of the things that end up becoming commodities, like the number of times we tried to recreate the wheel on creating a user facing developer portal before Backstage came around and gave us a framework for doing that. The number of times we recreated the wheel with creating web applications that could receive HTTP requests and speak to databases before we got frameworks like rails or spring Boot or pick your language, pick your framework. We see that in order to coalesce around a common problem, there have to be a lot of attempts at solving it to really understand that it is the same. And I think you're 100% right that we're getting there with platform engineering, we're getting there with the fact that hey, we want to be able to give databases as a service, hey, we want to be able to give development environments on demand per pull request. We want to be able to update the secrets that our web app depends on as a service. There are certain capabilities that I've provided time and time again across organizations and I think we're getting there where we're going to need to do kind of more of a framework approach to things, right?
ADRIANA: Yeah. And I think that's really exciting prospect, especially when you think about things like renewing certificates, updating secrets. I've heard horror stories of certificates. There's one story I heard, I don't know how true it is, but at one of the companies I used to work at, a certificate expired. The guy who was in charge of the certificates was off on a cruise. Unreachable, not good.
ABBY: And it's probably one of those ones that you have to email someone and then they send you back a login to a secure portal to go download the certificate to then SCP it to the server. I've been there, thankfully not in an emergency situation, but I have been there.
ADRIANA: To be able to have tooling around that where you can just alleviate that problem significantly, because nobody wants to have to keep remembering how to do this. It's annoying, it's stressful. And sadly we tend to wait until.
ABBY: The last minute for it's because we have so many other fires to put out. But I mean, again, your Cert example is exactly why something like Cert Manager has become ubiquitous, right? And for any organization that hasn't moved their custom bespoke process over to something like a Cert Manager is they're being tied down and they're being weighted down by this need to maintain. Something that was very necessary before and was good that they created it. But now the best action is to move forward and start to lean on the commodities. I think I'm having a whole conversation right now with a few people about this concept of thinnest viable platform that was discussed in the team Topologies book, and the fact that right now most people are defining that really as just another word for minimum viable, as in how to get started quickly. You get started quickly with great docs, I love that. Yes, get started quickly by documenting and coalescing what you have on your platform. But call that your minimum viable.
ABBY: Your thinnest viable is always having an eye towards what can you offload to a third party that you no longer need to maintain. So it's not just about starting small and growing big, but it's about starting small and staying small and figuring out how you can continue to stay at only the highest level of value that you can provide and lean on as many third parties. Open source vendor I don't care to do the things that your company is not differentiating on. Lean on the industries for that.
ADRIANA: I like that a lot. It's time and money well spent. In fact, it saves you time. Maybe not money, but if you end up having to fork money over to have somebody else deal with it, because as you said, it's not part of your core competency, then so be it. Because chances are they probably do it better than you anyway.
ABBY: And that's exactly because just to say money is time. I was just reading a fantastic thread about technical documentation writers, or technical writers versus software developers, and how it was somebody's personal experience where they witnessed technical writers being let go for cost savings because the software devs could write their own dOcumentation. And the thread was all about this like cool. So what you're saying is that these people who make not even half as much like the tech, the documentation people, do not make nearly half as much as the software developers. You're saying it's cheaper to let them go and take the amount of time they spend on documentation and put it onto the plate of people that cost twice as much and aren't as experienced and therefore are likely going to be slower at the job than this. So you're paying somewhere. It can be off of the books, out of your bank account if you've got the ability to do that. And if you don't, sometimes you have to pay in, we call it like sweat equity or something like you have to pay in engineering time, but you're paying somewhere.
ADRIANA: Yeah, absolutely. It's funny how people don't consider, it's basically a cause and effect thing, right? It's like, oh, of course it's going to be cheaper because we've got fewer people on payroll and something that someone else can already do well, that's not normally part of their job. Now you're giving them more work, you might have to pay them overtime, or you're burning them out, both of them kind of.
ABBY: Or you're getting less from them on what value you expected from them than you were hoping. Right. And that might be what, you might have made that decision quite intelligently and carefully. Or it could just be that you're learning that the hard way. The side effects of that.
ADRIANA: Yeah, absolutely agree. So, switching gears a little, well, I guess related but unrelated, tell us a little bit about Kratix.
ABBY: Yes, I probably should disclaimer it as talking about frameworks. So I am working for a startup called Syntasso and we're building a framework called Kratix. And the idea is that pet peeve of mine about how platform engineers just get completely ignored in the developer experience kind of conversation is what we're trying to solve at Syntasso, they absolutely won me over as one of the first tires after the founders when they talked about being in the platform engineering domain and thinking about how platform engineers can thrive, not how the end users of the platforms get benefit. And I just don't think there's enough of that conversation. And this is the business domain I'm most interested in right now. So when we think about how do platform engineers thrive, I talked a bit about what I'm seeing in trends and that is what we have decided, sort of our first product to start to create. So it's an open source framework for creating business capabilities. So you think about a platform as a service, as a kind of a monolithic thing you might be able to configure, but everything has to sort of be delivered the way that platform that you purchased or that you're using works.
ABBY: Why people love that experience is because they want to have something as a service. Super easy consumable don't have to think about the maintenance behind the scenes. Someone else does that. Why they have moved away from products like Heroku and others is because they don't fit their business processes. With Kratix, the idea is that you can build anything as a service for your company relying on the tools you already rely on today, but leaning on the framework to be able to provide that sort of user interface, user interaction, that automation of the workflows, that scheduling to your different destinations, your different infrastructure, and kind of remove some of that heavy lifting from your experience as a platform engineer.
ADRIANA: That's awesome. Yeah. And disclaimer, I have played with Kratix before. I wrote was a promise for installing the OTel Operator so that it sends traces to Jaeger.
ABBY: Yeah, absolutely. Our first community promise provided. So first of many. So yeah, it was fantastic.
ADRIANA: Yeah, that was so much fun. And it was fun because I got to provide feedback on the product on something that was so new because I think you were mentioning that whenever there were promises for other tools, you guys wrote them yourselves. And I basically sat down with the docs and bugged you all a bit here and there to write this promise. So that was a fun experience. And it was also like my first experience with the hotel operator. So I'm like, what should I do? Well, let's combine platform engineering and hotel, because that'll be fun.
ABBY: Yeah, it was a great example though, right? Like that OTel Collector is itself a community provided tool that can significantly help internal organizations collect telemetry and therefore have Observability. And that's great. But where do you need this thing? You probably need it in at least more than one cluster, maybe more than one namespace within that cluster. How do you manage the deployment of that? How do you manage the upgrade process of that? Often you don't just have an OTel Collector, you have a fleet of hotel collectors, and you want them to be managed as a fleet. But our current tooling doesn't do that. Our current tooling is probably customized folders or Helm charts being installed in multiple places or something to that effect. And we really want that fleet management of OTel Collectors on demand and as a service, that's what you provided through that promise with Kratix.
ADRIANA: Yeah. So that was lots of fun, and I can't wait to play around some more with Kratix. I think the next experiment which you guys helped me out with was trying to install VCluster using Kratix, which I'm like, this feels like such a fun little project to come up with. And then that was neat because it kind of exposed some stuff that I was trying to do stuff with the product that wasn't available at the time. But then it's like, okay, well now I've provided you a use case for things that people might want to try out, right? Which I thought there was lots of fun, being able to collaborate with you guys on that, just being able to be part of providing meaningful feedback to a young product that's like, it's come along quite nicely since I started playing around with it.
ABBY: Yeah, thanks for that. You definitely weren't the last person to have that use case of wanting on demand clusters. And I think we talked about that platform engineering right now is pretty tunnel focused on application developer experience, but actually there's so much more to it, like cost minimization and eco impact minimization and things like that. And VCluster is a great example of where you can use that product to try and reduce the number of Kubernetes clusters that go up with all the kind of redundancy on the master nodes and all those things. And so what we did with that is be able to make on demand environments in VCluster for people. So instead of giving people a whole new cluster, you give them a VCluster. It's sandboxed, it's safe, it's less impactful on the environment, less expensive on your pocketbook. Yeah.
ABBY: As I say, you weren't the last. And we're working with some design partners right now. We have a few open spots. If anyone else is in this space and is interested in working with us on the product development stuff, it's all open source, Apache 2, licensed. We're not building in private here. We're trying to build for you and for the industry. So yeah, come have a chat with us anytime.
ADRIANA: That's awesome. That's awesome. Well, before we wrap up, do you mind sharing with some folks some of the things that are coming up?
ABBY: Yeah, so I'm not sure exactly when we'll be airing. So some of these things might be in the past, but over the autumn I'm speaking at a few events around London, which is really fun. I love being able to not have to travel and so I'll be at a AWS day and SiVo navigate and DevOps days London. I will also will be traveling to Hungary for a Housteff, which is a Hungarian testing forum, which is a nice return to my roots. I was originally a software tester and so it's nice to be able to go and connect back with that community and then I will be in November in Chicago, as we said, for Kubecon, which is super exciting. So definitely looking forward to connecting with people there.
ADRIANA: Very nice. And the thing you're doing in Hungary, that's the tutorial with TraceTest.
ABBY: It is. Speaking of an amazing kind of feedback loop with a great new tool. It's not that new actually anymore, but they still are just so responsive to any questions and ideas that we have that I have. And so yeah, I'm doing a keynote about observability and have created a new tutorial around using observability with trace test for the testing audience because I think that will really kind of connect people who aren't typically in the observability space but are in the testing space with connect those two dots together. So yeah, really looking forward to that.
ADRIANA: That's awesome. Yeah, I can't wait to catch the recording for that. I hope they'll be recording.
ABBY: I don't know if they'll be recording the tutorial, but I am doing it on instruct so I can definitely give access to it. It's all kind of open source tech that we're going to be using. So the team at Instruqt have been so good about providing access for the community driven activities like this, and they just have such a great platform for creating content and so really makes it a pleasure to deliver.
ADRIANA: That's amazing. Good to know. Thanks so much. Well, we're just wrapping up, but before we do, do you have any parting words of wisdom or hot takes to share with our audience?
ABBY: Parting words of wisdom, I guess when it comes to platform engineering, just remember it's an engineering, it's software. What do we need to make great software? We need to think about how to build and run that software, and we need to think about the end users because it's a product. And so whether our end users are our colleagues or our friends and family or someone else, they're still customers. And yeah, it's a product. So I think that's really the shift in focus with platform engineering in my opinion.
ADRIANA: Awesome. I love it so much. Well, thank you so much, Abby, for geeking out with me today. Y'all don't forget to subscribe. Be sure to check out the show notes for additional resources and to connect with us and our guests on social media. Until next time...
ABBY: Peace out and geek out.
ADRIANA: Geeking Out is hosted and produced by me, Adriana Villela. I also compose and perform the theme music, Trusty clarinet. Geeking out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento.me/geekingout