PurePerformance - Platform Engineering is not just a trend and why Terraform is not dead with Artem Lajko

Episode Date: August 11, 2025

Did you know that the average salary for a Platform Engineer is 42.5% more than a DevOps engineer? But why is that?We sat down with Artem Lajko, CNCF Kubestronaut and Ambassador as well as Author of the book Implementing GitOps with Kubernetes. We dive into the role of a platform engineer, the common pitfalls in implementing IDPs and why Backstage and AI won't solve all your problems. And we touch upon a topic hot off the press around Terraform: Its not dead!Links we discussedArtem's LinkedIn: https://www.linkedin.com/in/lajko/Talk slides from Cloud Land: https://lajko10-my.sharepoint.com/personal/artem_lajko_dev/_layouts/15/onedrive.aspx?id=%2Fpersonal%2Fartem%5Flajko%5Fdev%2FDocuments%2FAttachments%2Fcloud%20land%2D2025%5F%2Epdf&parent=%2Fpersonal%2Fartem%5Flajko%5Fdev%2FDocuments%2FAttachments&ga=1State of Platform Engineering Report: https://platformengineering.org/reports/state-of-platform-engineering-vol-3Upjet GitHub Project: https://github.com/crossplane/upjet

It's time for Pure Performance. Get your stopwatch is ready. It's time for Pure Performance with Andy Grabner and Brian Wilson. Welcome, everyone, to another episode of Pure Performance, As you can probably tell, this is not the awesome radio voice from Brian Wilson. It's just the voice of Andy. Unfortunately, Brian had to cancel today. He's not feeling well.

So we wish him all the best. But by the time this airs, hopefully he will be recovered. And we will have already recorded yet another great session. But I typically, we start with a joke. But I want to spare the time and rather actually go straight into the topic and actually introduce my guest today. I met Artem at Cloudland just a couple of weeks ago in the beautiful area north in Germany and the northern parts of Germany in Soltow at the Cloudland Conference. And then again, just two days ago in Munich at the Cloud Native Summit, Artem and I, we are both sharing the passion for platform engineering. But there's a lot of other things we figured out that we are passionate about and that we share.

And this is actually today's discussion around platform engineering. We talk about the latest things that he has seen. There will also be some discussion around Carol from his day, yes or no. So I think this is something we want to discuss as well. But without further ado, Artim, thank you so much for being on the show today. And maybe let's kick it off with a little bit of an introduction. Hey, everyone. Thank you for having me, Andy.

I keep an introduction short. My name is Artem Lyko. I'm working as platform engineering, of course, because. No, you're not doing a DevOps anymore. You're doing platform engineering or you relay able yourself. I'm working for IITS consulting. It's a startup from Germany, founded 2019. We have about 160 employees, so we are not a real startup anymore, but we try to keep

the culture. Then I am certified Kipsonaut, try to keep me educated, not to lose the tracks on the market. And I'm as an ambassador for platformengineering.org, try to understand the pain of different customers not on the business side also on the worldwide side because of platform engineering ambassador you have also insights to companies from the USA not just Europe and I'm a co-published auto of the book implementing GitHub's with Kubernetes because getops is the glue for platform engineering and put some insights over the years into a book with a friend of mine it's really yeah it's

really amazing writing a book we were both holding our book in the air when we took the screenshots for our for a thumbnail here writing a book is not as easy as it initially sounds right what was your experience my experience was short nights a lot of stress but after it was published it's what's like I like it it's as worth it but I don't know you really was writing about I think three or four months full time so yeah it was tough time how it was the experience for you I mean we've written with just me and pietro and i think uh at your books you are three authors so with three authors yes max kerbecher who also who you know right from from munich

and then also hillary lipsick yeah we we kicked it off the idea in march of last year we started writing i think in june or actually end of may june and our our deadline was mid of august so it was it was also two and a half three months intensive work we think we did a good initial prep work and the vision of how we are separating the chapters and the topics but overall there was a lot of coordination work because you want to make sure that when somebody reads the book that it still makes sense and they're not contradicting that we're not repeating things that we're not missing things out right this was a good because you think it because you

