Charles Humble talks to Paula Kennedy about the rise of platforms. They discuss platform definitions; common anti-patterns and how to guard against them at both a team and organisational level; proving the value of a platform team to the business; setting up a platform team; lessons learned from Pivotal; and the Syntasso product.
Subscribe: Amazon Music | Apple Podcasts | Google Podcasts | Spotify
About the interviewee
Paula is co-founder and Chief Operating Officer of Syntasso; her previous roles include senior director of Tanzu Global Education at VMware, senior director of Platform Services EMEA at Pivotal and co-founder & Chief Operating Officer of CloudCredo.
Working in the IT industry for over 20 years, Paula is passionate about community, diversity and inclusion and has a range of speaking experience including DevOpsDays, DevOps Enterprise Summit, Velocity Conference, QCon and the LeadDev conference.
Paula is part of the organising committee for Kubernetes Community Days UK and DevOps Days London, and also organises the London Platform User Group.
Resources mentioned
- WTF is SRE?
- Designing for Habitability with Sam Newman
- Don't Call It A Platform by Sam Newman
- Podcast with Adrian Cockcroft
- Conference talk from Cloud Foundry Summit 2018
- Info on Kratix (Syntasso's product)
- Fast Flow Conference: a Team Topologies conference
Full Transcript
Introductions
Charles Humble: Hello, and welcome to the 11th episode of Hacking the Org, the podcast from the 'WTF is Cloud Native?' team here at Container Solutions. I'm Charles Humble, Container Solutions Editor-In-Chief.
Before we get into the podcast, I wanted to mention that our conference, WTF is SRE? is back for a third year and will be held in person for the first time. It takes place in London here in the UK, May the fourth to the fifth of 2023. And we have four tracks covering observability, DevSecOps, reliability, and for the first time this year DevEX. If you want to find out more, point your browser of choice to www.cloud-native-sre.wtf. Tickets are on sale now and obviously spaces are limited, so do get along as quickly as you can.
My guest today is Paula Kennedy. Paula has worked in the IT industry for over 20 years and is passionate about community, diversity, equality and inclusion. In her day job, she's the co-founder and chief operating officer of Syntasso, developing Cloud Native and open source technologies. Prior to that, she co-founded CloudCredo in London, which was acquired by Pivotal where she has worked as a director of Cloud Foundry Solutions. She's also part of the organising committee for Kubernetes Community Days UK and DevOpsDays London, and she's a regular conference speaker and meetup organiser.
Paula, welcome to the show. Thank you so much for doing this.
Paula Kennedy: Thank you for having me. That was a fabulous introduction.
What's your definition of a platform?
Charles Humble: So I had Adrian Cockcroft on the last episode and we started off by talking about the fact that the terms platform and platform team seem to be everywhere this year. And actually I've just been doing a CFP for our conference, the WTF is SRE? Conference, and I think every other talk that we got submitted had a platform shoehorned into it somewhere. But what was interesting was everyone's definitions of platforms seem to be a little bit different. So I thought we could maybe start with what's your definition of a platform?
Paula Kennedy: I love that question. My favourite definition is one from Evan Bottcher from ThoughtWorks from 2018 actually. So it is interesting how platform and platform engineering are starting to become very hot topics where it's actually been talked about for quite a few years. So the Evan Bottcher definition is "A digital platform is a foundation of self-service APIs, tools, services, knowledge and support, which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace with reduced coordination."
So the reason I like that, there's a few things. First of all, I like the way it's technology-agnostic. So he doesn't talk about, it's not Kubernetes, right? Kubernetes isn't the thing or a particular cloud vendor isn't the thing. It is agnostic of the technology. He's basically just talking about a bunch of stuff put together but in a thoughtful way.
So he talks about arranged together. It's not just serve a bunch of tools in a bag and let people pick and choose. It's about putting things together thoughtfully and he talks about creating a compelling product so it's not just "Well, build it and people will have to use it so it doesn't really matter what the experience is." It should be compelling, it should be nice for people to use.
And the final part I like is he talks about it being used by autonomous app teams. So, it brings in the idea of DevOps, where you build it, you run it. The platform should facilitate that self-service model. It should allow developers to build and run their apps themselves. It shouldn't kind of go back to an old dev and ops construct. It should allow those developers to have that kind of autonomous access to the platform.
So that's my favourite definition. I feel like I've quoted it lots of times at lots and lots of conferences, but that's my favourite one.
What do you mean by the “platform gap?”
Charles Humble: Yeah, it's a really good definition I think. And thinking of things you've said at conferences, I've heard you talk a certain amount about what you call the “platform gap”. Can you talk a bit about that? What do you mean by that term?
Paula Kennedy: In its simplest terms, it's really just about the gap between infrastructure and getting software in the hands of customers. So it's a gap that everyone's trying to get across. And I think what we've seen is an evolution of how people try to bridge that gap basically. So in the old days, you mentioned I've been in IT for 20 years. I am older than I look. Oh, I don't know, I feel like I look as old as I am today.
But anyway, in the old days you maybe had dev and ops. So you had infrastructure and a team that's managing that and they're doing the operational work. And then you have the developers who are focusing on building the applications and those are going to the customers. So in that gap, you've got kind of infra, ops, dev, customer and that's how many organisations probably still today operate.
Then you've seen the DevOps movement from 2009 onwards where folks have tried to close those kind of silos where dev is not collaborating, communicating, there was lots of time delays between things getting into production. So DevOps was about trying to increase collaboration and have dev and ops working together. So then in that model you've got infrastructure and you've got value to customer and you've kind of got one team trying to manage that whole journey.
So they're trying to do the operations and they're trying to do the development and they're trying to go up and down that full stack developer let's say. And where I think we are now, with platform engineering, is we're seeing another evolution. So we're still trying to solve the same problem we're trying to get from software has to run somewhere to, it has to get into customer's hands.
We're still trying to go from infra to customer. But with platform engineering we are trying now to have platform engineers are closer to the infrastructure level, but they're trying to make it easier for the folks who are focused on getting value to customers, make it easier for them to self-serve the platform parts that they need without themselves having to worry about the whole thing. But really the platform gap is just what we've been trying to solve forever, honestly.
What do you do when the money resides and basically the money sits with the product team and the platform team ends up being starved of resources?
Charles Humble: Something I've seen happen in lots of organisations actually, but particularly in larger organisations, has to do with money flows or where the money resides and basically the money sits with the product team and the platform team ends up being starved of resources. Is that something you've seen and do you have any thoughts on how to avoid it?
Paula Kennedy: Definitely seen it many times. It's something I've talked about actually in an interview I did for InfoQ where the question I was asked was, why are platform teams underfunded? Which is sort of a similar question. And I think there's a few reasons why platform teams traditionally are underfunded.
I think one is to do with some organisations, platform teams are just seen as another infrastructure cost. They're sort of something that has to be minimised, let's do the minimum spend we can. It's trying to reduce your AWS bill. Platform is seen similar. Let's try to reduce the cost so not spend any money unless we absolutely have to.
I think we've also seen organisations where they've bought a platform off the shelf. And then the platform team, because it's been sold to them as kind of this silver bullet that the platform is all singing and all dancing, developers can use it, you don't really need a platform team. So the platform team itself, the money's spent on the product and not on the team. So the team doesn't have much resource available to it.
And I've seen it where, you mentioned it earlier, sometimes it's hard for a platform team because it's just a cost, it's hard for the platform team to demonstrate its value. So the business doesn't want to invest money into that team. They are just trying to reduce it.
One organisation I worked with a few years ago, the application team was big revenue generator for the business. It was a big bank. They generated a lot of revenue for the bank and they were struggling to actually get software into production to the point where they actually decided to invest themselves in their own platform. They took DevOps to the extreme and they were like, "Right, we will actually build our own platform team within our app team." And they were straight up an application development team for this mortgage application, but they funded themselves because they had the pot and budget available.
They actually funded themselves and took some of their team and created a platform team within their own organisation, which is not necessarily the answer, but I think in a way, at least a way of introducing the concept of the value of a platform team into that organisation, which was quite good.
How do you go about proving the value of the platform team to the business?
Charles Humble: So given that, how do you go about proving the value of the platform team to the business?
Paula Kennedy: It's one of those questions where I'd say it depends. It depends what the value is for the business. So when I think about answering this, it really depends what metrics your organisation cares about.
So I've spoken publicly about platforms for quite a long time. There was a talk I gave in 2018 at Cloud Foundry Summit when I was working at Pivotal and I stood up and I talked about the very public case studies. Pivotal had a lot of customers who were prepared to get up on stage and talk about the value they had gotten from using a platform. And so there was all these different examples.
So there was examples where they had huge number of application developers supported by a really small platform team successfully. So they were able to have this very small team that had a huge impact on the business. We had another customer who stood up and talked about how they were able to increase the number of deploys to production. We had another customer talking about how they had been able to reduce security patching lead time. And all of these case studies were available publicly, so I talked about them quite a long time ago.
But if you are in a platform team and you are trying to figure out how to demonstrate value to your organisation, the thing to understand first of all is what does the organisation care about? Is it number of deploys? Is it security? Is it cost reduction? Whatever the thing is that the business is trying to measure for the value, that's where, as a platform team, you can take your own view of how you're contributing to that KPI, to that metric and feed that back to the organisation.
How do you start a platform team off?
Charles Humble: There's something else that I've seen happen, which is where the organisation doesn't have a platform team and it doesn't have a platform, at least officially it doesn't. But it turns out that actually it does. It just is something that one or two developers are maintaining, maybe one of them then leaves the company. This is I think more common than people realise. So if you were in that situation, how would you go about then getting to something more formal? How do you start a platform team off?
Paula Kennedy: It's one of those things, I was talking to one of my team earlier and we were comparing how naming things is hard. I think that's part of the issue. So it's like when someone says that they don't test in production. Well, everybody tests in production because everybody's released into production so everyone's doing it. Or it's like somebody's saying, "Oh, we don't have CI/CD." But at some point you're delivering some stuff into production.So you have a pipeline, whether it's automated or not, whether it's continuous or not, you're still getting stuff into production at some point.
And I think that's the same principle with platforms. Like you say, you've got a platform, whether you know it or not, whether you built it or not, you've got something that is running your code and that people are accessing to be able to deploy code too. Doesn't really matter what you call it.
Like I say, naming things is hard. I read the Sam Newman article where he talked about he doesn't like the term platform engineering. I mean, fine, fair enough. But you sort of have to call it something. It's like DevOps. I've been in DevOps for a long time. I've been running DevOpsDays London since 2017 and that's a word that's overloaded.
But I think if I was in that situation that you described where I'm in an organisation and I think I'm running a platform and I'm not quite sure, or I want other people to think I'm running a platform, I think Sam described 2023 as the year of platform engineering. And I would tend to agree. You mentioned you've got lots and lots of CFPs coming in around platform engineering. It's a hot topic right now. And that means there's lots of online talks available. There's lots of blog articles being written.
There's lots and lots of information out there about that. There's articles that describe the types of work that are being bucketed under the heading of platform engineering. So if it were me, I would be reading some of those and trying to have a look at what I do as at my day job and try to map the types of things that I do. Do they sound a bit like the things that other people are talking about?
A real key identifier for me, regardless of your definition of a platform, if you are enabling other people to deploy stuff into production, that's sort of the definition of a platform. That's sort of what Sam was talking about. It's like anybody who's doing enabling work, you could say platform team. In the team topology model, they talk about platform team enabling teams, stream aligned teams. Arguably platform team is just another type of enabling team. It's literally enabling the business to give value to customers.
So if an individual is looking at their day job and thinking "This smells a bit like platform engineering to me," then what I would do is, within your organisation, if you have an opportunity to do lunch and learns or brown bag sessions or an internal Slack where you post interesting articles, I would be trying to raise awareness on the general topic. There's so much information that can be pointed to.
So, starting to raise up within the organisation, hey, there's this thing called platform engineering and sort of sounds like what I do and maybe like I said, do a presentation. If you've got a team meeting or a company offsite, start getting the conversation raised, raise the awareness. And then, whatever your job title is, if you think your job looks like platform engineering, try to measure the value that you think you are bringing to the organisation.
Like I say, if part of your job is helping people to be able to get code deployed, whatever it is you're doing, maybe do a survey of those people and measure their satisfaction. Maybe ask them how much time is it saving you because I've done this? How much easier is your life because you've got this thing?
And if you can start from something, measure something, if you can then measure some value that you are adding in your job that you think looks like platform engineering, then you've got some data that you can share up to leadership and say, "I think we need to invest a bit more in this. I think maybe we need to have a talk about org structure. I think maybe we need to talk about bringing in a couple of extra people because this is an important thing. The industry is talking about it, I'm sort of doing it. Let's make it more formalised."
How do you avoid spending too much time building the platform?
Charles Humble: Right, yes. I want to briefly go back to you mentioned testing and production. You and I have both been around this industry for similar lengths of time.
Paula Kennedy: A long time.
Charles Humble: Right. Too long maybe. But I remember when people like Charity Majors first started talking about testing and production and the default response was, "Oh, that's a bit cowboy, a bit dodgy. We don't test in production."
Paula Kennedy: Everything's testing in production.
Charles Humble: Right, of course it is. And of course you do. Maybe you don't think about it in those terms.
Paula Kennedy: Yeah. Oh yeah.
Charles Humble: And I also remember, you had UAT environment that sort of bore a passing resemblance to production. Hardware was spec'd a bit differently and then you'd have a problem and it's like, I don't know, is it the data that's different or is it because the hardware is spec’d differently or whatever it is?
Paula Kennedy: Yep, a hundred percent. That's exactly where I started.
Charles Humble: And isn't it extraordinary to reflect on that and think actually how far we've come? First, I think because of DevOps and man kind of going alongside that as a result of public cloud. It's maybe I'm in the phrase of doing a second edition of a book with Anne Currie called The Cloud Native Attitude, which is a CS book. And so maybe this is all top of mind for me partly because of that. But I just think it's really interesting.
There is another antipattern which I've seen and I've only seen it once and I don't know if it's just me who's seen it, but I was interested to see if it was something you'd come across, which is where a company is embarking on perhaps a Cloud Native transformation or some sort of digital transformation and they say "We are going to move to the cloud, but first we need to have a platform." And when they pour time and resources into the platform, and two years later they never actually ship anything of value because they're still building their platform.
Paula Kennedy: Oh, you're picking up all my nightmares right now. Yep.
Charles Humble: I'm really sorry, but is that something that you've seen then? Is that a pattern that you've seen else where?
Paula Kennedy: Yes, a hundred percent. Yeah, many times. I've been talking about platform as a product for a long time, but it's the very classic thing about the build it and they will come. I don't know. Sometimes I feel like why do people not learn? I don't know. It's Friday afternoon and I'm like "Ahhhh!"
Charles Humble: But it's interesting, isn't it? I just think as an industry we are really bad at learning from past mistakes or reading academic papers and going, "Oh it turns out someone solved this problem in 1975. Maybe I should start there." Do you know what I mean? I've sat in conferences where people have been talking about how they've essentially rediscovered Lamport clocks or something except they've been... We've solved this.
Paula Kennedy: Yeah.
Charles Humble: You’ve done a lot of work. It's very clever, but, you know.
Paula Kennedy: I know.
Charles Humble: We've solved this before.
Paula Kennedy: It's exactly the same with the platform. I've seen it over and over where, like you say, millions, millions of pounds spent on building something upfront, long list of requirements, built in a vacuum, platforms being built in a vacuum, no collaboration with the people who would be using the platform, no understanding of even needs evolving.
In my old days at Pivotal, we talked a lot about product over project. So you'd have a project team come together. And that project would be funded and it would have a Gant chart and it would have a start and an end and the team comes together and they build the platform and they ship it and da, da!
And then no one uses it because it doesn't do what anyone needs and let's say lots and lots of money and time wasted and project's over.
So the project team is disbanded and the team goes off and then there's just this thing left. Whereas, at least what we've always tried to do and I do now, is we talk about product over project. The product is long-lived, the product evolves. So when we say treat your platform as a product, that's really what we mean. It's, you build the right thing for the people that need it, you understand their user needs, you collaborate with them, you ask them, you get feedback as you go. And then that product lives and it evolves and continues to meet user needs. It's not a project that's once and done, but I've seen that approach too many times to talk about honestly.
Charles Humble: Yes. Yeah.
Paula Kennedy: It makes me very sad but I have seen it.
How does the project to product movement fit in here?
Charles Humble: You mentioned the Sam Newman article on platforms and that kind of came out the back of a webinar that we did with him, which I will link to in the show notes because it's well worth watching. And in that webinar he talks about something which is kind of related, which is this idea of not forcing people, not mandating people to use your platform.
And his point basically is if you force people to use your platform then it stops being about enablement and instead it becomes about control, but also it works against you making a platform that's actually nice for people to use because they have to use it anyway so why does it matter? Which I just found a really kind of interesting take. Again, I think that whole shift to product away from project, it's kind of tied into that same space.
Paula Kennedy: Yeah, a hundred percent. One of the things we used to try to do, you mentioned how I'd been previously at Pivotal. My role was platform services for EMEA. So I led that team and we did some really interesting things with customers. One part that was really fun was with an internal platform, the kind of internal advocacy of that platform. So as well as building what the platform consumers wanted and collaborating with them. And we'd often have the development of the platform, we'd have the application team in the room as well.
So the first application that might be landing on the platform, we'd invite the application team in to be there with us to have regular demos once a week showing them what we're building, making sure it's fit for purpose. And one of the fun things we would then also do is come up with some branding for the platform. We'd give it a cool name. We'd come up with some logos. We'd market it like literal internal marketing of that platform. And we'd help customers to do that and produce swag, stickers and t-shirts, the stuff that people kind of quite like and try to generate internal buzz.
Because, to your point, what we wanted was those app teams to be excited to use the platform. We wanted them to have a good experience and to want to use it and not to be compelled to use it, not to feel like that's how shadow IT comes about. Because if you're forced to use something and it doesn't work and it's clunky and it takes too long or it's not what you actually need now to get your software delivered, that's when you're going to go somewhere else. So by making sure that the platform is optional, but the best thing is “make the right thing the easy thing” is what we talk about quite a lot in my team.
If you can make your platform compelling, to go back to Evan Bottcher's definition, and delightful, develop and delight is something I talked about back in 2018. If you can make your platform compelling and delightful and also reduce barriers. If a developer knows that they can use the platform and therefore it's already approved for compliance or governance or security. If they know that using your platform is the easiest path, it might not be, I don't know, the flavour of the month, the sexy new toy that's come out. But if they know they're going to use this particular route to get to production and it's all ticked off along the way, people are going to want to use it.
Charles Humble: Yeah. And equally, there are situations where you might need to make an exception. I took to Sarah Welles who did a lot of a sort of platform enablement stuff at the FT and I've talked to people at Netflix over the years about this as well and they all make the same point, which is you try and make your golden path, your platform, your preferred route, whatever terminology you want to use for that as good as possible, but you have to accept that there may be cases where that particular use case just doesn't make sense. There is a perfectly reasonable reason to go off. Otherwise you end up sort of trying to tie yourself in knots trying to meet every possible requirement, I think.
Paula Kennedy: Yeah, I'm a big fan of Sarahs. That's absolutely right. When we talk to customers, what we think about is, as a platform team, what you're trying to do is not necessarily solve for every single case. What you want to do as a platform team, maybe you're trying to cover 80% of the services that are needed.
So if you've got five application teams and they all happen to be using Redis as their database, then if the platform team could take that on and say, okay, we'll offer Redis as a service and when you need to spin up something, you just need to have a really simple API experience where you can just request it and up it comes, Bobs your uncle.
And then if you happen to have another app team that has a very specific requirement that they need and no one else is going to use this particular tool, whatever it is, but it's useful for them. It's not just, I don't know, resume driven development or whatever, they've got a specific requirement that they actually need, then you have to make exceptions.
So there's a couple of ways you can do that. You can let that team run it themselves. I've seen quite a few examples where organisations will say, "Okay, platform team will handle all the shared services and anything that's specific to one set of requirements, you team, you can absolutely use that tool. Have at it. But you install it and you run it because it's only used by your team for a very valid reason, but it's on you. Okay, we platform team won't take responsibility for it, but you can have it and you can run it."
And I've seen other examples of organisations who allow that to begin with and then the platform team will have a process to kind of monitor it. So if they see something that is a pattern that one team is using specifically, but actually the platform team can evaluate and say, "You know what? That tool could be quite useful for a few others." Then maybe the platform team will agree to accept it on as their responsibility and then offer it out as a service to other teams and it then shares best practices across those other teams.
So exceptions can become norms if there's good reasons. But allowing exceptions, what you do not want is for your platform to stifle innovation, creativity. You want to allow that, and you want to allow the exceptions, but you just need to keep an eye on it because the last thing you really want is as a platform team particularly to be trying to support every single possible tool in the toolbox that every single app developer wants in your organisation because that can be chaos.
There's a person who I was speaking to recently who's called Mathieu Frenette, he works for Nesto, which is a Canadian financial services org, but he talks about golden paths, not golden cages, which I really like. The golden path is like the yellow brick road you can skip down, everything is hunky-dory, but it shouldn't cage you in. You should be free to come up with your own path if you need to or your own step, or a couple of steps along the way if you need to as an exception.
Were there things you learned from working on Cloud Foundry that you've taken forward to the new role?
Charles Humble: You've mentioned obviously the role at Pivotal a couple of times. Were there things you learned from working on Cloud Foundry maybe that been interesting lessons that you've taken forward to the new role?
Paula Kennedy: Yes. My time at Pivotal was fantastic and I learned so much. It was one of those experiences that really, even though I was there five years, it felt like I was there a lot longer. Cloud Foundry was fantastic in its mission to simplify developer experience. It feels like actually that Cloud Foundry was quite far ahead of its time. It was trying to offer a sort of Heroku-like experience for developers but at an enterprise scale and it was very, very good at certain things.
It was very, very good at offering this fantastic developer experience, the whole CF push experience that we talked about, which was, as a developer CF push, here's my code, run it for me, I don't care how kind of thing. Very, very good at that. But, what we learned, so the team in my startup Syntasso, the three founders, we're all ex Pivotal/VMware. And what we learned from our experience was really that there's not one platform that can do everything.
It was a hard lesson that we learned from Cloud Foundry. Cloud Foundry really tried and Pivotal in particular. We really tried to offer this is the platform that can do everything. And it was very opinionated and it worked fantastically for certain types of applications, particularly stateless 12 factor applications. But for an awful lot of, particularly the big enterprises, which is who we worked with, there's a lot of other estate out there that doesn't fit that model.
We've seen the rise of Kubernetes. Kubernetes has sort of been this answer to actually we don't want the black box model, we want to be able to compose things ourselves, which is why you see the CNCF landscape as being this huge explosion of tools to meet all kinds of different pieces for building the platform. So we've certainly learned the lesson the hard way about you can't really buy one platform that's going to do everything for you. As an organisation, if you are kind of on that path of platform engineering, we understand we need a platform, we're going to go out and buy it.
Whatever you buy, whether it's a cloud vendor, whether it's a Kubernetes kind of experience, whatever you're buying, you still have to, at the end of the day, build something yourself. We talk in Syntasso about only you can build your platform. Because everyone thinks they're a special snowflake and there's a lot of conversations about are people actually snowflakes or not? But actually, every organisation has something that's unique to them.
People have their own reasons for existing. They have their own software, their value, their unique proposition of why they exist. And every organisation has got to do some amount of curating of the platform, whether it's a small bit, whether it's a lot, but you can't buy a platform. I think that's the lesson we've really learned. There's not one platform to rule them all. And so, like I say, we talk about you have to build your own platform and that's what we've tried to bring into our new startup.
How does the Syntasso product work?
Charles Humble: Yeah, that's really interesting. And I think you're right, I think Pivotal in many ways, I think they were very ahead of our time, both with Cloud Foundry and lots of the ways they were working and the stuff they were doing with Pivotal Labs and people like that, I think was a very kind of a real force for good within the industry in many ways.
But I also think you're right, Cloud Foundry was very opinionated and it's the same problem you have with Heroku or Railway or any of these things. If your use case fits, that's great. But if it doesn't, you kind of run up against that, I can't make the thing bend in the way I need it to to do my thing, which is really interesting. So what does that look like from a product point of view? How does the Syntasso product work? What am I getting?
Paula Kennedy: Well, I'm glad you asked that question. So, like I say, the three founders, myself, Colin, and Chris, we've taken our lessons learned from five years at Pivotal and then subsequently VMware. And we've learned that every organisation has to, like with Cloud Foundry, they end up having to break open the black box and try to customise and try to make something fit into their organisation's needs.
And we are big fans of Kubernetes, let me be clear. So we see Kubernetes as kind of this substrate which actually makes it an easy API across cloud providers. It's a very good abstraction, but it's also still very low level. And we see CNCF, it has many, many, many tools available. And one thing I've talked about a lot recently is cognitive load and where it sits in an organisation. So we talked about the platform gap going from infra to software and customer's hands. The same is true for cognitive load. A whole bunch of stuff has to happen.
A load of tasks have to happen to get software into the hands of a customer and it's just a question of who's going to do what, and where does the kind of workload and the cognitive load sit? And what we've been learning is that with this kind of, I don't know, sort of shift left mentality that people talk about where you want the developers focused on much more getting value to customers and you don't want app developers focused on maybe security or compliance or infrastructure or networking.
What we've seen is more and more stuff being pushed onto the platform team, like more concerns being pushed onto the platform team. And they're trying to wire together this curated experience that we talked about earlier. And yet, they're either underfunded, as we mentioned before, or even if they've got a good number of people and funding, it's still a heck of a job. It's a really complicated landscape right now trying to wire together all things.
Like you look at that CNCF landscape model, how are you going to pick which pieces that you need? How are you going to evaluate? How are you going to put them together? And what we are trying to do in Syntasso, we have this product called Kratix. It's a framework and its purpose is to make it easier for platform engineers to build a platform. It's literally about trying to improve platform team experience.
So there's so much focus on developer experience. Everybody's focused on that developer experience and offering the Kubernetes platform that's kind of managed that makes it easier for developers. Where we are trying to come in is actually everyone's putting load onto the platform team and no one's helping platform teams to make their lives easier. So what Kratix does is it allows platform teams to basically create an abstraction that we call a promise, which uses all Kubernetes native constructs.
It's not something different, it's just wiring together kind of parts of Kubernetes, so CRDs and operators. And it basically allows a platform team, it makes it easier for the platform team to kind of wrangle YAML, makes it easier for them to offer things as a service to their app teams so that the knock on effect from Kratix is a better developer experience. Because we make it easier for the platform engineer to then offer that experience. We're trying to make platform engineer's job easier.
You can tell I've been in platform engineering for a long time. It's where my passion is and what I care about. And so we are literally trying to have this abstraction level of a promise you can make it composable. It's a little similar to maybe Crossplane for folks. Like we get compared to Crossplane quite a lot right now. But really Kratix is trying to make platform engineers life easier, make it easier to wire things together, make it easier to offer it as a service, make it easy to update, make it easy to be secure, make it easy to do things, even non Kubernetes things so that you could offer one platform that gives a lovely Heroku experience to your developers, but as a platform engineer, it's easier for you to wire those pieces together. That's where Kratix fits in.
Is there anything else you just want to mention briefly to wrap us up?
Charles Humble: Right. Brilliant. So we are unfortunately at time, but I know you've got a couple of people speaking at our WTF is SRE? conference and I'm sure you've got one or two other things. So is there anything else you just want to mention briefly to wrap us up?
Previous article
