Data. Why did it have to be data

Episode 5 · 2015-11-17 · 46:25 · SRT · archive.org · all Tanzu Talk

Well, hello again, Andrew. It's been a little while since we've talked. We've got such a large team now that I have to systematically go through and talk with our teammates and put you on the back burner to talk with. Well, I'm not hard to find, but we do have quite a crew now. I know. How big is the team we have now? We're 10. 10 strong. 10 people. And we're writing a lot in that Slack channel. I keep thinking I need to set Josh Long up with his own, I always jokingly call it the Josh Long open mic channel in Slack, where he can just come in and he just has these wonderful stream of consciousness things. And I think I need to finally do that. That would be wonderful. I'm not sure Josh writes more than anyone else, though. He just writes all at once. Well, he batches it up. And so it has this, it's sort of like every now and then there's like drive-by communication, which makes it seem like a large volume. Where most of the rest of us are streaming. Exactly. He's got the batch paradigm. We smooth it out. Just like delivering every day, we smooth out the risk instead of like these giant big curves of things. But yeah, I bring that up because that's the thing I wanted to go over is very, I would say I was doing some background reading for our, we have a new release of Pivotal Cloud Foundry coming out soon. And I was looking at what we had the last time I did a bunch of work around this. And I would say the nature of what we do, and especially after talking with customers a lot more since starting back in January, has modified a lot, right? There's still a lot of, a ton of operational and cloud things that we do. But a lot of what's going on now is going up the stack as well and addressing a lot of the application development and architectural concerns. What are you actually going to do with that cloud type of stuff? And I think, I think with the team that we have, which is sort of like the, I don't know, advocate team, some people might say evangelist,

but sort of the, the people who go out there and try to explain what's going on and also discover and help out. A lot of it is really, a lot of the people on our team are application centric. And I think, I think that reflects what at least in the customers and prospects I go to visit, the people who are using Pivotal Cloud Foundry, a lot of what they're interested in. They definitely want the operational stuff, but they're now pushing it towards how do we, how do we get into microservices and managing our application development in a new way? And just, just to wrap up, like I'm starting to look at it as really like the evolution of the, to use the proper term, the JEE market. Like as we record, Java one is going on now and there's a lot of, obviously from, from that community, figuring out what, what their mainstream future looks like. And I feel like we have a pretty good position of the companies we talk with. Many of them, they don't only work in Java, but a lot of them do. And they're looking at what we've been espousing in the Cloud Foundry world as like the way we should architect and develop our applications, which I think is, it's pretty interesting sorting that out. Absolutely. And I would say, and part of it is probably because of what I've done before and, you know, what people know me for, I still get pulled into a lot of the op-centric conversations. And we definitely still have those. So I wouldn't, I wouldn't say so much that we've, we've shifted everything to be app-centric, although there's, there's been some of that. It's that we've like included that as more. Exactly. Exactly. So that, that focus, looking at, you know, and connecting the dots from the bottom to the top, incorporating Spring, and that's, you know, that's part of this new release, the Spring Cloud services that give people, you know, access to a bunch of convenience with things like the Netflix open source that you can run in production, the same kind of stuff that they've been running. So I don't, I don't know so much that we've shifted, but we've just added and expanded that conversation to include the apps where before it was, you know, as you kind of pointed out,

much more focused on the, the infrastructure and like the platform capabilities. Yeah, no, and, and I think that's exactly the right framing and I think one of the most recent visits I had out in the field with people represents that where there's, and this is what, what seems to be happening in the industry and in the app dev and cloud spaces. People like to start at the bottom. They like to start out with, with the computer, the silicon, if you will, and then build up of how they manage the infrastructure, how they do all the operation stuff and how it gets built out. And, and then that kind of derives the style of application development that you'll do. And, and, you know, the, the chattering class of the industry spends a lot of time at that sort of orchestration that the middle of the stack, if you will. And so when, when I go out and talk with people, they're very interested in what's going on at the, like right below the application layer and they want to make sure that that's covered and handled as well. And when you kind of close out that conversation with them and you explain how, you know, I mean, basically like, here's our vision of how highly automated infrastructure works and how we govern and coordinate the way that processes and applications run and they coordinate together. Then it's sort of like, it opens up the next door, which is like, all right, now we need to write some applications and design them. And so I think it's those two conversations together that give you that, that fuller view. And, and what I've noticed, especially over the last six months is, yeah, I mean, most of the people I go out and talk with, they have to go through that whole conversation. And then, and then once you hit on the application stuff, there's like this whole other group of people that you talk with. The more of the enterprise architects and, and they're much more closer to the end users and the way they're sorting through how to use things like Spring Cloud and, and how to come up with their microservices is, is fascinating. It's fun to see them like sorting out the new, the new architectures they have to put up with. Like, like we were talking before we were recording how a lot of the, a lot of the style of architecture