have three authors two different writing styles so it's a little bit difficult to think and also to have all the stuff like it's sounds like written by one person because we have struggled at some points with some chapters with pietro and it's it's not sounds like so you don't have our flow and then we need to refactor it it's it's for stuff and i mean with three autos it's gonna be another challenge but yeah really really nice you're writing seriously i think and then you're zing everything as three autos exactly yeah we also did constant reviews so we always we had a shared google drive where we kept our work and then try trying to stay on top of what the others are writing and then also with this getting some inspiration. Yeah, I was hoping to grab a copy assigned one in Munich, but, yeah, not enough books. There will be maybe another chance at another event coming up. Yeah, but let's talk about stuff that you are doing. And I was really fascinated when I saw you present with one of your colleagues, I think, in the Cloudland, right?

with Alex Huffed, one engineer. Yeah, and you were presenting on the topic of platform engineering. I think you have the opening, one of the opening talks at the conference. I then followed a little bit later with my thoughts on platform engineering, with a little bit of a live demo as well. And there's a couple of things I want to pick out from your presentation. Because I think overall, when you are following what's happening in platform engineering, right now after several years,

I think there's a clear understanding or some certain things that are repeated all over again. So platform is a product, is a very important piece, keeping the end user in mind when you're building a platform self-service. What I thought was interesting for you, one of the slides,

and I'm scrolling down because I want to get the stats right. You talked about how platform engineering in DevOps also has a huge impact on the salary range. And you were comparing the two roles, but you're also comparing U.S. and Europe. Can you fill them in the audience and talk a little bit about what you have observed there? I can try it. The numbers coming out from me, I'm using it for Platformengineing.org because the analyst the market on the USA and Europe. And the numbers is showing if you're doing, for example, DevOps, if I remember try to earning in Europe, something about 80.

90k US dollar and in the USA it's going to be about 150k of course depends where you're located and platform engineering was something about when we tried about 100k and you a 200k 200k compared to it and from my point of view and also have some exchange with cube careers and also asking if you're hiring platform engineers that not just building managed infrastructure like for example you're building some you compose with terraform with ham charts depends on your infrastructure and also on your cloud provider, whether available or not. So you need to have these skills. And also you need, in my opinion,

to have some software engineering skills to put it in a product, not like trade it as a product, but you need to create it something. You need to know how to create features and all the stuff. And the most engineers coming from a system engineer background, cloud engineering background, don't have it. So I can just try to explain the numbers. So you need to have the skills of a system cloud ops engineer,

combine it to a software engineer to build a portal, a platform, however you call it, with a self-service approach. And you are not building anymore for yourself as an end user. You are building it for end users. And it's a difficult mind shift. Also for me, I have a software developer background. And if I'm building platforms, it's easy to build it for you.

Like you have your custom, some play rules, and enable the developer to play on your castle. But if you are building, and provide it for them and they can use it, it's cost you a lot of time. And I think because of that, if you're doing real platform engineering, the numbers will be if you hire people,

it's going to be about right. And we have to compare it. We have last year, we have about 4,000 applications at IITS, and we just hire 25 people from that. And I don't found the profiles I will need to build a platform engineering as a product code it's described in the books. And so I think, yeah,

the numbers are going to be maybe right, maybe not 100K now for a year or platform engineer with this kind of experience. I think this is just my opinion or my scope for you on it. I don't know. How do you see it? I mean, you have also building platform at dinah trace or try to integrate everything. And I mean, you have a similar requirements for hiring for the people and also in. I think, yeah, I think you're spot on.

I think what your observation is, right, we have a lot of very skilled people that know how to build automation to solve their individual day-to-day tasks. The challenge is how can you build something that can be used as a self-service by many people with different skills in your organization? And I think this is the big challenge and where I believe this is why you're spot on if you are in a platform engineering team.

I'm not sure if you need every individual member of the platform engineering team to have this broad capabilities of being on the one side, kind of like a marketeer, a product manager, an architect. But I think within the platform engineering team, you need to treat it as a software product that needs to be successful. It means you need to figure a way to build something

that helps not only one, but many in your organization. And also you need to build it in a way that they want to use it, because if you build something that is hard to use, doesn't solve the problem, then the result will be that they will go off and build something themselves, or they find some other solutions, download something, use an external service.

And then you end up with the actual problem that I think Plattsum Engineering wants to solve is reducing the complexity and providing a standardized way of doing things instead of having five different tools that essentially try to solve the same thing. Totally agree. And also, I think you have to need a product mindset,

because for me, I don't have a product mindset. I was never working as a product owner, something like this. and now you are building something. It's going to be a product, not like a lot of people are going to and rephrase it, going to the talks, reading the right book and say, you need to treat it as a product. And say, can you explain me and simple words for an engineer what I need?

