Platform as a Product: What Does it Actually Mean? – The Platform Engineering Show EP3
The platform-as-a-product mindset is perhaps the key differentiator between platform engineering and neighbor disciplines like DevOps, SRE, or I&O. In this episode, we will cover where it came from, and dive into the why, the what, and the established best practices.
Transcript
Hey everyone. I'm Alan Shimel. That's Luca Galante, and you are watching the Platform Engineering Show.
Hey, Luca, happy New Year. It's great to see you, my friend. How are you?
You too. I'm good. How are you doing?
Happy New Year. Happy year everybody. Yeah.
Happy New Year to everyone. So, Luca, where let's play. Where's Luca?
Where in the world are you today, man, east coast is Sri Lanka, the east coast of Sri Lanka. That's great. And it's nice and warm there.
You're on the beach. Yeah. I mean, freezing.
Apparently tour than in Florida, right? Yeah. Well, winter, winter came to Florida.
Right. But we get this around this time of year, we'll get like three, four days. I was telling you where it, sometimes it'll go down even into the high thirties, low forties, fa night.
And then the, the, uh, the iguanas that are, they're not native, but they're invasive here. They, they get frozen up in the palm trees and they go what they call topi, like, you know, they just shut down and then they fall outta trees. And some of these iers are like four feet tall.
I mean, they're big, they're big reptiles, so you don't want 'em falling on your head. Y'all get hurt. But, uh, this is so fascinating to me.
It's crazy. It's crazy. But, but, but do they recover or are they dead?
Uh, it depends how long and how cold they are. Long because, you know, Gus are usually like that nice green color, and then when they're in reading colors, they get red and orange. When they get topi like that, they turn gray.
It's like they really Yeah. It's a good dark. They look like off.
Yeah. Um, crazy. But yeah, we'll see.
I mean, no, they're, they're kind of like a nuisance animal here, so people aren't terribly upset that some iguanas die. Uh, they don't belong here and they just, they're a mess. They're a mess.
Right. Anyway, enough about iguanas. You're in Sri Lanka.
There's a lot going on in the world of platform engineering, though. We got a great topic to cover today. But before we do, I wanted to just go over with you a few things.
First of all, we're making plans here to head over to London, the cube con, I think it's April 1st to the fourth is the actual cube con. Um, but I know the community has, has some real big plans going on. You wanna share a little?
Yeah, it's gonna be, it's gonna be a big one. Um, cube Con, right? In London, they're expecting 12,000 people.
And so we do our sort of like unofficial cube con opening party, which is Coha Cube. We've been doing it now for like two or three years. It grows every time, expecting a lot of people.
Probably like 4,000 plus signups. There's probably gonna be like 500 people, 600 people at the location. They're be pretty crazy.
And, and you know, the whole thing of us cubes, like we started it when I think we were at CubeCon Valencia, and it was basically, oh, I love that. You know, we were kind of going from like, which was great 'cause it was like Valencia and so on, but we were basically going from like one party to the next, or like, man, all these parties are the same. Um, and obviously, you know, we have like a Berlin background, uh, techno background.
And so we were kind of like, wouldn't it be funny to do the sort of like, uh, the dark room of DevOps? Um, and for those that catch the reference. Um, and, and, and so it started like as, as a joke, but we did it.
Um, and it's really funny 'cause it's always, there's a bit of, bit of a tension with the CNCF guidelines that basically don't allow you to stay in the dark room of DevOps. Um, but yeah, so we started and, and, and now it grew to basically really become the unofficial opening party. You know, we have like drag queen shows and it's a whole thing.
So, so that's gonna be really fun. Really. Oh, very cool.
Um, yeah, yeah, yeah. Looking forward to that one. Kind of like Key West down here.
We that's, I dunno if you've ever been down to Key West, but they Well, of that No, but I heard, yeah. Um, yeah, yeah, it is. Yeah.
Well, there are other places that are more, but anyway, um, I digress. Let, where can people get more information about House Cube? com.
Um, and you could sign up. It's free. We have, uh, amazing food, amazing drinks, amazing drag queens, and just come post fun post party.
We're gonna do that. That's fun. That sounds great.
And then the other, you know, big thing on the horizon, and it's not too early to get this out there, is, this is the third or fourth platform con, this is coming up in June 4th Platform Con. So we started 22. Um, we had like, I think like 6,000 people or so joining virtually.
Um, then we had pop from Count 23, we had like 20,000 at 24. Last year we had like 35,000 or something, and then expecting like over 40,000, um, this year. But the important thing this year is that we're really doubling down on the in-person components.
So we're gonna have two live days. One in London, one in New York, both around like four or 500 people. Uh, you know, we have great speakers, Nikki wa Gregor Hope, Kelsey Hightower speaking, I this thing's live.
So really excited about that. It's gonna be last week of June. So London on the 25th of June.
And, uh, New York on the 26th of June. Uh, so it's gonna be fun to like hop between one city and the next. Um, but the, I think the events are gonna be great.
We're gonna have parties. We, we have like a lot of great like, speakers live trainings, a lot of new formers that we're rolling out for this. com.
Um, and you can choose your, uh, choose your own adventure, uh, and join us either virtually or in person London and New York. I think Techstrong TV will be in New York. I'd love to come home to New York.
Um, and we'll be broadcasting live from there as well. Yes. So it should be a fun, fun, fun thing.
com. Yeah. Right.
Fantastic. Uh, speakers are, uh, all speakers have been assigned. What about sponsorships available?
Yeah, sponsorships still available. Um, almost sold out of New York. Um, that, that's gone pretty quickly.
Um, and, and you know, we're closed with London, but there's still, there's, there's a lot of like, you know, um, there's like, also virtual sponsorships are still open. Sure. Um, so anyway, sponsorship, sponsorship's still open.
Um, and there's a lot of like, interesting formats that, as I said, we rolled out the trainings, but also, you know, we're gonna do live interviews with you in New York, for example. So lots of new interesting things that I think can be very fun as well to do with, uh, with vendors and other sponsors. Very cool.
Very cool. Alright, Luca, we gotta talk about what we're talking about. You know, this is, uh, our third episode.
Yep. This is our third episode. This will probably be the last one where it's just you and I talk in like this.
Well, we gotta bring in some fresh blood, some expertise, and, you know, we'll announce, uh, check marks is gonna sponsor our show. So many thanks to them for that. We're looking at other sponsors if, if anyone out there might be interested.
Um, but for today, Luca, we're gonna talk about platform as a product. And look in today's world, right, there's platform as a product because everything is as a service, right? So here we got PAAP, and I'm sure the next thing will be PAAS, but you know, what does it actually mean when we talk about platform as a product?
And, you know, it's a, it's a key part of this platform engineering kind of mindset. But, you know, you're the expert. Why don't you define it?
Yeah, absolutely. And, and I actually think it's a good place to start from the pa a a s that you mentioned, right? So like the, the platform as a service, right?
Th this is just as kind of like, uh, one of sort of the, the main trends. If you look back like 15, 20 years ago and like Heroku, all those guys, Heroku start. Yeah.
And yeah, and, and, and, and it was just idea like, hey, like don't worry about anything, right? Like, we, we build this like platform layer for you. It's, you know, it's like turnkey, plug and play, let's go.
Um, and, and that didn't really scale to the enterprise, right? Because like everybody realized, hey, you actually need, um, you know, some, some customized platform layer, uh, for your, for your own enterprise engineer organization. And, and that's kind of what platform engineering, sort of like, you know, where we're sort like platform, platform as a service or pass ends and, and sort of like platform engineering starts is really this idea of like, hey, you're building this internal product or internal consumption, right?
Like your internal customers are the, um, the, your, your application developers. Uh, and you do that as a product, right? And that's like a very, um, it's probably, in my opinion, the key concept.
Um, the key foundational concept of platform engineering and also the key differentiator, um, you know, of platform engineers vis-a-vis, I'd say like a DOS engineer or, you know, an SRE, um, that, that normally we'd approach the infrastructure project as a kind of like one and done, you know, six months project, something of that kind. Whereas a platform engineer, at least like a, like a good one, um, approaches building an internal developer platform or IDP, which is the end product of apop engineer initiative as a product, right? So a product that has a life cycle, not that it's, so it's not like a one and done, you know, six months thing, but it's actually, it's being rolled out as a minimal viable platform initially, um, for the first few months and then irate on, and then eventually grows.
Um, it gets adopted widely across the engineer organization. Um, right? And, and it keeps being worked on as a product.
Uh, and I think it's, it's a, it's a super interesting concept because the moment you look at your internal developer platform as a product, you immediately unlock, you know, 20, 30 years of product management best practices and experience that that we have in the industry that can be applied to build, uh, your internal developer platform as a product. And here's the thing, whenever you talk about something as a product, the next logical conclusion is who's the customer? Right?
Right. And, and, and traditionally that was in it, right? In the IT department going back, I'm going back now, you know, 25, 30 years.
The IT department, the, the customer was the internal business, right? It wasn't sort of forward external facing, it was internal Right. Facing.
Right, right. And, and your customer was the, was the sales guy, the business guy, the marketing person, the HR department, you know, all, all of the above IT service them. It, you know, they, they were the customer of the IT department.
So this, I mean, this is not new in terms of a concept of of of that internal customer that gets served, you know, uh, in this case with, with the platform. The other thing I'll tell you is, look, you know, when, when cloud first came out, a lot of people were very definitive about saying, well, this is infrastructure as a service, IAS, right? And we're gonna have platform as a service, right?
And, and haruku was probably the biggest success coming out of that. But really to a lot of people that meant, well, infrastructure service ended at kind of the hypervisor. They took care of everything hypervisor and below, and you built on top of the hypervisor os and everything else in IT platform as a service initially to a lot of people was, well, no, everything up through the os.
And then you just build your app on top of the os. And I'll tell you, my 2 cents on it, if it wasn't for platform as a service not being sort of a complete, uh, concept, you never would've had cloud native. I think what we see as cloud native today with the containers and, and cobe and mesh and everything, you know, that old cloud native stack is a better platform as a service, or it's a result of the initial like Heroku style platform as a service just not being complete enough, right?
It wasn't what we need. And then, so now you got this cloud native stack, and now you have this whole platform engineering kinda movement, right? Which is borrowing from a lot of what, what's gone on here.
And that's the modern platform as a product platform, as a service that I think people were really thinking about back when, but the initial like Haruku versions were, I don't wanna say flawed, but incomplete. They were immature, right? Yeah.
And, and so I think they, they mm-hmm. There were like a child of, no, that's my 2 cents of the, of its time, right? O of like, yeah.
Also, like I think stacks that were like a lot simpler, right? Infrastructure that were a lot simpler. And, and, but then to your point, right, as cloud native exploded as this like complexity really, um, really exploded as well, then you had to have like a completely different approach.
So it's like the idea is, hey, I still wanna provide a po a path like experience to my developers, right? Um, and, and, and, and I think like your, your, uh, point earlier is super interesting, right? Like, it's also not only the complexity of the infrastructure exploded, but also the, uh, size of the engineering organization exploded to the point where now you have a part of the engineering organization, the survey, the other part of the engineering organization as, as its internal customers, and no longer just like the sales, marketing, hr, whatever, right?
The other functions. And so, and there is also like a, there's also like a, like a mind mindset shift that that needs to happen a lot of times where it's like, well, actually the internal customers is the developer itself, right? Um, which is something that a lot of people are not used to because they think, well, developers kind of build stuff for themselves.
Well, but the, the problem is like, once you have, you know, 10,000 developers and you actually need somebody that like, specifically builds stuff for them, right? So, um, but yeah, so the idea is really like, Hey, I want to build a task like experience for developers, but on top of, you know, a complex and changing and, and, you know, cloud native or hybrid tool chain. Um, and so therefore, I, you know, I, I, I need to take, you know, the, the vision is the same.
I take the tool set, um, you know, in the toolbox of, you know, I borrow it from, from, from kind of like all this other like adjacent disciplines. Um, and then really, like, I focus with this like, product mindset on, on building this site. Um, so like, platform layer developer, um, DevX, uh, layer on top of this increasingly complex, uh, stack, right?
Absolutely. Hey, you mentioned DevX. I just wanna give a quick shout out.
We're gonna do our first live round table of the platform engineering show, um, I think early in February. And it's on DevX. So if DevX is something you guys are interested in, your folks are interested in, uh, stay tuned.
We've got a live one where you can take part and ask questions, and we're gonna dive into that. Now, Luca, the, the platform is a product idea. You know, it's been percolating now for a couple of years, and we're starting to see, I don't know if I want to call it best practices yet, or, you know, evolving best practices.
I don't know if it's written in stone everything just yet, but we're starting to certainly see where, hey, this works. This is not such a good idea. This is a better way of doing that, you know, we're evolving best practices.
Can you talk a little bit about what some of these are and, and where people can kind of, you know, stay in the know on that? Yeah, absolutely. I think like, um, you know, and as I mentioned, like, I think what's interesting is the moment you treat your, your internal product, your internal platform as a product, you unlock all this like best practice.
Like, so it's not like you need to invent anything radically new. It's like, Hey, there is this minimum viable product MVP concept, it's just being rebranded to mini level platform, which is the same exact letters, and the concept is the same. It's like, Hey, start small, irate quickly, and so on.
Um, I'll cover, I'll, I'll talk about MVP in a second. The, but, but I think like before that even, um, like if we look, I think chronologically, and I've seen the, the space sort of like mature in the last couple of years, you know, initially it was kind of like, okay, like what is platform engineering? Is this helpful for me now?
It's like a lot of people are like really bought in to the concept. Like it's been, you know, compounding like crazy. And we spoke about the, you know, the overall like, you know, numbers about platform engineering as a trend broadly in the other episodes.
Um, but you know, with that, a lot of people are coming in, they're like, okay, you know, I'm bought in. I heard this is cool. Where do I start?
Right? Like, what does this thing actually look like and how do I make sense of this? You know?
Yes, we have like a, like a crazy, like cloud native, and so landscape, you, you can just see the CNCF landscape is insane. Like nobody can actually really understand it, but, um, but even the platform engineering, it makes a good picture. It makes very good picture.
Exactly. Um, and, and, but even the quantum engineering landscape at this point has been developing so much that, you know, it's far from that level of complexity. But you know, you already have, like, if you're a newcomer in, and it's like, okay, like how do I, you know, how do I actually piece all this, this from, you know, pieces of the puzzle together for a platform that actually works for me that makes sense for my engineering organization, right?
And so that's where I think the first sort of like, standard that's been really, really helpful in a game changer. I think in the, in the community and, and broadly in the platform engineering market has been this, this reference architecture is for interior developer platforms, right? Um, and, and some of the first ones were, um, open source, uh, by McKinsey actually.
Um, and then, you know, kind of like, now they're like really widely adopted. Um, I have one stat for you on that, which is Platform Con. Um, they were, so the first, the first, uh, reference architecture was, uh, uh, was kind of like presented in the talk at, at pop con 23.
Um, and so there was only one at Pop Con 24 last year. There were already like 20, 30% of the talks that were using. Um, this is a blueprint to kind of like talk through, uh, the platform that practitioners built or whatever, right?
So very, very interesting to see like how quickly people adopted this. And it's for a very good reason. It's just like, it gives like a really good guidance as to like, okay, how do we see, how do you think about the different pieces and how to fit together?
org, I think slash tooling or slash platform tooling is, um, you can see the sort of the tooling landscape there. And that also follows the same structure, um, as the, as the reference architecture. So that was kinda like a first step that was really helpful.
But then sort of like, what I've noticed is that people were, um, kind of like looking at this and like, okay, great, that's, that's my target setup. Like, that's how I want to build my platform. Um, but then they were trying to do everything, you know, at once, um, like, you know, the, the, the Korean movie, like everything everywhere, all at once.
It's kind of like, it's kind of like, like that, right? Like, they were trying to like, okay, like this is great, you know, they get super excited, you know, I get buy in some executives, let's go, you know, build everything, right? And the problem with that is that, you know, you very, very easily lose momentum, right?
And this is, I think, in my opinion, is the number one cause of death apart from engineering initiatives, uh, to be a bit morbid, but it's, um, it's really, it's really like that, right? Like it's, it's people that get really excited that have this like grand designs, um, for, for what the platform is gonna look like. And the problem is that the platform engineer really is a huge, you know, org transformation, right?
And so, uh, and so that means it touches all these different stakeholders, application developers, executives, architects, security teams, infrastructure and operations teams. And so you need to basically get all these people on board with you, you know, sell them effectively, eternally, this idea of the platform. And it's different components that you have like so beautifully designed in your head.
Um, and, and so the problem is like, it's very easy to lose momentum there, right? Because you need, you know, by the time you, you know, you spoke to person A, B, C by the time you, you spoke to person Z, it has been six months person a completely forgot about you, and, you know, you kind of get stuck in this person, right? And, and there the trick is really to take this minimum viable product or minimum viable platform approach of saying, Hey, start small.
Um, focus on like a really, like a subset of, um, uh, not only the problem that you're solving for, for different stakeholders, but actually a, a a subset of the stakeholders, right? So just focus on, on maybe like application developers and security teams or, you know, infrastructure, infrastructure operation team. And really, you don't have to please everybody immediately just focus on like, what's the low hanging fruit here?
And then if you think about that reference architecture that maybe we can link in the, in the show notes or like throw up a picture at some point, um, we can, you know, you can, you can, you can think of like, well, let's, let's actually focus on a subset of events, right? You don't need, you know, your MVP to have a full, um, you know, to be fully security compliant, uh, or, you know, have, uh, you know, the, the latest observability stack built in already. 'cause you, you're not going to production right away with this thing, right?
You need to first show the value to, for example, developers and say, Hey, look, you know, Jimmy right now is spending, um, you know, like, um, uh, is, is is waiting like two weeks every time, uh, he wants, he needs a database, right? Um, and, um, you know, Ann is providing that, um, uh, but you know, now she's like fielding this like oldest like ticket ops request for like 40% of her time, and that sucks, right? And so what you want in the first MVP is, is to actually show, okay, well I, you know, I, I proved the, you know, for example, I reduced the, the, the time that Jimmy needs out for database from like weeks to minutes.
And now Amy only needs to spend like 10 minutes, 10, you know, 10% of her time fielding ticket requests, not like 40, 50%, right? Like, and you know, and, and you can, you can show that within weeks, right? That's really the powerful thing I've seen, um, like very large enterprises move incredibly fast following this MVP framework, um, and within weeks show some level of success internally to the, the stakeholders they selected.
And then from there it's like, okay, great. Are we all happy? Yes.
Okay, let's go to the next iteration, right? And then of course, you should have, like, you should design the end design with, you know, security in mind, for example. But it doesn't mean you need to implement all the latest governance and security workflows from the get go.
'cause this is gonna slow you down and not gonna get you to actually show value. So, um, I think reference architectures and MVP framework have been, um, very, um, very helpful standards and very helpful best practices that, as I said, you know, we've been borrowing from existing, existing disciplines already, um, and just like slightly tweaked, uh, to, uh, to really help platform teams deliver on their, on their initiatives. Excellent.
Excellent. I mean, Luca, if I, if I had a boiler, it's a bad word to use, Cason gonna use that word. If I had to like, just really give people in one line here, right?
You, you, you don't wanna boil the ocean with platform as a product. You want. I you want to do it step by step, bit by bit.
Here's my question for you though. Do you need a master plan to begin with saying, okay, here's I, here's step one through six. It may take me three months to do step one, four months to do step two, four months later I'll do step three, but eventually I'll get to steps all the way through to step six.
Or do you just say, well, let's start with step one and then I'll decide what even step two is. 'cause I don't know if I want to make that, what, what I'm labeling now is step three may wind up being step two. Um, right.
So I'm not, I'm not locking into any of that. I'm just locking into step one right now. Totally.
I think it, I think it, um, I think it's a mix of both, to be honest. org actually has like different tracks. Like you have an executive track or business track, you have like a technical track, which is basically, you know, how you build everything, how you get the first like developer option, you have a security track, audio, make the security team happy, right?
And I think like different tracks have different timelines and you need to, right? So like, I think for security and business, for example, it is helpful to have a little bit of, you know, like a look into the future, right? Um, and like how do you attach, because you know, for example, like your business, your business stakeholders, like your execs, like, you know, usually sinking quarters or even like fiscal years, right?
So like, how do you attach, you know, your initiative to whatever their goal is, for example, for, uh, you know, for the quarter, for the year, um, in some cases multi-year plans, right? Um, on the developer adoption though, on the other hand, like, it's really what you were saying, um, it, it, it doesn't make sense to just get started, just get started, figure out, you know, what works, what doesn't, and then I from there, right? So, um, I think there's a combination, and this is also I think where it's helpful to think of your platform as a product.
You know, you know, we've built product, um, uh, products and, you know, the product is not just about building a product, it's also going to market with that product, right? So, um, and so that's where you have, you know, I think you have basically your product engineering teams aerating very quickly on building a product, especially at the beginning, right? And then as your platform matures, you can have like longer plans and like longer iteration cycles and so on, but at the beginning you want to be very nimble, right?
Um, um, and the same thing kind of like goes for your go to market at the beginning, you really need to figure out, okay, you know, which executive is gonna support my initiative and so on. But then like over time as it matures, you know, really like attach it to like, you know, very specific budgets or combination or budgets and so on, right? Um, but it, I think it's, it's helpful to, to to, to not only think of like platform as a product, as something that's like purely technical in terms of like, how do I drive developer adoption and how do I, um, you know, you know, I to rate reviews from a product perspective, but really broadly, like if you consider it as a product, it means like it actually needs like its own go to market, uh, its own internal marketing and internal sales effectively.
Um, and actually you can see this, I was, I was talking, uh, a while back to our Ericson, who's the guy that that built the, the, the turn developer platform is Salesforce five years plus ago. And you know, it's very interesting because, because Salesforce is so big, actually at the time, they had multiple platform initiatives sort of like bubbling up and competing with one another. And so there you have even, and obviously like in, in most organizations you wouldn't have that, right?
Um, but Salesforce, because they're so big, um, but there's some cases of like very large engineering orgs that have, um, similar situations. Um, and, and in that case, really you're competing, right? And you're competing on the product front, but you're also competing on like distribution on the platform.
Um, yeah. Yeah. But I mean, look, you see that in large enterprises that are built through m and a, right?
Where you, you'll have, you know, company A was doing this, company B had that initiative, company C, now they're all under one. com days, right? We had 30 different acquisitions and each one had their own, you know, not platform per se, but their own it, their own, they were all, they were all storing websites, they were all website hosts.
So there was 30 different platforms to coast websites on how do you pick one, or eventually you do want to get to one, but it took a really long time because you, you can't, you know, you're gonna wind up raking some eggs making that omelet. And, and, and, and so you, there's a, there's an art to that, right? That's, that's a whole thing in and of itself.
And, and, and how did you, how did you think about that? Like, how were you Well, we went bankrupt. Like I, well, what we, I mean we, well, because the do com bubble burst, that's, yeah.
That made it easy. I left, but no, but seriously, what we did do is we, we brought in, we, we developed one engineering team across all 30 acquisitions, one engineering team. And they basically took from each of the acquisitions what was best about them, what was the strengths, and then also looked at the wider state of art, right?
In the industry. And, and, and we did, we, we actually built a whole new platform that we migrated these two. Some, some were easy migrations, some were a lot harder migrations.
But we built a state of the art. 'cause back then, look, we, we had some companies that were using what I call baker racks, like that you would keep bread on, and they would keep white label servers on there. The hard drives are in the server.
The servers running Apache, and they got a thousand websites on there, right? Then we had other ones that were running like one U web servers to network attached storage, right? A very different kind of architecture.
And we had other ones that, you know, had, would load balancers and st you know, there was, there was a variety of, of, of architecture here. And, and we settled on one and it took, it took the better part of a year and a half, two years to really migrate into the standard. The company was called inter Reliant into the standard inter reliant architecture, which, which by the way back then was like IBM Domino server or something like that.
And, you know, it was, it was big enterprise level stuff. We were hosting a lot of AppSec. This was before there was cloud, you know, multi-tenants and all that.
And we're hosting Oracle AppSec and Lotus Notes and, and Exchange and PeopleSoft and, you know, crazy stuff in addition to websites. So we needed, and that's how, actually how I got into security. Then we had Layer Security in Checkpoint at the time.
Was it, you know, checkpoint was the big firewall, right? So we had managed checkpoint firewalls in front of this stuff. It was, it was really cool.
'cause we were way before our time, way, way, way before our time, right? Um, but it was, it wasn't anything like, we didn't have at our fingertips what, you know, platform teams have today, right? We were inventing this stuff outta rock and chisels, you know, you didn't, you didn't have the tools we have today.
But it was interesting. It was interesting. That's so interesting.
That's so interesting. And actually it's something that, like, we are seeing a lot in the community as well. Like, we do this, uh, this trainings with large enterprises, um, where we kind of like help them either educating their teams or actually like putting together strategy for the rollouts and, you know, phase rollouts and so on.
And I was actually working with like, um, okay, I think it's public right now, but anyway, it's like a very large, maybe the largest, I think CPG merger ever. Um, and you know, it, it's kind of like you have these two teams and they, they sort of like are gonna go in, right? It in, in gonna end up in the same setup.
And, and so like one of them wants to figure out, okay, what's the right strategy for me going into this, right? Because I have like something that's working right now, but obviously everything is gonna change. So like, how do I, how do I make sure that my platform evolves in a way that it ends up being the winning platform, right?
Uh, from an evolutionary perspective, it's the one actually surviving in the end. So very interesting. These sort of like m and a conversations where you really see this like, yeah, like internal products competing with one another.
Yeah. You also see personalities competing with one another, right? And that, and that's sometimes the personalities are harder than the technologies, right?
And, and, uh, that's a whole nother story. We could talk over beers one day about. Anyway, uh, Luca, this has been a fascinating discussion, man.
I loved it. Um, yeah, it is fun. org, we've got reference architectures, we've got tools and people and documents out there to help people as we go on, as they set, you know, set sail on this journey of, of, you know, adopting platform as a product.
Um, wow. What a great show this was. Let, let's can't wait for the next one.
Next one. We'll have some people joining us, so, well, it'll be more of a active discussion, but we hope you enjoyed this. Luca, how long are you in Sri Lanka?
Uh, three more weeks. Yes. Um, alright, so maybe for the next show you'll still be there?
Um, no, no, no. The next show is in February, so we're gonna Oh, okay. Yeah, because this almost mid-January.
So where, where do you think in the world you might be by then? Japan, maybe? I am, you know what, there's a cube con in Japan in June.
I was really had my eyes on, but we'll see. Yeah, it's a small one. It's only two days, but, uh, okay.
You going check it out. It, I might, I might. I'm looking for an excuse to go to Japan, so all Yeah, yeah, yeah, yeah.
We'll see how that goes. I'll let you know. Yeah.
Anyway, though, until then, enjoy Srilanka. We hope you've enjoyed our, the platform engineering show. It is at episode three.
If you haven't caught the first two, you can, they're available on your favorite podcast platforms like Apple and Spotify and all of that. Also on text Drunk tv. And, and they, uh, text Drunk TV is the website.
They're also on the YouTube text, drunk tv, YouTube, and I think by the, well, hopefully by the next show, our text Strong TV OTT channel will be up. So you'll be able to catch it on Apple TV and Roku and Amazon Fire, as well as mobile AppSec. But until then, is Alan Shimel Luca Galante.
I hope you've enjoyed the show. Take care, everyone. Thank you, Alan.
Bye bye-Bye. Thank you everybody.