is very similar to how you connect together a bunch of processes on a, on a Linux or Unix command line. Like you're combining things together. Except now it's distributed. Now your schedulers are across, you know, this fabric of resources instead of on a single machine. Right, right. And that's, that's where you have to have that marrying of operations and application together, right? It's, it's like there was this time back when both of us, if I remember, did Java development where there was this fascination with how distributed architectures work and distributed applications work. And you kind of needed to know all of that stuff. And then it seemed to kind of wear away slightly, at least at the architecture layer. But now, now that we're back to doing or thinking about and being real cognizant of doing distributed application architectures, now you do think about all that stuff. And so I think there's a general trend to reinvent Korba about every, exactly, every so often. That's why it's baked into the JDK. I also think that there's a, there's an aspect of scale, both scale and, and, and velocity that's different now than, than we saw in the past. Yeah. And, and I think that what happened in, you know, you, you just kind of alluded to it is the, there are sort of these basic primitive clustering approaches that were kind of baked into the J2EE app servers, but they're not, they're not really built to, to deal with the, the scale out architectures that, that we're seeing emerge right now. Right. And, and a lot of that just comes down to the, to the hard problems of managing state, which for whatever reason, it seems like most people refuse to think clearly about. Yeah. No, I, I think, I think that's, that's the hard problem. And, and, and making sure that you write your applications to, to, to properly deal with state or ignore it. I mean,

that's the other trick is like figuring out when to ignore it, but that's, that's where, that's where the annoyances come in. And I think, I think the trick is, and I, I mean this as seriously as I could possibly be if you ever met me, that's, you know, really serious. But the, the trick is pushing that, that place where you handle state into the place where you know that you can do it deliberately instead of, like, I think there's a tendency for people to just kind of smear state across a bunch of stuff. And then they're like, why is it so hard to manage state? Instead of, instead of, okay, like, let's do everything we can as stateless as possible. And then where we need to deal with state, we make that very deliberate and we can do things, you know, in a, in a sense, and this kind of goes back to my mental model that I've been trying to get people to understand around promises and contracts and the rest of the stuff. Like, if I, if I have to have state everywhere and manage it in, in, you know, different ways everywhere, then I have a lot harder time keeping my promises than if I have deliberately set up the, the stateless processes in a certain way, and then the stateful processes in another way, and I can kind of manage those in this sensible way that, that makes sense and I can, I can reason about it. Reason about both how it will perform, how it will fail, how I can recover, all these other things that I want to do to manage the full life cycle. Yeah, that's, that's like, when it comes to the database, that's, that's a reoccurring conversation I've, I've found myself and other people having when I'm out there talking with people is, there must be some name for this effect, but if you centralize all of your storage into like one place, as most people do into a traditional big, big database, there's a certain cut point where you, where because everything is in that one place, it introduces like a huge amount of complexity that you end up spending a lot of time with, versus like trying to always have reverting