Yeah, just the feature and all the stuff. I said, in my opinion, I think you need a product owner for your platform because the most engineers I'm working with don't know how to build a product, not just because lacking of skills and software engineering. You have another mindset. I think you need also treat it like another product you build for a customer to solve their pain or if you're providing a cell solution or something like this. So also

I don't find many companies I found I think just two they have we hiring also product owner with engineering background. No also the telephone infrastructure is code parts the Kubernetes part and know how to build a product and I say I think this is

also a missing piece if you try to build something like with a self-service for different stakeholder you need a product I think I guess I don't have one at the moment. Well, I agree with you. Now, there was one, I was just trying to look it up.

There was one presentation. I think it was in the morning of day two at Cloud Native Summit on Clapton Engineering. I remember his name, but I'll try to find it and then put the link into the description of our podcast. He also talked about Plebslems engineering, some lessons learned. And one of the things he had a bell curve, and he basically had a really interesting message he said, you need to solve the problems for the 80% of your engineers that are currently struggling. And yet the bell curve with the 80% in the middle, but he said, the most common problem is

that you don't talk with this 80% because these 80% are often the quiet ones. You typically listen to people that are very vocal. They are very invested. And it's typically the ones on the outside, left and right. And it's those that have very specific, very niche problems. So I think he had a really nice slide that talks about don't listen to the loud noises, try to understand what the 80% need and solve the problems for the 80% and not for the 20 others that have very specific use cases and have a completely different mindset anyway. So I thought that was also really interesting. Yeah, it sounds really interesting.

I also need to take a look on it. It sounds like, yeah, you need to try to reduce the cognitive workload of the 80% that there's a page. to understand the pain and then maybe you're getting some adaption and because you heard also a lot of presentation like nobody use our platforms we built a platform and nobody used to yeah of course like you say or like the colleague was presenting the talk i also not attending to the talk but i will um making my homework and looking after our um podcast into the talk because i want to learn and i think also um ab thanks are from st tasso we're also doing a really work understanding the product mindset and also the pain of the market they're also giving a talk i

just saw it on youtube but i don't take a look on it and they explain what product mindset means and how you put a product owner into your platform and also my to do with between all the 300 hours other links yeah which also reminds me i need to add i we had ebb bankser uh on a podcast a couple of months ago and we also had the name currently escapes my mind on the late on the last episode also from Cintasso, the CTO and founder I think we had him also on on the episode here to talk about PLEPSOM engineering but yeah lots of lots of interesting people to listen to now I mentioned in the beginning plebsome is a product we heard a lot about it so we agree it is really important for success Now, I want to shift topics just a little bit

because there's one thing that you had on your slides that I also thought I would like to get more insights from you on. You talked about the five common pitfalls to avoid when building an IDP, right? Because for me, it's always interesting to talk about what things are not working well, what have we learned? When Brian and I started this podcast years ago, we talked about the top performance problems

that people built into the application because Brian and I have both a performance engineering background. So we talked about what can go wrong, what did people do wrong? And so I'm also interested in diving a little bit deeper. What are some of the problems that you have seen in your life as a platform engineer and in helping organizations building platforms? Yeah, of course.

I try to share it. It's starting how we learned so much because I just put, I think if I remember I tried at Cloudlet, I just presented three on the slides are five. and sometimes I also until 10 and I think two years ago I started a blog because I was overwhelmed what is IDP what is the platform engineering staff and just drop it and then I have an exchange about I think 100 200 people at the moment with some product builder and also some end user and collecting also for our customer all the common pitfalls and the easiest one or the most one have I think 90% in common it's going to be ignoring the education gap. I call it. What I mean by that is, for example, if I'm joining a customer and we are speaking about just, I don't know, what's mean cloud native? You're asking or platform engineering, you're asking five people, you get five different point of use. And that's what I'm

also missing. And I say, okay, let's now create a common share terminology. So, because if you try to build something in your company, however you call it, it doesn't matter. But if you try to build it, you have an education gap on different areas. You manage, have more education gap than the engineers, maybe your software developer. I have also some education gaps. And then we have find out since the most company, before they started to build something,

they having a commitment on wrong terms because of the education point. And then they are building something. And after they see a proof of concept or MVP, they say we don't want it. And the other side, we also don't want it to build it. And you say, yeah, first start with the education gap. I mean, you don't need to be an expert on IDP. and turn the web platform, portals, or another stuff,