back to that contract state where you have like state is really, you keep it as simple as possible, like the APIs too, it's simple, and you don't necessarily like jam it all into one database where you have to start worrying about ontologies and taxonomies and like, and how you modify things from time to time. Like I obviously haven't figured out what the answer to this is, but it's been interesting talking with people who are very obsessed with the schema and how you update schemas and how you do table upgrades and all of this stuff, which those discussions don't necessarily come up as much in a microservices world where state is treated differently than like a big honking relational database that you're always tracking with. But there's sort of like this general thing that I've noticed where the concerns you have, that you used to have, you're using different technologies so you don't need to worry about those things too much, like spending months governing the perfect ontology of what your data model is. Yeah, that's wrong. Right, right. The first day. Yeah, well, that's always been an exciting issue. I think pretty much every time I've ever talked, and this predates anything to do with Cloud Foundry, the conversation pretty quickly got to, how do you do database migrations? Yeah. Right, and it's like, well, these are technologies that weren't actually designed to be operated. They weren't actually designed to be, this is something I got all of our team watching, I don't know if you've ever watched the Joe Armstrong, The Six Laws of Reliability. Right, right, right. But one of the six laws of reliability is that if you want a system that never stops, then you, by definition, need to be able to do live upgrades. And how many database engines have baked into them, and there's starting to be some, this notion of a live online upgrade.

Right. And that's particularly hard in a database because you've got like this single point of running. Not to call it a failure, but as you were saying, right, the database was not written to have live upgrades so much. Right, like it's not, it's not written to operate that way, which bubbles up this annoying constraint. What year was the SQL standard published? Yeah, yeah. Isn't the most recent one like 92 or something? It's probably like more recent, but that's what I remember learning. Good old SQL. But these things go back decades, right? And there's a different world with different needs and that's why you've seen all the large kind of web-centric cloud-native companies move to other types of approaches and this is a buzzword of the yesterday, but no SQL, and I suppose it still has some conversations, but the methods that people are using to run cloud-native, large-scale, highly available, rapidly changing applications are kind of different than that relational model. And even when you have those relational databases, like when you start doing things like sharding and then they have the read and writes and you have separated like, we don't like using this language but it's the one everyone uses, masters and slaves, you basically went to an eventually consistent kind of separated model anyway. You just didn't take full advantage of the opportunity to separate it all the way because you're still basing on that older technology. So then, you know, while we're on the data topic, as it were, like, here's, how did we get here? On the data topic. That's right. Like, here's

something that I haven't sorted out yet, but I've noticed, this is a question I've had in my mind. So, on the one hand, you want to minimize variance, as you were saying, and sort of like, have some common ways of handling data. And then if you look at sort of like orthodox microservices speak, like, every single service that you write, or microservice, I guess, like, can make decisions about using its own data store. And so far, I haven't reconciled in my mind, those two things seem somewhat at odds. So the question is, when you look at, like, cloud-native architectures, like, how many different types of data stores are there really out there? Like, do people end up choosing just a handful or a couple, or do they really just choose whatever makes sense for the service that we're using? And I think this is a perfect kind of thing for the two of us to kind of go over, right, in the sense that you can approach it very well from the operations side, and I can approach it nicely from, like, the ignorant developer. I'm like the person who would end up using MongoDB or whatever, which, you know, because it looks awesome. It's that dopamine drop that you get right at the first. Exactly. And especially like in a microservices architecture. So, you know, with Pivotal Cloud Foundry, it's like we have all sorts of supported data services that you can use self-service and the way you end up managing them can be kind of normalized. But it does raise the question of, like, how many different data stores do you actually want to end up using, essentially? So, I was once a naive developer. So, I probably went through this arc. And I think if you look across the types of projects and people that do these things, I would, in my own project, if I was running something that was, you know, a small team, I would try to minimize the variation of the different databases, right? Like, I don't want to have, like, there is an operational overhead, there is a cost of

ownership to adding complexity. So, there's a bunch of things that I think the right answer for is, you should just use Postgres. Like, whatever comes out of your mouth, Postgres, right? Like, that's the deal. Or, you know, you could make it work with MySQL or something like that, too. But, as you start to get into more specialized understanding of what your needs are, what your rights and your reads and a bunch of these other things, then it starts to say, okay, like, this is probably a good fit for Cassandra, or this is probably a good fit for, you know, some of these other things like Reoc. And having the ability to make those decisions deliberately, like, with full understanding of what the costs and benefits are, is something that, you know, there's communities that have these kind of discussions. If you see some of the stuff, conversations that have gone on in places like Velocity and DevOps Days and Recon is coming up as an interesting thing as well. Like, there's that body of knowledge, but, you know, the spray and pray, like, let's put every database into the system, I think that ends up having more operational cost than benefit. Yeah, sounds like there's a lot of praying that happens as a result. I think, honestly, you know, and this is something that I think all of us have to some degree, it's fun to build things with new toys, right? And then those are also resume generating events. So if you, you know, read Hacker News or scan what people are talking about on Twitter and you hear someone did something with something, then you kind of want to see what that's about. But there's also, and there's people that are talking about this, explicitly, right? Etsy is heralded as one of the kind of more advanced in terms of DevOps and automation and deployment and continuous delivery and all this kind of stuff. They also have a great culture. They blog

about the craft and blameless postmortems, but they've also been very public about their deliberate choice of boring, boring technology, right? like they're not trying to drive everything with the newest, shiniest toy. They approach things with the mindset that I know how this will perform, I know how this will fail, and if you go look at their tech stack, it's pretty vanilla, PHP running on a relational database. There's like technologies you can trust. Right. And so that should not be discounted. When you're evaluating a lot of the new shiny toys, you don't really understand what the – so my strategy, like as a technologist, I don't actually like living on the bleeding edge of technology. I like knowing that it's there. I like reading about it, maybe even dabbling with it. When it comes to putting things into production, I kind of want to – if you think about the model of the chasm, like I want to be on the front lip of the chasm, basically. Like that's where I think you want to have reconnaissance to the early adopters and the rest of it, but there's a reason it's called the bleeding edge, and a lot of those technologies are not viable. Like they're not going to be there. So do you want that to be your blood or someone else's? Yeah, that makes sense. Plus I'm – I don't know. I think there's a fascination with technology and then there's the pragmatism of trying to get things done. And I think that that's a pendulum that swings and as you get new paradigms and new technologies, it can open up different opportunities to be productive, but you can also spend a lot of time, waste a lot of time with

technology that's not really ready. And I don't want to name any projects, but I have some fairly public rants about some of these types of things. And so it seems like, I mean, so there's a general principle to extract there, is like, so you should probably choose newly mature parts of your stack, right? Things that are, you know, you don't want them to be too old and slow moving and crufty. Mature is a wrong word, because that connotes years, but it's more like you want some assured stability of what you have, especially in the data layer, which might end up reducing the amount of data stores you can use, right? So, like, first of all, like, can you just do it with Postgres? Like, if so, you should probably just use that. And then, if you require something like above and beyond that, then it's good to have, like, both operational knowledge of, like, can we operate this and is it reliable? And then also the developer dopamine-driven knowledge of, like, is this really fast and easy to use? And have more of a balanced evaluation of using those things, which, which, getting back to my original question, I think would start to very quickly call out, like, way too many data, or I shouldn't say way too many, call out having a bunch of different types of data stores in your architectures, right? Like, that'll whittle down to just a few things pretty quickly. I think what it whittles down to is a few classes of things, and as you understand the overhead of running those, the cost, I mean, there is a time when, you know, there's a new database that came out, I'm not going to name any names, but if you know this, then you've probably been paying attention, and they published a bunch of benchmarks, and it's like, oh, we're faster than these other databases, okay. Well, then you go look at what they were doing, and they were taking writes, but never putting them on disk, right? Right. And so that was a trick that says, okay, like, you wrote something

to this, and then it wasn't actually written. So it was faster, but it wasn't actually doing the same work, so it was only an illusion of, it was an illusion of speed, and the trade-off was you never actually wrote your data, and so a bunch of people implemented this database, and then they ended up in situations where they lost data, right, or they couldn't recover from certain types of failure, and that's the type of operational maturity I'm talking about. It's like, what is the trade-off? And maybe there are situations where it makes sense to have that be the thing you're optimizing for. It's like, I don't care about this, I can deal with that failure mode, and that's fine, and I'll take that trade-off, but basically you should realize that's ephemeral data that is not going to be written to disk, or it's not going to be written to disk when you thought it was. That realization, that maturity, being able to analyze those trade-offs is what I consider system architecture, which is, I'm going to go on a slight rant for a second. There's this notion of architecture that's getting discussed right now that is sort of ivory tower focused on code, and we're going to talk about the code, and it's like, we have these separations of concerns, and solid, and all this stuff, and that's not bad, but there's like this missing discussion about system architecture, that there's a few people, and you sort of see this slightly discussed, although it's not as explicitly as I'd like, at places like velocity, and surge, and maybe some DevOps days, but there's this gap between architecture that people talk about with respect to code, and then like the actual system architecture that I feel like