just try to creating for you company a common understanding, but not to reinvent the wheel and also create a lot of acronyms, because in Germany we love to create acronyms, nobody can understand, but we have a lot of them. And everybody knows what it means. I mean using the terms from the market, but creating a common understanding what it's mean, for example, if you're using Cloud Native,

because I was attending to one meeting, I have an infrastructure team, I have a management, and they said we want to build it, Cloud Native. As the infrastructure teams say, yeah, of course, we're going to build it because Cloud native for them was to build an application with a Factor app. And you can also run in on-premise.

And for the management, it was Cloud, it was a public cloud. So if we are building Cloud native, we are going to put it in a public cloud. And they have a common. Yeah, we agree. We agree both sides. And I was an intermediator. I say, wait, they want to build it on premise.

You wanted to build it on the Cloud. And the management say, hey, what do we mean by that? I say, yeah, exactly what I think. say and they're looking at the infrastructure team as it's right to say yeah cloud native doesn't mean you have to build it just for the public cloud or hyperscale or something like this and this is what i mean by creating a common understanding so every talk every workshop i'm starting i'm spending five between five and fifty minutes to create a common understanding so you have uh input output you can work on it and then you can maybe create your plan and build whatever you like however you call it

And I think it's going to be one point, lack of a share terminology. No, and I think most of us have a story like this. I have one on Dora where I had a long discussion with somebody at a conference over lunch, and we both talked about Dora. Or I picked up Dora from him and then I joined the conversation. And then after five to ten minutes, we both figured out that I'm talking about the Dora DevOps metrics that they develop efficiency and he was talking about the digital operational resiliency act of the European Union. Yeah, similar openings with IDP.

Identity provider and to develop platforms. Yeah, it's also going to happen for you. IPA meeting day in the morning with people from Australia and one in the meeting asks, what do you mean by IDP? Identity provider? I say, oh, no, into a developer platform. So yeah, it's very important to making clearance and also not just use the acronyms, or if you're using acronyms, maybe to say one sentence, what you mean by that. So you have a common understanding. But yeah, as you say, every one of us, I think, have a lot of stories to share about common meaning. This understanding on wrong terminologies, terminologies.

I think especially as we're operating, as you just mentioned, you had a call with Australia. If you are dealing with international, with a diverse group, with different language backgrounds, with different cultural backgrounds, maybe some acronyms mean something different in a different country. So it's always good to start with defining what you really mean, so that we all have a common understanding. So you called it the educational gap. I really liked it. You also have a very expanding meme there with the hobbits. So, folks, the presentation that Artem used, I'm not sure Artim if you allow me to also link to those slides, let me know, then I can also link to the slides. Yeah, please.

Sharing is caring, so I try to share everything if I have nothing to hide. So, yeah, please. Perfect. We'll be doing your favor if you shared. Thank you for that. We'll definitely do that. What are some of the other kind of pitfalls that you have identified? We have identified also one, something I call building on an unstable core.

It's mean, for example, if you have back workflows, because I have some project. And if I'm going to the project, say, we want to build a platform. And I say, show me, please, you bootstrapping. How do you bootstrap your platform? And I was identified really just simple. Some swim lanes, some to do. And I say, we are doing here, 20% click ops. You're doing some power shell scripting.

have a infrastructure is called here we have for example something ham chart and also stuff we have fully automated I say yeah but you have 20% on the click ops so why do you want to build a platform first start to focus on your workflows improve for example removes the click ops remove the power shell so you have for example infrastructure is code ham charts whatever so you can use it focus on your workflows not just on the next abstraction layer and try to build on top of it because you need to remove the bad work close or improve it, and then you can go in the next part.

This is what I mean. If you, for example, if you try to building clay on layer and you have an unstable fundamental or ground, it's very difficult for you later to improve it because it's going to hide a lot of bad complexity. And if you have a portal, you click on it and you're looking behind the scene and say, oh no, I don't trust the system. And also we are learning in Europe, for example, if you want to using a stable core, it's means from the beginning. to understand if you are in a regulated area and you need a lot of certification testates, I don't know, BSE, C5, type 2, and all the things we love as engineers. And you are using, you're choosing the wrong provider for you.

Then you need to refactate and to migrate it in the future. We are seeing about, I think, 50 reference architecture every year. And a lot of companies coming to us and say, we are making the wrong decision. We are choosing the wrong cloud provider for us. we need to migrate it so before the workflows part started it started with your ground your choosing so also this is what i try to tell the people you need to focus on your core to understand what can i choose i mean we also will not build our house in some area it's not stable i think the most of us is similar with your whatever you build on top of it and this is also i think