there's a body of knowledge, and there's practitioners that kind of internalize this stuff, but there's not great resources, and there's not great conversations or communities where people are able to kind of, like you basically have to learn it the hard way right now, and that sucks, and that's when I go into places, and we have conversations with customers, and we see some of the stuff that's going on in the field, like I really wish there was these resources where you could say, okay, here's how you should think about these problems, like if you want to move fast, you want to move at scale, here's a bunch of properties around systems and architectures, and I think some of that sort of falls out when you start framing things in terms of promises and contracts, but there's just like this hands-on, kind of knee-deep in the mud, chest-deep in the mud experience, and conversations with people who've been through that, that's really lacking, and I wish there was a fast way to give people that knowledge, but I haven't figured out how to do it. Yeah, well, I mean, we've talked about this before, but it feels like across the industry, that is sort of like across the vendors and people who are developing these technologies, at the moment, collectively, we're not really interested in having a known de facto standard, like everyone across stacks talks about how they accomplish a common systems architecture differently, right? Like, they all have different words for it, and they don't necessarily unify together so much, and as a result, you don't have sort of like a common, like, I don't know if we're even at the state where we're like, we have a common concept like a three-tier architecture, or like, or I guess one of the more recent ones was the lamp stack, right? Where it was like, this is the general pattern that you're going to follow, and what P means might be different between, you know, all sorts of things, and might actually be an R instead of a P or whatever, but like, it's basically the same stack, which implies the same

architecture. But at the moment, there's so much fragmentation out there with all the, I don't know, various infrastructure stuff, that it's almost like we're saying the same thing, but using different languages. And, you know, we have the Cloud Foundry community that all kind of speaks the same, but there's other clusters out there who are speaking differently. So, as a result, when you go out there and talk with people, you almost have to start from scratch and triangulate and figure out the common terms and words that all map to that sort of like bucket of common systems knowledge, which is varying degrees of helpful depending on what you're interested in and are trying to accomplish. I mean, I think that's all, that's actually great and it's exciting. It's, it's the, the process where you go from innovation to kind of productization. There's a, there's, there tends to be a Cambrian explosion of, of approaches. And then, you know, I expect that to, I won't, I won't say it will, it will collapse, but you, you'll emerge with the, the standards based on, you know, de facto or, or, you know, I, I, I'm not always the biggest fan of, um, standards bodies, right. And committee driven standards. But as, as those things emerge, uh, and, and the utility of those things emerge, then it doesn't make sense for everyone to kind of reinvent everything from first principles all the time. Uh, but, but we're kind of in that phase where we're transitioning to this new architecture and everyone can kind of feel it in their bones. And, you know, we, we've, we've picked up the mantle of cloud native and that's the way we're, we're framing it. And we're seeing more and more of the industry adopt that same kind of verbiage. And, and they're all sort of saying the same kind of thing, uh, although they might have slightly different, uh, approaches. and some of that just comes down to, some of it comes down to politics and what all,

you know, and I say this all the time. It's like basically technology is driven by fashion and tribalism much more than it's, than it's driven by logic and, and reason. And, and we're just watching that play out in, in, uh, in our space. Yeah, no, no. And, and I, and I think I've, I've been seeing that trajectory, especially, uh, since I've been at Pivotal since the beginning of this year, but even back when I was an analyst, there is a, uh, uh, it's, it's almost like a, I wouldn't say drunken, but a mildly buzzed meander down the street to coalesce to the same stack. So, so you see, uh, you know, and, and, and there's cheesy ways you can track it. You can sort of like see the, uh, the sort of weekly infographic that comes out or, uh, kind of see the evolution. Like we're in conference season now. So you can see the evolution of the, the corporate slides that describe the stack and they're all starting to kind of look the same and have similar layers and, uh, we'll just, we'll just be in that kind of battle to have the exact words of what they're applied to. But I think the thing that's clear is that there's a, there's a new way to do things. There's, there's going to be a transition from, you know, whatever we, we've already kind of touched on this sort of app server that came out and try to solve problems, but that technology hasn't really evolved for the last 10 years. And so the, the enterprise people, um, you know, the startup people, they're all kind of finding this new way to do things and that whatever that next thing is, is we're, we're basically inventing it together every day. So, so then as the last topic, let, let me, uh, we'll go to a whole other part of the stack, so to speak, and, uh, just get your take on, on something I've been noticing recently. Um, so I, I've, I've gone to speak at, uh, several like internal tech summit recent tech summits at companies recently, and it's been really encouraging because the high level management is basically saying, um, to the staff, we'll just put it that way, like you