i called it a building on an unstable core something like this yeah because they are the more unstable the core, the more effort you will have to work around all the instabilities, and in the end, you're not getting the value out of the stuff that you're building on top. Yeah. I also liked your image there. The guy who is working out with huge muscles on the upper body, but then very tiny legs was really, really interesting analogy. Yeah, I like, never on the leg day. If you're going to the gym, something like this. Exactly. If it's a lot. like the everyday. Yeah.

Yeah. Yeah. Yeah. Then I know you didn't cover it, but maybe we can cover it today because it comes up a lot in my, in my conversation is around the backstage. Yeah. Yeah, I have to skip it because we are running out of time at the Cloudland. And we have, I think we call it use backchers or just use vacations, something like this,

because a lot of people are coming also to us and say, yeah, we're just using Backstages. using backstage. I say, okay, tell me more. And then I say, do you try it? No, I'm going to try it today afternoon. Say, try it and then come to me and tell me more. And then they're coming and say, just just last uses backstage doesn't work. I say, why not? They say because it's like you have an archive, you an archive it, and then you have a framework of a lot of libraries and you need to build it your own. You need to using plugins. You need to build everything. And then you need to put it in a Docker container if you want to deploy it for. example, on Kubernetes, and then you need to fix the imager.

And every time you need to fix it or every time you need, for example, a new plugin, you need to go to the code, import the plug-in. I say yes, now you understand. Backstage, if you're going to the site, they say you, it's a framework. And I mean, every developer, this is also the pain point with system engineers. They never develop software. If you're speaking to a developer, developers say, of course, it's a framework. You need to build it.

But with system engineers, they say, we just use it. Because you have also a community handshot. Now, if I remember it, right, exist. They say, we just can't deploy it. And so I say, no, you can't just use Baxage. You need to understand it. You need to integrate it. I never say Vexage is a bad solution.

I really like Baxage, but you need to learn it. The learning curve is a little bit tough at the beginning. You need to understand what you have. And I think it's the best solution on the market for Salesforce that you have at the moment now. As far as you have, of course, something like Port or Cortex, really nice solution. But if you need to self-horses it, because you're running on an air-gap environment or on edge, and you need by your own. So I think backstage is at the moment the state of the art.

I mean, it looks like 2020. It seems like 2020, but it's the best solution we have. I guess it was built in 2020, I guess, or even before that. That's why it looks like it. But as you said, it solves some really important problems. Like most people, I think that started with backstage, it's around the overview. the software catalog to really understand what you have in your organization, then the self-service onboarding is obviously with all these workflows that they have is really good.

But yeah, you made a good point, especially with depending on who you are, what role you have or what background you have, you may think that backstage is just something you install and that's it. But if you have the skills of the software engineer, if you have the understanding, then you know it's very powerful, That is the framework and you need to build on top of the framework. Yeah, if you need to like, I think it's React written and so, yeah. And the most system engineer or Cloud engineer or DevOps engineer and our platform engineer, the most I know they are never touched React in the most cases. But it's a really nice tool and I mean, but like you say, the most, we are also using it.

For example, some customer building it as a common portal for everything and they started with some documentation. So every news I got putting it or something to explore your catalog. You can explore all the services your company provide. And then they start to integrate step by step using the plugins, understand it, looking at the market. And like I say, I think it's the best solution we have at the moment. If you try to building something self-hosted and also building templates.

I mean, critics also or Sintazio shows it. They're also using backstage and port to create promises from the real world and then integrate it as a template and you can click on it and getting the resources you need. I mean, it's really nice, but you need to understand it. Which brings me to, I think, you're number four of your pitfalls that you had.

You also didn't get to it, I believe, but I think it's a very important topic because we often, and I got criticized for that, because when we do demos and we show backstage and we show a self-service onboarding workflow with a new app, and all of it works smooth and nice, but how often do you onboard a new service? once in the lifetime of that service.

Yes. So the question is what happens afterwards. I think the point you have mentioned, it's about day two operations. How do you handle day two operation? Because there are all the demos we are seeing on all the conference or unconference. It's about I have a backstage, have a port have a template, day zero, day one operation, and then it's works.

And then you're saying, for example, I have, I was, it was I think port, if I remember, I tried. They created a template. You have a platform engineering team. We have a developer. the team. And you have four or five developer teams. And the platform team created a template with Kubernetes, with a managed Kubernetes with some databases and another stuff. And they provided to the developers, the developer taking a set set site, click on it, getting so everything they needed. And then they provided for their two operations, a new version. And I think three teams using the new version upgraded it to the, I don't know, it's going to be upgrades the Kubernetes version and another stuff. And it works. And one team, using the template and its breaks. And then they say the platform engineering teams are responsible for it.

And the platform engineering teams say, no, we have here three another teams. It's working on it. And I take a look at it. And I'm seeing, for example, the developer created port disruption browser. Something will require one, but they have a mid-replicate of one. I mean, it's the purpose of Kubernetes to block it. And something, if you try to upgrade it, it's going to, you're getting time out. And so I saw it.

And I asked the developer, you know, you have a misconfiguration of the service. So the template doesn't work. And now you can discuss it because the developers say, yeah, but the platform engineering team need to cover it. I say they can because the purpose of Kubernetes is if you define for critical workloads, PDBs and you don't want to be disturbed like it says, it's going to block it. You can't just upgrade it for your workload.

And they say, yeah, we understand that. But they need to, for example, cover some health checking some notification. I say, yeah, it's a learning. But they do operations to cover it very difficult. And they ask me, can you explain to us in other terms? I say, very easy. GCP, Google Cloud Platform are using it because they have the platform inside. I say, if you're going to GCP and you're creating a service and misconfigure it,

going to the GCP team fix it for you? They say, no, because we make the mistake. I say, yes, of course. This is a similar example. What do you have now done with your platform engine teams? They provide you a platform with a template, you misconfigure it. You break it. And why they should fix it for you?

And they say, yeah, right. So we need to speak about this. the day two operation and it sounds easy but in some cases it's not it is what i saw from a project they also was thinking now okay the day zero day one operations are really nice but no one or just a few people maybe speaks about the two operations and how things breaks and how the shared responsibility is on our platform if you provide templates and if you where it starts and where it ends on the both side you don't have the right answer you can say it it's fixed.

Yeah. No, I think that's, as you said, it's also a learning thing because, and it's a definition thing. So what are the responsibilities of both sides? And also what do you expect the platform to cover and what not? How much extraction do you put in? How much freedom? It also then goes with the freedom, right?

Because the more narrow, the more narrow it down what people can do, obviously the safer it becomes, but also the less agility or the less. there is autonomy you have. So it's an interesting, I'd really like your explanation though with Google, where you say, you know, do you open up a support ticket with Google just because you misconfigure something? Probably not because you can,

but they will not tell you or just ignore it. I mean, if they are frankly, they will point out it for you and showing, if you make the mistake and showing user documentation how to fix it or what you have misconduct, but they don't going to fix it for you because it's right. For all the listeners, right, if you think about platform, building an internal platform,

really sit down with your engineers, also learn on, because if, let's assume, this example that you brought, right, if you have a large organization with 10, hundreds of teams and a high percentage of them always run into the same problem, that they make configuration mistakes in their YAML files based on the templates, then maybe it is time from an overall efficiency perspective from an overall stability perspective to think about how can you prevent this maybe then something like a health check makes sense but this is the constant learning and the constant evolving of your end users your internal development teams in the process of how you're evolving your your platform your product like because every product right a product not necessarily doesn't it doesn't have hopefully doesn't have a an end time right a product evolves right It's not a project. I remember Max Purbacher, who I wrote the book with, he was very picky in the book around a platform as a product means it's constantly evolving.

If you think about a platform as a project, it has a deadline. And at that point, it's, you know, it's done. You deliver it and then it's done. And so I think this is also the product thinking that you're constantly evolving and constantly making it better, because you constantly learn from your users on how they're using it, how you need to make it better. And also, maybe there's new use cases that are coming in.

There's new technologies that are coming in that you then also want to support. Totally agree. And if I remember it's right, I think it's going to, it was Gregor Hopper that say, be happy if they break the things because it's an indicator for you that as they're using the platform. I think he was using other words, something like they're going to build and surprise you and you are not expected of things. you can i think also translated to if they break your platform be happy because they're using it exactly

exactly so you have a kpi for this part they're using it so don't be angry say thanks agree on that and then make a new iteration and fix it and make it better like a living product like you already explained so yeah that's what you send to there and i think this actually brings us to the fifth point that you have um because it goes into measuring terrain you have the impact that you have found like impact could be how many people are using it I think that was your your fifth pitfall that you mentioned yes yeah if I remember it's going to be something about and how do you measure failing or something like this and the most company was like we try to create Dora matrix