should go out and do new stuff, right? Like, like we, we want you to like look for new ways of doing things and be creative and really explore, uh, new ways of doing things. And, um, I've seen a couple of examples firsthand, uh, where I guess the staff kind of doesn't believe them and, and they're still almost shelled shocked from like a command and control structure of doing things. And, you know, I, I've, I, I have my own things that I tell like the management class and the, uh, the staff class about how that'll like get over that divide. But, but I'm curious like, uh, how you like sort of talk people through that in the sense of, we actually generally want you to go out. And this is where the example that comes out is, so we've picked a project that you can basically learn from that is you can kind of fail and we in the management level would really like you to tell us the failures and the learnings that you have. And, and they're really working on building up that trust between these two levels at the moment. And, and what I've noticed recently is that the, the staff level layers, like it takes a big leap of faith for them to do that. And so it's almost like, I'm, I'm, I'm, I'm always theorizing and curious about how, how the, the, the managers, if you will, can start to kind of construct these trust lessons that are sort of like metaphoric falling backwards and catching them. But it's, it's something that's been popping up more and more that I think is an interesting thing we should be advising people on more. Yeah, I think this is a fascinating thing to watch and it's something that the, you know, I'll just keep saying this word over and over the cloud natives realized a while ago, but, but we're seeing more and more of the enterprises start to realize this, which is that software technology, these things are a competitive advantage, not a, not a cost center. It's not a, you know, nice to have. And, and then the other thing that's

driving this is when you, when you really understand what it takes to make great software, you realize it's not a, it's not a science. It's closer to art. It's a creative act. And the, the types of work that you manage with what are, you know, essentially the industrial processes that kind of came from literally the industrial revolution. If you try to manage software with that kind of command and control approach, then you, you don't tend to get the, the best outcomes. And so, so that transition, and I think it's hard for both sides. It's not just the, it's not just the quote unquote underliens that are struggling with that trust. It's also the, the managers, it's also the organizations where, and I think this is one of the things that's interesting. If you look across the, the majority of the cloud native companies companies, you know, or like the, the big tech giants, right? Right. They, they're kind of the, the newly emerged tech elite are by and large led by technologists at the, at the highest level of their executives. Right. Where, where for the, for the enterprise, um, even, even the CIOs in many of these companies are not terribly technical. Right. and, and so that puts you at a significant disadvantage when, as someone who's trying to evaluate, uh, the technology, trying to evaluate the technical direction of your, of your company, of your, of your whole strategy, you're, you're kind of beholden, uh, to the, to the consultants. You're kind of beholden to whoever has the, you know, the most confident sound in their voice instead of being able to, to reason about the, the technology yourself. And that puts you at a disadvantage. So one of the things I just read an article, um, in the, it was like the financial time saying that, um, only 6% of the banks have, uh, technical, technical people in their executive team.

All right. Now, just, just a footnote really quickly, hopefully not to make you lose your train of thought. That's interesting because I've had this conversation with several people who they kind of see, they see a generational shift in, in, in managers who are not, not even cloud natives, but computer natives and who have much different expectations about what technology should be doing and is capable of, which, which hopefully we'll raise that 6% up, but it's, uh, as, as, as basically like software is more in the fabric of our lives to seal that, like that, hopefully that'll be help out on that point. Yeah. I think there's a bunch of interesting ways to frame that, but you know, and not, not to belabor the, uh, the war metaphor too much, but if you have, if you have generals and officers who, who've never felt the mud, who don't know what it's like to, to shoot a weapon or, you know, be in an actual war, then it's much the types of decisions that they make and the, the way that they perform is very different than if you have some of that DNA in the leadership. Right. And, and so, and so like, have you, uh, whether firsthand or secondhand, like encountered way of, uh, ways of like building trust between those two groups that they're actually shifting things over or is it just sort of like, uh, largely contextual? Like how, how does that pan out? I, I have a few tricks that I, I, I basically think that a lot of this just comes down to, uh, empathy and recognizing the, the human aspect of it. and there's one of the exercises that I made up in, in, uh, is as a workshop, I was sort of thrown into, this is way before Pivotal days and someone, someone had, had basically they, they tried to do an agile transformation and the developers were, were loving it. And then there was kind of like total organ rejection, uh, from the ops team. And, and then someone said,