KPIs and all the stuff and in the most cases what I am doing or we are doing is if somebody not using the platform we try to build our platform for developers if We are speaking about developers. We are speaking about multiple stakeholders. You have, I don't know, the security team, depending on the size of the customer we are working for. It's, you have the cloud engineers, you have security teams,

you have Phenops, you have, of course, the developers, software developers, software engineers. And then what we are doing, it sounds sometimes weird. We are doing a shadowing or internal shit, something like in the teams and looking how they works. So we measure the KPIs by just shadowing and asking them ways that pain point understand it because in some cases you have teams they have another pain points and if you're building a platform or portal or however you call it for the developer and they don't accept it it's not because you build it wrong sometimes the cognitive record is so high and there have a lot of other problems and maybe you need to solve it first to understand what the pain point is to solve it so because of that every time i say i think the most time or about 99% i say just ask you developers understand the pain point solve it

Then they have reduced a cognitive workload. Then you can understand they have time to explore your platform, what you're building. And also, if you're building for them, you will also getting some insights and see maybe observability at the moment not the right part. They are figuring out how to build Sika container. So I don't know, try to integrate our golden paths with our Argo City workflows or

another pipeline tools that it's going to build with build cats, see a container for them, something like this. I learning a lot, not just only from the development, also from security teams because if you are joining security teams in Germany, the most security teams don't have a developer background, have a little bit of the system engineer background and they're doing a lot of compliance and the most don't understand our cloud native world and how it works. So it's scary for them and but I mean they are part of the organization and you need

also to understand, for example, if you, I don't know, allow O1 template to deploy the developer software or a Kubernetes cluster or something like this, it's going to be compliant, you need some policies that you have cover with the company. And then if you say, OK, now I understand your pain. We have, for example, Kiwern as a policy engine, we can enforce in every hour template, everything you like and taking the pain point. So this is what I every time and say, just ask you, developers, not software developer, the most stakeholder of your platform.

You don't need to ask them all because then you're never starting to work. But here, try to understand the real pain. And then you can, of course, integrate some KPIs because you need it. I mean, you're putting a lot of money on building a platform team. And I mean, we are speaking, we already spoke about the numbers. If you establish a platform team, you need be maybe between five and eight engineers for 24 seven on call duty. Some infrastructure is going to cost you one million. I guess it's not less. I mean, we are looking at the number 100K on one engineer, you're having five until eight, some infrastructure.

So yeah, you also need some KPIs for the management because why do you need a platform if it's not provider value. But first, try to ask your future user, hopefully. Cool. So thank you so much for going through these five common pieces. For me, this was one of the cool things that I remember from your talk besides everything else that you could send. So folks, if you are listening to this, make sure to check out the link to the slide. also connect with Artem and LinkedIn. You see a lot of the content that he and his team is producing. I want to just quickly touch based on one other topic

because we're getting at the towards the end of our recording year. But there was one thing we discussed in Munich. We were sitting kind of like listening into a talk. And then you reminded me about some new reports that came out. I think from platform work, there's a report that came out on the state of of platform engineering, then I think you referenced another report and also a LinkedIn post from Christian Shelle, from Sebastian Shelle.

We also had him on a podcast a couple of years ago, and I will just use the same provocative sentence that Sebastian used, and he said, terraform is dead. Now, why will we bring up terraform now? Obviously, Terraform or everything is code, infrastructure is code, deployments is code, observability is code, is a very big topic around platform engineering, because this is how we can really automate, how we can ensure consistent systems.

Terraform, obviously, is a big player in the market. But there's obviously been some quite change over the years. New tools are coming out, obviously, a lot of things that happened around open sourcing. open tofo but from your perspective what do you hear what do we need to know around terraform and around infrastructures crawled in the realm of platform engineering what i'm getting from the numbers from the both state reports the one is going to be if i remember i tried state of platform engineering volume three from platform engineering org just

published a few days ago and another one was the state of gettops from octopus deploy if i remember right and I was looking at it because a lot on the market say telephone is that I say okay maybe and I'm looking at the numbers and the numbers say 70% of the companies I think in the one report it's going to be say 68% in the one hour on it's what's going to be about 70% say the people still using telepharm and I can also agree on that the most of the customer we're working with they're using because if you're not running on a hyperscaler like Azure or AWS, you can just use cross-plane. If you want to use cross-plane, you need to object your terraform.