well, let's throw Andrew into that and like, see what he could do. And so on short notice with like very little preparation, I was, I was put on a plane and like flown to, to try to help basically do kind of therapy, uh, for, for these teams. And on the, on the spot after I got in there and like, I saw what was going on and talked to them and we're all spending two days together. Um, I, I made up this, uh, exercise where I, I made them interview each other. And then what, what they do is each, I tried to pair them up with whoever they thought was the farthest away from themselves in the organization. And we spent, we spent an hour with those two having conversation and then each one of them had to write a press release. So they're all, they're all technical managers or, or, you know, technologists, um, at various levels of infrastructure and applications and they, they had to write a press release for how that other person that they just spent time with adds value to the company. And I got, I got feedback from basically everyone that that was like the most amazing thing for them. Cause, cause for the, for the most part, those were all like nameless, faceless functions. Like they knew the person existed, but they didn't really understand what they did every day. They didn't understand why they did it. And so to me, like trust is about patterns of behavior. And if you're, if you're tribal notions don't extend to this other person's perspective, their viewpoint, you know, obviously if you're, if you're in someone's cube and you see the picture of their kids on the, on the wall, like that's a person. But if it's just someone you interact with through tickets and they're annoying because they're not doing the thing you want immediately, uh, even though they're practically on fire themselves, uh, then you don't, you don't have that same kind of empathy.

And, and that empathy to me is like the basis for a bunch of these things getting solved with respect to trust and, you know, understanding. And it's the same thing where as, as a, as a technologist who struggled with technology, who struggled with delivery, who struggled with innovation. If you're, if you're leading a team that is going to go through that whole cycle together, then, then that's a very different approach than if you're just like, oh, I need to have these features by this date so I can make this other thing happen. Right. And, and like you'd like, you'd like those things to line up, but it's, it doesn't actually get you better software to just kind of crack the whip all the time. Yeah. No, and, and I, and I think, I think this, this falls in the category of, uh, I remember that, that conversation you had with Matt Curry a while back, like there was, there was a delightful part I always referenced where no one seems to believe the advice coming out of these unicorn companies that they actually have like two pizza teams and, you know, so forth and so on. Like, they're always like, what are you really doing? Cause that sounds like a bunch of hokum and, and, and it is like, we have this layer in our, in our stack of understanding what, what the stack is called the, uh, the cloud, you know, the empowered culture basically, um, which, which enables all of that. And as you were saying, like the basis of it, and, and I've seen this over my career and definitely recently is once you start getting people trusting each other, which, which sounds like one of those hokum things, right? Like surely that's not how you make things operate in an adult world, but once you actually get people trusting each other, then everything else is possible and more falls into place. So it does seem like you have to get over it. You have to take a leap of faith, if you will, that this is something you need to work on, but then whatever time you spend actually getting people to treat each other as people and just be normal and humane, like, uh, tends to pay off when, when it comes to actually, uh, you know, whether the management people and you want your staff to like execute