You terraform, I don't know how it's called it, your terraform models, or you need to build a provider about it. I never done it. I just saw the example, so you can update it. And you don't have the solution at the moment, in my opinion, between we have the cross-plane part. It's going to be about from the adoption rate, about 5% and 8% on the market. You can use it, but I'm working at the. the moment for the most, with European cloud provider, and you need to update it.

So you need to hire people again, the topic. You need to hire people with the right feel set that going to object, that understand Kubernetes, understand infrastructure as code, understand all the world. And then up jet, for example, you telephone models. This is also I think how Azure is doing until today, they just objected, it's a provider and embedded it in a crossplane and

use it for infrastructure. So it sounds fancy on LinkedIn, and a lot of people would have Teleform replaced with tools like Crossplane. So you can do everything declarative. You can push everything to get, gettops, and your infrastructure, everything is going to be for a visual. But the reality shows on the market that the most people are sticking to Teleform. And so I think I'm going to also taking a post in the next days and saying, yeah, Telephone, that is nice. But the report says this is the real. reality, how we're going to be available between Terraform and then the next step, going to cross-plane, everything is going, how do you handle it or how you transit it, especially for a cloud provider from Europe that don't have the cross-plane provider. This is what I see. And we also see it. I mean, obviously, many years of investment in Terraform, a lot of custom-built modules around it, a lot of expertise that has been built up within organizations. And this is why.

as we see this big of an adoption of terraform, even though there was obviously some shakeups on multiple ends in the last years. I will definitely provide, I found the state of Pflipter Engineering Volume 3, as you mentioned it, folks. I will add all the links to the description. Also, thanks for the reminder of what upchatting is. So in case folks, you don't know,

Upchat is a project from Crossplane. Also, we'll add the link. It's generating cross-plane providers from any Terraform provider, as it says, on the GitHub repository. And so we'll also add the links to this. And yeah, the reason why I wanted to bring it up is because we also have a lot of discussions

with the people that are not trying to figure about the future for their infrastructure is code. So I'm looking into cross plans. I'm moving back to Terraform because of, for instance, the reason that, hey, we have not enough skills within organizations to move to another IAC project. Also, we will have a gap if we would move over. And then we need to maintain two things.

And two things, maintaining is not the right thing, that's not efficient. Just as you, I also very much like cross-plane. But right now, as you mentioned, 70% are using Terraflow. still, this is not going to go away in the short term. But we'll see what's going to happen in the months and years to find me. Maybe AI would save us, just kidding.

Yeah, exactly. I think you also mentioned the, it was a, thanks for the reminder. I believe in your slides, you had your recap slides. And in the recap slides, at the very end, You said, AI won't save you. So, yeah, I will definitely make our lives hopefully easier if you leverage it well, right? It's going to be a productivity tool, but it's not going to solve all of our problems. Not yet.

Not yet. Exactly. So maybe in a year from now, we come back and then we say, you know, we were all wrong. You never know. You never know. Hey, Artem, thank you so much for the time. It's amazing how time flies when you have a discussion around topics that you're interested in. I hope, well, first of all, I wish you all the best with your upcoming projects.

Are you going to speak at any other conferences that are coming up in the next week or months? Yes, next week I'm going to be at the WSO2 Asia, and I'm going to speaking about platformless. If the companies fail on building IDPs, which solution exists, and I'm going, taking a look or providing Korea, which I really like, and to say, if you don't have the money to build a platform engineering team, you can use Korea or open Korea with self-force it. And I'm going to be on a conference and on Sri Lanka,

I think, or in Sri Lanka, I think they say, they don't say Sri Lanka, in Germany say Sri Lanka, but if I remember, I tried to say Sri Lanka, it's going to be my next conference. And of course, container days. If people are joining Container Days, you will also attend to Container Days. Oh, most Container days, no,

but we will see each other, I think, at the Cloud Native Days in Vienna, in Vienna, yeah, of course, then we're gonna reverse a platform engineering. So it's a, I try to keep posted. So if you follow me on LinkedIn or something like this, I'm gonna post it and be updated in which conferences attending.

Cool, again, thank you so much. Hopefully, folks, the content, as always, was useful. You learned something new or you enjoyed. Just listening into our conversation to Brian, I want to say, get better soon because I need you back as a co-host. And with this, thanks again, Arcton. See you soon. Thank you for having me. And Brian, all the best.

And thanks again. And also to all the listener. Thank you very much. Thank you. Bye-bye. Thank you.