along these like new, like ideas of exploring and being creative or in the other direction, right? Like if, if you're coming from the bottom, so to speak, and, and you want management to understand a more agile sort of learning based approach to doing things, you have to get management to trust you as well. So it starts to make sense to actually just start to know the people so that they, they believe what you're saying and build up empathy. Yeah. The trust has to go in both directions for sure. And I think that, well, my experience seems to indicate that you got, you kind of get these self-reinforcing upward or downward spirals. And as you start to have results and as you start to trust and, you know, become a high-performing team, uh, you never want to go back, right? Like that just becomes the thing you want to keep getting better and better at, uh, where if you're in that, you know, cost center mindset, the, the scarcity mindset, then that downward spiral, like actually drives you deeper and deeper into this function. Indeed. Well, I think that's a good top place to wrap up. We've, uh, we've covered a lot of, uh, in, in, in an exciting scattered kind of way, a lot of interesting new developments around here. Do you have anything else you want to say before we, uh, end it? Well, the, the one thing that we, we had, uh, aspired to, to talk about that I think, um, maybe we don't, we don't explore this fully today, but we come back and might even be funded to do this with a couple different personalities at the same time is this, this transition, this separation that we're seeing. We, we, we kind of started hinting about it when, when we're talking about this proliferation of solutions. But what I'm seeing is a, is a trend towards much more, uh, application centric approaches, uh, application centric user experience, uh, with the platform, uh, that we're focused on versus the, what, what it looks like, you know, very infrastructure centric approaches, uh, that, the other, other, uh, projects seem to be taken. Yeah, no, and that, that's,

that's, uh, that would be a good panel conversation to have maybe, but, uh, I, I think, I think definitely like that's, that's what I end up seeing is, uh, most of the conversations I get, I get into nowadays, thankfully are about how do I architect these things out and how, how, what's the implication of, of using a microservices based way for, for the way I evolve my services, essentially the way I evolve my application and, and, and, and the bridge I always try to go back to, especially with the, the large organizations I talked to is, is, uh, I'll remember all that SOA stuff. There were a lot of interesting, good ideas in there and, and trying to sort out how, how we can actually make it work well. And I've actually, I've actually been in a lot of weird conversations recently trying to diagnose what went wrong with SOA. What went wrong with SOA? And I, and I think, I think a lot of it has, my theory so far is that it was the original goals were pretty much the goals that we have in the, the application and architecture conversations nowadays, right? Let's, let's make a bunch of services that represent various types of processes in our business, right? So like in, in the retail world, you have like inventory, you need to send inventory out to various distribution centers that show up in stores. And then you need to do an accounting of who bought what, and you know, all this stuff breaks apart into a bunch of little services and types of data. So we want a common way of representing those services so that we can very rapidly write applications that do something with it. Like if I want to, if I want to compete out in the crazy unicorn world and have an app that allows someone to buy something in my store and someone's going to go into the store and pull that item from the shelves and deliver it, like there's a bunch of software you need to write to make that operate effectively. I don't know, rather than faxing things around or something. I mean, I think, I think

what I'm talking about here is slightly different framing, which is that everyone's sort of talking about this new paradigm. Everyone's talking about these new architectures, but the way that you interact with them, are you coming from the bottom and building them up from the primitives of the infrastructure or are you abstracting them from the top and saying, okay, like these things should exist declaratively and then letting the automation, the application, which is the automation, make those things happen. And like who, which persona, if you will, is that experience optimized for? Right, right, right, right. Yeah, that makes sense. Yeah. Anyway, that could be a whole hour. That's right. Easily. Yes. What went wrong with SOA? I know, I mean, my where's the body buried? It's actually that it was, it aspired to be a service thing, but then it was implemented as a monolith. Right, right. No, and that's the avenue I was getting to, like laying out that lengthy example there is like, so you want, you want to write this new application that needs to use all these services and you end up spending all your time specifying what your data looks like. Like you spend all this time about the interchange and interoperability and very little on like the original goals, if you will. And so that, that seems like the distraction that happened is it ended up focusing on the wrong thing versus something closer or something that feels more like what you were saying is like, well, eventually all these services need to coalesce and run. They have to do something, not just perfectly exchange data. I think basically what you're saying is it started out with this great idea and then as, as always, it was re-implementing Corba basically. Exactly. That's what happened. That's right. We didn't like our IDL files. So now we have SOAP files. Perfect transition. Well, on that delightful XSD note,

no conversation is complete without a reference to XML, I guess. This has been Pivotal Conversations. You can always find the show notes and what we have at pivotal.io slash podcast or podcasts and we'll see everyone next time. Bye-bye. Until next time.

Tanzu Talk · 🍕 Get more pizza.