The Enterprise Event Loop, Multi-cloud, & more, with James Urquhart

Episode 114 · 54:27 · SRT · archive.org · all Tanzu Talk

Well, I don't have any prepared inanity to start this one with. I was thinking, you know, I should start a book, you know, Inane Cold Opens. There'll be 300 pages on the weather and I'll deal with that, which I think will work. But here's what I want to ask you, too. Now, on my other podcast, I had this topic, the Software Defined Talk podcast, last week. Here's what I want to know. What do executives actually want to hear? When you go talk with CIOs and stuff, what are they thrilled to hear about? What really, like, gets them chomping at the bit or whatever the metaphor of the year is? How about you start first, guest? Sure. My name's James Urquhart and I'm a field CTO at Pivotal. I think what executives want to hear is that you're going to make them look good. That you're going to provide solutions that are going to achieve the things that they see as most important in the eyes of their superiors. But also, I mean, you know, and that all has to do with customer success, driving customer success, driving revenue. It all boils back to the usual things that people talk about. But when I, you know, when I speak to an executive, it's more important for me to know up front what their biggest pain points are. What are the things that they are considering really critical to address? And I think when you can address those things, you have a good match. That's right. So that's always the most helpful answer is they want to hear what they want to hear. So you should find that out, right? You know, what the critical problems and stuff they're dealing with. How about yourself, Richard? What do you think? Yeah, that was a good answer. I would have just said Cooper Denny's. Thank goodness. James went first. No, I think that was a great answer. I mean, to your point, it's are we helping them focus on the right stuff? Or we may be helping them cut through the fog and just pointing out, you know, the outcomes that matter.

It's your point. Are we helping them solve a pain point? Are they stuck in the mud? So they want to hear kind of a path forward. I think every time we have conversations at that level is, do you all kind of know what you're talking about? Are you going to help me? And versus just like, hey, give me interesting information. They'll probably forget by the next meeting. That's probably not the point. Yeah. Right. See, we can't we can't help but talk about the weather with cutting through the fog. It's just we're old enough that that's all that that we it's everywhere we go through. Yeah. Next thing you know, in a couple of years, we'll be talking about, you know, cancer and which of our friends has died or not. Do the roll call. If I if I remember what my grandparents, their favorite topics were. And and as always, the price of milk. You got to cover that as a bellwether. Well, as as as mentioned, we have we have James as our guest on this episode. I think when did you join Pivotal? Was it January? I don't remember. First week of December. First week of December. Yeah. Well, that's exciting. Well, well, we'll we'll come back as always to talk with you. But first and feel free to join in. There's there's some little news items or things we would like to call attention to. What what what why don't you start us off, Richard? Yeah. So what do we got here? So the first thing I thought I'd point out was the the sneak who's a partner of Pivotal's great security company issued an interesting security report last week. It was the state of open source security and just a lot of findings. We'll have the link in there. You should absolutely read it. It's a it's an easy, easy read. But just a big increase in vulnerable libraries for people doing dependencies in their application code. Developers actually think they should own security, but don't feel like they have the right tooling. Even people who run open source projects want to be secure. They don't their goal. I don't think is to have an insecure library, but a lot of them lack some skills to do it. And if you look at the most popular container images, most of them have a lot of vulnerabilities in them. So it's just an interesting landscape review of, yeah, security still is a tricky thing. Here's some things to maybe focus on. And it obviously should probably dictate some of your technology purchases and strategy.

Yeah. Yeah. You know, I mean, I think as I've joked about here, I always I always metaphorically equate security to like food must taste good. And I guess I guess metaphorically speaking, there's a lot of food that doesn't taste good out there that that people are buying, which is unfortunate. Maybe they just need to add some salted butter. Yeah. I mean, look at like empty calories, right? There's a lot of processed food out there that people really don't know whether or not it's actually good for them. Yeah. So it's sort of sort of like a shelf cheese, like cheese that can sit on a shelf. Right. Exactly. Or, you know, truck step sushi. Oh, that's right. I mean, James, I guess question for you is even at something like this, maybe back to the even that early question. I'll tell you aspect what executives care about. I guess very few of the current technology we're all touting right now, whether that's containers, whether that's microservices architectures, whether that's even serverless, don't necessarily negate most of these concerns that they call out here. Like now you're using containers from third parties could have vulnerabilities. Now your app code is more distributed and you're using more dependencies than ever. That's a new attack surface. And serverless in a single cloud. Well, now there's a single place to go attack you. Like, it just seems like the ball, I don't know, maybe the goalposts keep shifting versus necessarily stamping out old security concerns, new ones are popping up. What's your sense of that kind of, I don't know, is there any sort of false confidence we get from current trends that some of these old things are going away? Or are we just finding new problems? No, well, I think there is a trend that's understood that as you move to clouds where other people have to maintain layers of what you're dealing with, security is their problem at those layers, right? The Amazon shared security model, I think it's sort of becoming the assumed model in a lot of ways for people who consume cloud. So that part of it is kind of good, right? If you're a developer and you're like, you know, now more and more the unit, the deployment is the unit I actually care about.

So we're going from, you know, from servers to processes with containers to functions with serverless. That's great. And all that other stuff should be dealt with by somebody. However, if you're going to consume stuff that has been delivered by an unknown party that you can't identify succinctly that they are maintaining the security and that they will update and patch and have a mechanism to update and patch without disrupting you, then it is, in fact, your problem to deal with the security of those third-party things that you're consuming with and to make sure you understand them. Which is why I think there's so much focus in a lot of organizations on vetting what containers are allowed and consumed within the organization. And so, you know, putting more restrictions on what developers can do in order to increase or decrease the risk of security issues. So I think we're going to have this heave and hoe for a while. And it might drive mechanisms in the industry to make sure that things are secure before they're offered like what Apple does with the App Store. Or it might drive, you know, insane decisions by individuals and organizations to, you know, jump through hoops to test everything that they've got for security problems. I guess that's not insane, but, you know, but there's going to increase the workload for the dev. Sure. Yeah. You sort of have, you know, at the very minimum, new things to worry about. And as a result, the, I don't know what the security people call it, but like the models of consideration to think about when there's some new thing. We lose sight of the fact that there are new things to worry about. We lose sight of the fact that there are some old things that are being taken off the table for us to worry about. That's a good point. Right. So it's, I don't know that it's a net even or anything like that, but I do think it's important to note that, that, you know, there are mechanisms out there that allow others either within your organization or outside of your organization to deal with layers of security that were your problem in the past.

Yeah. Yeah. Your problem. Well, speaking of your problem in the past, we'll see if this transition works out well. So that, uh, as, as I mentioned over the past, uh, I don't know, many episodes, I've been working on this little booklet or report as O'Reilly calls it. Uh, and, uh, now it's available, uh, for people to have, I don't know if you can like get it from somewhere other than pivotal at the moment, but, uh, it's called a monolithic transformation. And I had, I had our, uh, I, I had a moment of marketing genius where I came up with a very lengthy URL, which is a pivotal.io slash monolithic transformation, which, which, uh, you know, you got, you got a spelling challenge there. How do you spell monolithic? But, uh, so that book's out now. People can go check it out. And, uh, I think maybe there's like three sentences on security because I don't know anything about security. Uh, so, so why write it? I figured I'd use all of my, my, uh, my energy on talking about things I don't know about on the rest of the book rather than security. Makes sense. That's a good book for, uh, Coté not plugging the content, a lot of the content itself, but it's a great book. It's absolutely something everybody should read. It's freely available. It'll be up on Safari books online in a couple months. But I think pivotal gets a free period where it's just available from us. Oh, an exclusive. It is an exclusive. So, so when, uh, when, when am I going to be able to retire to, uh, a Tuscan villa since you've written one of these reports? What's the timeline I'm looking at, Richard? Yeah, I think it's when you're about 300, uh, based on the number of royalties. Yeah, that's right. If I, if I survive the, uh, the, uh, cancer, the cancer parlor catching up of old age and, uh, and become a vampire, then, uh, then, uh, you know, it'll be fine. Yeah. Yeah. What do you think the average length of a vampire's life is? Do you think, do you think, do you think they do all right? Or do you think it's sort of like a high risk early, early death situation? Well, that's a good question. Cause yeah, I think the average, I mean, you're not being killed. It's not like six or 800 years old or something like that, but you're right. You are.

There's a lot of stakes in the heart risk going out and around there. It's a, it's a high stakes life. Oh, it is. Well, also the digital transformation, stay for the vampire talk. Exactly. Maybe that'll be our new topic. The undead. Uh, well also, uh, you know, it's speaking of other things we launched, uh, we launched the intersect website and newsletter, uh, which, which has already got, it's got a, uh, CIO's guy. Speaking of what executives want to hear, there's a CIO's guide to Kubernetes, which, which is pretty good. I, uh, I, uh, I sent something over about like how to actually like test and validate corporate strategy, which, which, uh, we'll see if that's anything, but, uh, what other kind of stuff is, have, have y'all seen on there? Well, yeah, James already has a piece up there. Oh, that's right. I published a piece on, uh, an interesting effect that I saw that we could talk about later, but in the short, um, with, uh, using a platform and having a platform team that can maintain security of, of, of all the, you know, the, the, the building components and, and the underlying, uh, operating systems and systems and so on, uh, a, a very large bank was essentially, uh, discovering that they had no of the normal resistance that they get from security and audit teams or very little of it, much less of it. Um, and, uh, surprisingly more resistance from developers who were nervous about all that stuff that was being done for them and what that meant to their productivity. And the great thing about the platform is, uh, it, it shows you that you can update all that stuff and not affect developer productivity. Yeah, no, it's great. I mean, one of the reasons for those who are unfamiliar with intersect, we, we launched it mainly because we saw a gap between, I don't know, cause some of the general purpose executive advice and then the super low level, like, you know, here's how you configure something, you know, you know, Bosch manifest or Kubernetes release. So what is that middle section of like executive advice about technology? And so that's what intersect is it's website, it's a newsletter.

So definitely go check that out, pivotal.io and see what you think. That's right. There's no, uh, there's no, uh, Mecco charts in Bosch. Unfortunately, you can't, you can't automate your, your strategy. Need some other stuff. Well, and, uh, you know, do people, are people still, uh, pedantic about on premise versus on premises? Are we over that? What are y'all two encountering? Oh, I'm, I'm pedantic as heck about it. So I, I assume premises, on premises. That's right. No, it's on premise. Uh-oh. Oh no, it's on premises. No, you're right. It's on premises because premise in the case of on premise means the, the, the context around an idea, right? The premise behind an idea. That's right. So, so maybe on premise would be, uh, the idea originates from you. It's on your premise instead of some other person. You haven't outsourced your, your thinking to someone else, which, which is probably good, except maybe, you know, in like medicine and things like that, you might want to outsource it and, and, and I hear in finance, but you know, we'll see. Well, uh, there's a couple of on premises, uh, items one, uh, there's, I think, uh, there's a beta of, of Google's, uh, cloud thing out and, and you wrote a post on that, Richard. So give us a little summary of it. Yeah, I just dug into it for an InfoQ article about their new cloud services platform, pretty much a hybrid kind of play from Google that for something that runs on-prem, uh, it's really the flagship part of it is the Google container engine on-prem or Kubernetes engine, GKE on-prem. But then they wrap in things like Stackdriver for monitoring and you can put things like Knative on it, really, again, recognizing the hybrid need people are running in both places. One of the things I referenced in the article and the Google fellow who they quoted in there is making the statement that instead of even seeing it as these clouds against each other, like it's Google versus Amazon versus Microsoft versus IBM and Alibaba. It's really the stacks. Like what are the durable stacks that are going to win? And in their mind, this could potentially be that durable stack made up of like SEO, Envoy,

Kubernetes, K-Native. Like, does that become a new LAMP stack, hypothetically, or something like that? But those are a durable stack that kind of wins at the market, almost agnostic of the cloud. So interesting, interesting goal there. It's just certifying an on-prem platform takes a long time. So just the question will be, given they say, you know, even Google says, hey, we want to go through all the certifications. That's a long journey. So I don't know when customers can really bank on this being a thing. Yeah, it's interesting. It's an interesting play. I worked on the Microsoft Azure stack stuff in the early days when I was part of Dell. It'll be interesting to see. I personally think it's all about the services. And so the stack matters less than the availability of services that work the same in public. Interesting. But that's a personal opinion. Oh, you mean the non-human services? Yeah. Yeah. Yeah. Yeah. Yeah. And the non-humans. Yeah. That's a good distinction. Yeah. No, I mean, it's all in terms of the infrastructure services and cloud services that are delivered. Yeah. The actual features that are out there. I don't know, to put it one way. Well, then also, there's now... I was talking again on my other podcast about the impressiveness of the page over at VMware on their Kubernetes distribution where they're just three things. But there's... And just very clear links of them. But now from VMware and Pivotal, you can get three distinct Pivotal container service. I don't know what you would call them distributions or running instances. So you got your community one, which correct me if I'm wrong, but it's kind of the ongoing evolution of the Heptio thing to have with some sort of community-driven support around it. And then you've got your, let's call it classic Pivotal container service. And then there's a, I don't know if people call it managed anymore, but there's a managed run for instance that you have that VMware will manage and run for you.

So what did I get right there? I mean, I love that you, I mean, amazingly, for each three, I actually used the wrong name for each one, which just makes me love to run for instance. I try to, you know, I try to be unbiased. They always tell me, they always tell me when I go talk, don't give us a vendor pitch. So if I'm ignorant of what the vendor does, I can't give a pitch. Oh, it's perfect. I mean, I was really thinking the last one you were going to get right, but that was, that's why I love you. So yes, essential PKS is upstream Kubernetes, a lot of Heptio stuff, absolutely. Enterprise PKS is the one you already know and love, the one that runs on all the clouds, kind of traditional PKS. And there's Cloud PKS, the managed one that runs in AWS and other clouds in the future. So the goal is, look, different Kubernetes for different stages. If you already run this yourself and you really want support from now one of the largest contributors to Kubernetes, not to mention the company that has two of the creators in there, like that's probably a good service to buy. That's great. If you don't really have those skills internally and don't want to be in the business of running a lot of Kubernetes, the enterprise is great. That's an ideal choice, especially when developers are asking for it. And if you want nothing to do with it except serving up an endpoint, then you use the hosted managed version. It's not even a progression, I don't think, because you could go from immediately to the cloud version. Or you could be using the essential one because, look, you already feel like you're experts. You just want somebody to call if something breaks. So I don't think it's even this sort of progression that you move between them. It just means where are you at which stage. Any of those could be a good choice. Indeed. Well, thanks for correcting me there. I'm going to go make some flashcards and I'll practice that. Have you all ever looked in Kindle and they have flashcards in there? Like, I always wonder if anyone actually uses that. That seems like, I don't know, maybe for the textbook stuff, but it seems awfully proactive of people. It's sort of like if you logged into Medium and by default it did the five paragraph essay template. I'm not sure that's a technology anymore. So then finally, there's a couple of items that you put in there, Richard.

Do you want to cover those? And then we'll get to James. Yeah, real quick, just for those who are starting to pay attention again, even from an executive leadership level, let alone technical leads, but chaos engineering. And they see this idea of purposely introducing some instability, if you will, to test hypotheses about the reliability of your systems and what happens when certain things go wrong. And how do I test and experiment, not just randomly shut things off and see what happens, but have some hypotheses, test them, harden your systems, make them better. Gremlin's a great company who does a lot of great stuff around there. They announced a free version of their product that helps you do things like shutdown attacks and actually shut down and reboot different hosts or containers so you can experiment and see what happens. Or even kind of CPU tests to see what happens if you just flood a CPU, what happens to your application. So Gremlin's great software for this. There's other technologies that help with this too. But if you're trying to dip your toe into chaos engineering, it seems like a great choice. Well, then also, before we get to the last part, I just want to remind everyone, we've got a bunch of SpringOne tours going on. These are little regional events we have that basically bring, it's mostly programmer focus, but we also go over things like Kubernetes and Pivotal Container Service and Pivotal Cloud Foundry. And the ones I go to, I try to give some discussion about why all this matters and, you know, aligning with the business and overall how you're improving the way you're doing your software at a corporate level. But we've got one coming up in London, March 18th and 19th. And, you know, I think that'll, I'll be at that one. It'll, it'll be fun to check that out there. And then there's going to be another one in Amsterdam on March 21st and 2nd. And of course I'll be there. And there's a way to get a reduction, a discount on the tickets. If you go check out the show notes over at pivotal.io slash podcast. And if you have a pin ready, the code is S1TOUR2019 underscore 100.

So that'll, that'll give you some amount off. Interestingly enough, it's not actually a hundred units of cash that you get off. So it'll be a fun game to see, see what you get. And there's all sorts of other SpringOne Tours happening globally. If you want to go check that out. I think you can go to SpringOneTour.io to see it. And then finally, I know all of us are excited about this. The, the call for papers or the submissions for SpringOne platform is open. So there's probably each of us is, is helping select talks in various tracks and doing things like that. So you can be guaranteed it'll be a great show. And because Richard's involved, we'll use the proper product names for things. So you'll, you'll have that. No promise. But it'll be, it'll be in my hometown of Austin, Texas. So it's a good excuse to come to Austin. And I just remembered that either weekend there is Austin city limits. So we're sandwiched in between there, uh, like, like some delicious meat, uh, between two pieces of, uh, of good bread. I don't know. I'm going to go for maybe a pastrami or a Reuben. I think that's, that's what it seems like. But, but, uh, anyways, it's, it's a good, it's a good reason to come check out how to, uh, help your organization get better at software. And, uh, there'll be also just sort of like general, uh, improving the way you do programming and also, uh, do your, your operations and DevOps and things like that. And then you can come to Austin, eat a beef rib or, uh, some excellent vegetarian, vegan options if you're not into that kind of thing. So, so with that, why don't you, uh, give, uh, give a, uh, a large introduction to yourself? What do you, uh, what, what's your story? What, what do you, what do you do around here? And, uh, what have you been up to in past years? Who are you? So again, I'm, I'm James Urquhart and, uh, I'm in the field CTO, uh, global field CTO organization at Pivotal. I'll explain that a little bit more in a second. Um, my background is in distributed systems, uh, since the early nineties, I've been working in various forms of what that means.

Uh, uh, early, early client server work with, um, small talk and believe it or not, a small talk front end talking to a Fox pro backend, which, you know, some of us who come from that era will recognize as not being as weird as it sounds today. Um, and, uh, kind of, uh, first vendor that I worked for was a company called Forte software, which did a 4GL environment for building distributed systems. Um, I spent, uh, four years working in the field as a consultant there and learned a huge amount about, uh, the pressures of, of building a distributed system that can scale, that can fail, uh, has failure recovery capabilities and so on. Um, and, uh, uh, uh, when Sun bought, uh, Forte, I spent about six years doing various things at Sun. Um, if you were forced to change either your screen name or your username at some point with, uh, Java sun.com or, or one of the other sun.com properties, that was me. I, uh, I, uh, I drove that project and, and, uh, various, uh, interesting things in my past there at Sun. It was a very kind of heady time at Sun. And then, uh, from there, uh, did, uh, some work at Cisco, um, and, uh, uh, doing, uh, cloud strategy work, uh, worked at it before that I worked at a company called Cassatt, which did, uh, distributed, uh, the data center automation. And, uh, that sort of led me to start blogging and led me to start writing a blog called the wisdom of clouds, which, um, which was an early cloud blogging, which, you know, I was very lucky, got quite a bit of play and, and quite a bit of, uh, uh, influence for a while there. Um, uh, ended up at CNET, uh, ended up the blog ended up at CNET about the time that I was at Cisco doing the cloud strategy stuff. Um, and then, uh, I went to a little startup called in Stratus, which did, um, uh, uh,

multi-cloud VM automation, uh, back in the EC2 pre-container days. And, uh, that was eventually sold to Dell. Um, I did, uh, VP of product there. And so, you know, they have a really wide, varied background in both field and product, um, uh, related roles, um, over time. I, my last, uh, role was at AWS where I was a GM for a team that was working on, uh, a application for, uh, the field that they were wanting to platform eyes for the rest of Amazon. And then, you know, I'll just simply say that it is AWS and they're always looking for things that could go further, but our target was Amazon at the time. Uh, and, uh, and, you know, as, as that wrapped up, I, uh, decided I didn't want to manage engineers anymore and wanted to get back out in the field, get my hands on stuff. So I came here to Pivotal and the CTO org, the field CTO org at Pivotal is a resource. It's really, uh, some amazing people on, and then me. Um, but some of, there's some great people out there that know a lot about, um, uh, about a number of core enterprise distributed cloud-based development and cloud native development topics that can speak to an executive and work with an executive on, at the strategic level. Um, and in terms of sort of, uh, helping to evaluate the effectiveness of how they are approaching cloud native and getting the benefits of cloud native. Um, so we do a variety of things from, uh, you know, from kind of security deep dives to, uh, you know, uh, helping to, uh, watch how a number of different projects are adopting new cultural practices and, and the pivotal way. Um, and, uh, and to talking about different ways that digital transformation that, you know,

that, that software can affect digital transformation and how that, uh, how the platform can be applied or software can be applied with the platform to address those issues. Um, so I'm bringing to a number of customers, uh, mostly in the West in my case. Um, but there are the people that will, um, all over, uh, internationally and, and, uh, but we're applying, I'm applying, uh, my background in distributed systems development in, uh, in identifying software as a complex adaptive system. Um, and what that means in terms of, of, uh, design and practices, uh, in terms of, um, cultural change and, uh, the, the topic of, uh, uh, Mike's great book, uh, is it, is it something that I've gone through several times, uh, um, deconstructing monolith applications. Um, and so I'm bringing all of that background to these customers and working, uh, with, uh, senior technical people generally in terms of identifying the best strategic way to approach those things. That's awesome. Good. So one of the things to me in that, that long history is, you know, especially with the instantaneous time as you were thinking multi-cloud way back then when it was like, Hey, do I need multi-cloud manager tools where I spin up infrastructure in different places? What's your take on the current, not just multi-cloud landscape, but even the imperative? Like what, why does someone really do that? Why does someone care? What advice would you give to a leader in an organization around the multi-cloud strategy? Yeah, I, my, my personal opinion on the multi-cloud strategy is it's, it's very critical in two contexts. One context is, is that you have an organization that has a lot of things that just won't move tomorrow and migrate in a, you know, six month migration plan, uh, because of various technical requirements, because of maybe regulatory requirements, because of, um, uh, resource limitations that

you might have, um, in those situations, um, very often it's, it's good to allow, um, or things to happen organically in terms of cloud native adoption. And in those situations, you may have on-premises plus, uh, a public cloud, or, uh, very often there'll be on-premises and multiple, uh, public clouds in part because some of the technologies at, uh, at, uh, one cloud vendor may be better for the technologies that were used in the legacy system, uh, uh, prior, um, versus another that gives you, you know, better innovative capabilities or whatever it may be. So, um, that's one area. And the other area then is, um, organizations that are really looking to, um, to spread risk and to take advantage of the strength of certain, um, cloud providers. Um, and, and generally where I see this is, you know, a, an adoption of, um, Azure or, um, or AWS for kind of compute capability, and then maybe a focus on, um, GCP for the data services that they have and, and, uh, some of the really innovative data, um, and analytics capabilities and machine learning capability that they have. Um, but there, there may be a number of other different reasons why an organization that has enough applications out there with enough different use cases will say, you know what, you know, love vendor A, but there are technologies that I really don't want to lose sight of in vendor B and I don't necessarily want to wait for. Um, and so in those situations, uh, once again, um, you, you, it's hard to predict where those applications will end up. And so you need some flexibility in the way that you consume clouds and those, uh, but those are the two kinds of use cases where I really see it. And if you're, you know, where there's less of an imperative to do multi-cloud is in an organization where it's maybe a startup or it's an organization that has a very consistent,

uh, set of technologies they need to bring forward. And there's a cloud provider that meets that need very strongly, uh, in those situations, there might be financial incentives from the cloud provider that would make it, uh, reasonable to, um, focus on one vendor versus the others. Makes sense. So, so, uh, somewhat related to that, like, I mean, as, as you're going over, there's a, uh, in a, uh, a mature, usually well-functioning, but sort of like big organization, there's, there's a whole lot of existing software, maybe even some of your, uh, you know, your Fox pro stuff from back in the day. I think there's some file maker things I wrote that might be operating somewhere still, uh, which, which is exciting, which, which didn't Microsoft buy one of those things, Richard, or, or am I missing? They bought Fox pro. I think file maker is still out there. That's the first thing I was programming in like 98. I think I haven't checked in a while, but I think, I think file makers into not indirectly, but I think they, Apple owns the company that makes file maker, which is curious. Yeah. Any, Claris, I think it's called, uh, anyhow, uh, how, like, like, like, I mean, especially since, you know, in part, part of your background is being in the, uh, the, uh, I don't know, the, the exciting, uh, Sotterati class of cloud stuff with the wisdoms and the whatnot. So like what at this, at this, uh, this is like, what is this? March 4th, uh, 2019. What's the deal with like bimodal IT as something helpful or not? Cause it seems like, um, there's a lot of stuff to deal with. And if, if, uh, if you're sort of going to apply like awesome DevOps principles to like your highly customized ERP system, it seems like there's some way that that should be managed or not. And, and, and, and to close out my, my statements here, you know, the, uh, the, the DevOps people were all like, you know, bimodal IT is going to destroy you faster than just, you know, lighting your ship on fire in the middle of the Atlantic.

So you should not do that. But, uh, where, where are we as far as like balancing out in a large organization, how you should think about your existing portfolio versus your brand new stuff. Yeah. I'm not a big fan of the bimodal IT concepts. And the reason is because it creates an, uh, an unnatural silo between, um, teams that are working on different technologies that is given the history of silos that we've seen in the enterprise in the past, uh, is going to end up with politics that you don't want. It's going to end up with bureaucracy that you don't want. It's not, uh, a smart way to go after, uh, improving your organization's, um, ability to adopt new technologies versus old. I'm, I'm more of a fan for an organization that's mature enough in their culture, um, of of what Simon Worley has talked about, um, with, uh, the pioneer settler town planner model. So it sounds like it's a three modal thing. What's the difference? But the real difference is because there's an intentionality in that model of, of, of driving the stealing of technology from say settler stealing from what the pioneers discover and make work to build and scale out new applications that have value and find that value in their respective market, whether that's an internal market or external market. And then for town planners to, to take the stuff that really works that the settlers have discovered actually has a market and has a, a need to scale, um, and has a definition to some definition around to it, and then to drive both scale and efficiencies out of that. Um, and so, you know, as, as Simon's been pointing out lately, it takes a fairly mature organization that has a culture in which technologies can be easily consumed across those boundaries, um, to drive that, that. So the first thing I always tell every organization to work on is, you know, you've got to get good at that cellular structure, um, for doing development. You've got to get good at that ability of understanding that there, there are owners for pieces of what

you do. And those pieces are going to be codependent in various ways and have to interact with each other in various ways. So you need to build the culture and the technology, um, but culture first in this case, to really allow for that, um, that shared operation and that, that treating everybody that is dependent on your technology as a customer, uh, as opposed to as another team that that's, you know, that's filing tickets with you. Um, and that transition, that cellular transition allows you to begin to look at which projects kind of need what kind of people and what kind of attitude to, um, to do what they need to do. And if it's experimentation and heavily trying to figure out whether you can make something work, you have a pioneer to kind of take it. If it's, Hey, we've got something here that works, but we need to figure out how to productize it, how to make it something that's easily consumable and that has a market fit. Um, then you, you get a team of people who are really good at seeing the value in technology that's been created and figuring out products from that. And then, um, and then, or, or, you know, and there'll be multiple teams of this. And then if you've got something that's like, man, this thing is really critical to the business. It's got a scale. Um, but also we, you know, we need to get the costs, uh, uh, you know, make sure that the costs are as optimal as possible in running this thing. And it's not going to go through massive change. It may, it may get updated regularly, but it's not the form of it won't change significantly. Then, um, you know, you get people who are really good at driving that. So the people who've been owning data centers for the last, you know, 20 years, probably, um, a lot of them are really good town planners. They, they, they are focused on driving efficiencies out of the system as opposed to how fast can we build this up as, you know, as big as we can. Um, and so, uh, that's, that's the model that I see, um, in the longterm is kind of working, but you got to start with that cellular structure. You don't have the flexibility and the breakdown in bureaucracy that will allow it to be successful

or allow any model to be successful. Cause as soon as you have those, those lines, hard and fast lines and political lines between different technology groups, they won't interact, um, or they'll try to avoid it. And you'll end up with two pounds or three pounds or four pounds or however many of those boundaries that you have. Yeah. I, I, I get, you know what the, the, the word I kept, uh, remembering as you're going over that was just, uh, intentionality. Right. And I think, uh, uh, uh, I don't know, I always joke overly about it, but like, you know, you should, you should stop doing dumb stuff. Like, like if, if there's some way of running it that's like not working and, uh, you know, you're the, the, the classic bugbear example is we have this system that was awesome 10 years ago and now it's, it's mission critical, but we have to keep dumping money into it. And the business doesn't really understand the value of it. Cause we're completely disconnected and people are grumpy about it. And, um, you know, there's, there's rather than thinking like, Oh, just let that thing keep running. There are definitely, uh, plenty of, of lessons about how to, uh, run the culture of that, so to speak, so that, uh, things work better. And then, you know, I also think, uh, you know, there's a certain amount as, as you were saying of, you're just setting yourself up to have more of these problems in the future. You're basically avoiding fixing the problem. Uh, but, but that's a, that's a, that's, that's a good summary of it. I was thinking, you know, we should do is we should get a transcript of your answer and use that as a new intersect post. I think that would, that would be exciting. There you go. I think that is what, let me just give it one quick soundbite piece of it too. I personally think that it's harder to decouple development, uh, you know, development innovation. Uh, I think it's easier to decouple the development innovation from process than it is to decouple it from politics. Yeah. Yeah. Wait, what does politics mean in that con the context of it and all of this? Well, I mean, a lot of this has to do with people's control and, and, and influence within

the organization, right? So, um, organizational structure, um, uh, ownership of major decisions. Um, I, I think very often when you have, uh, uh, you know, it goes back to, um, to, uh, uh, uh, I can't, Conway's, uh, right. It goes back to this idea that your software will reflect the, the, the communication, the communication structure of your software will reflect the communication structure of your organization. Um, when people are still fighting to maintain, uh, an organizational structure that gives them some influence and gives them some foothold to, to move forward, um, very often to me, that's, that is where it gets harder. When somebody says, look, the way I'm going to, um, the way I'm going to, uh, to gain, um, political influence or the way I'm going to handle my politics is to actually give up some control to a more cellular thing and allow, you know, allow the success of that, uh, approach that's been proven over and over again elsewhere to drive my success and make, and going back to the beginning of the podcast, make me look good. That's going to be my political influence. Um, those, those are the, those are the executives I see being significantly more successful, um, right now within it, but there's still plenty of people who look at the town planner kind of scenario situations that they own and they say, uh, this is going to stay like this because it works and because it gives, you know, and because that's my success story. Yeah. It reminds me of, uh, the politics part of, I should go back and reread this book now, but I read this book, uh, the Wolf and CIO's clothing. You ever, you ever read that one? It's by a, uh, uh, a Gartner analyst. I don't know how to pronounce her last name, so I will do it. It's, uh, it's, it's by Tina Nunyo, N-U-N-N-O. And it's, it's, uh, there, there's the positive version of, of, of her advice and also the negative version or cynical of like how to deal with politics and organizations. And it's basically, as the subtitle says, a Machiavellian strategy for successful IT

leadership. I was, I was, it'd be fun to get her to come like give some talks, but yeah. And, and then, and then also just to, to, to free associate. It's interesting that the, as I recall, uh, the, the sort of literal definition of politics is like of the people. Whereas really when we say politics in this context, we mean of the rulers, so to speak. So it's a, it's a fun, uh, mismatch of it. We should come up. I don't know if it's, uh, oligarchy X. I don't know what the, uh, the proper ancient Greek phrasing would be. Yeah, that's interesting. Nice. Good. Well, I wanted to ask you, James, part of that kind of decoupling teams, I wanted to give you just a couple minutes, even describe what you've been thinking around a venture of an architecture and flow. And so how does that even feed into this model of thinking of IT differently, thinking of how teams work? Sharing data, you know, in a more real-time fashion instead of the batch processing. So could you give us a couple minute explanation of what you see as maybe this resurgence event of an architecture and how does it maybe coincide with even some of the org things you just laid out? Yeah, I think, so what, what drives this is a combination of what serverless is demonstrating in my opinion as being, um, you know, a very quick composable model. I will reserve my opinion on manageable until, um, it's scaled out a little bit in use. Um, but it, it, you know, but technologies are being worked on in terms of management and I think that's a solvable problem. But, um, but basically the idea is that the definition of an application, um, has been changing significantly from over the last 20 years. If you look at what an application was in the dot-com era and what people would point to that, you know, there's a, a fairly sophisticated, large team effort to bring all the pieces together that would be deployed as a unit, um, to maintain a website, say for a commercial website. Um, and that was a, you know, that was a pretty big, um, and, and they were all on the same schedule and all on the same, uh, you know, with the same marching orders, et cetera.

Um, the, the difference now is we've really seen that breakdown, even with microservices and the philosophy behind microservices, we're seeing the breakdown of not only the structure of the application, but also the organization that supports that application. So in some cases, microservices are sort of, there's many microservices that are part of a development team that maintains a single backlog across those. In other situations, there might be, uh, you know, a small number of developers that maintain a given service, um, with its own backlog per service. Um, but you're beginning to see that breakdown also applies to the front end pieces where, you know, there may be a, an overarching application front end that owns the main URL the customers go to, but the pieces that build the page are being delivered by different teams on different schedules. And the, so that's part a is sort of that breakdown into kind of more and more granular pieces. And the second piece of that then is that, that the event driven nature of what's happened with AWS Lambda, especially initially has kind of demonstrated this idea that, that services can push information out about activity, about, um, changes in data. Um, about, you know, anything that, that is relevant to other systems that would want to know about a change in context. Um, they can post an event that says, Hey, X just happened, you know, an API call just came in is the, is kind of the obvious one. But if you look at the events that are available on AWS services that, you know, if, if a, if a, you know, server goes down and needs to be replaced, uh, in a failover scenario, you can have an event that's, that's raised that triggers a Lambda to deal with what you're going to do on all that. That event driven nature to me kind of opened an idea of like, there's, we have APIs that allow for me to, uh, and as, as a consumer of data, initiate a contact and request data and maybe get that synchronously or asynchronously. But what I really like is to be able to sort of say, Hey, I want to know if X ever happens

and, uh, and I want to be able to try and receive that. So standard event driven architecture stuff at that point, right? Um, everything becomes potentially an event, um, and, and you're reacting to what happens in the system and environment. And by the way, just as an aside, Forte, um, when I worked back on that 4GL way back in the late nineties had, it's the core of what it was, was in fact, an event loop and everything that happened in the UI and everything that happened generally at the data layer, um, that would be a push model thing that you would be an initiator of activity, uh, could be done as an event and most often was like everything in the UI was an event for sure. And often we did things at the data layer as events as well. So, um, so this is a pattern that has some things. And what got me thinking about flow was, okay, there's this huge flow of events happening within an organization across all of these smaller and smaller building pieces. And I'm going to explain why that's a good thing in a second, but what happens when those events now cross organizational boundaries, like go from one company to another, or go from a government agency to, um, to a regulated business or go, you know, there's a number of different scenarios you can draw there. Um, what if there's a standard mechanism by which people can say, Hey, I'm searching for event types of events I can subscribe to. I'm subscribing to an event. Maybe I'm paying a fee and subscribing in the sense of, of, uh, of, you know, uh, of a monthly subscription fee or something like that. Maybe it's free data. Um, but I, I, I'd like to be, I'd like to receive that signal. Um, and then, uh, uh, you know, and what would happen then if there becomes a marketplace of events that are out there that would drive the connection of businesses and individuals in unique new ways. And we've seen early versions of this was if, if this, then that, um, and, and a number of other technologies, which are still fairly, you need to have some technical acumen to use well, but, um, and in this case, it would be more at a business layer and more driven, uh,

in terms of business events that take place and the ability to do this at scale, um, and, and do this, uh, uh, with, uh, um, you know, in a way that it's business critical and mission critical. Um, the, um, the, the reason I think all of this is very likely to happen is, is kind of twofold. So one is, um, I'm a big believer that, uh, composability will win out over contextual development. And the difference there is simply if, uh, a contextual system is something that, where you might have a lot of plugins that go in, but the, but that application, that system defines the process and defines the context in which every executes. Um, and so, you know, a number of things built over the years, SAP would be a good example. Um, you know, we're, we're really, it's built so that, um, you know, you could affect the actions taken within the course of a process generally. Um, but the process is predefined and those systems do great while that process is still critical. But if you have a situation where say 5% of what you want, you want to do is impossible to do because of the process, then that system becomes useless in those scenarios. And that's generally what over time kind of kills those systems that can, the composable aspect of things is like the Linux command line and all the text processing tools that are available in the Linux command line, right? So you can pipe these prebuilt things that do work and then define the work, but you can pipe them into any process that you want to pipe them into. Um, and that gives you the ability to compose any number of a myriad of millions of different ways that you would want to be able to process text or, you know, execute other Linux command lines to take action within the operating system or whatever it may be. Um, and that incredibly variety has led to people being able to build an amazing, you know, rich ecosystem of scripts on top of Linux that, you know, really are a big part of why Linux has incredible value, um, to, to most organizations.

So that, that, so that composability piece is a big, big piece of it. And then secondly, um, I believe very strongly that software business software is being built and exists to automate our economy over time, right? So we're automating more and more and more of the economic activity that takes place within industry. And if that's indeed the case, then the ability for one software system to trigger a transaction in another software system or to react to a transaction that happens in another software system that becomes really critical because that's how people interact and do, um, uh, do economic activity today. So you need to, you know, you need to see that there's something available for you to consume. You need to be able to, uh, initiate a transaction to find out more about, uh, comparative elements that you might want to consume. You need to be able to initiate an activity to actually purchase and consume. You need to be able to initiate an activity to schedule an appointment, et cetera, et cetera, et cetera, right? There's, um, there's a lot of things where, where things are kind of driven one way. And some of those work well with APIs, but others to me are things that need to be proactively driven from a software system, not from a human being. Um, and so I believe those things are going to eventually make this idea of event flow across organizational boundaries, um, grow. And one last thing I want to say very quickly about it is it's not just events. Cause every time I talk about this, the IOT folks that I know say, um, events are really large grain thing. In many use cases, you actually want to be able to process the raw data stream cause you can get to patterns and pattern discovery faster that way. And so it's actually a combination today. I look at flows, a combination of events, which are discrete activities that have occurred and, uh, real-time data flows is just raw data being fed from some source. That's a lot to think about, but that, you know, it, it, it makes me think, I mean, at, at a, uh, as you were starting with at a low level, there's sort of the, um, there's basically

the, the, the waiting around to see an event happen in, in a, uh, a GUI app, which if you sort of, uh, as, as you were kind of doing, extend that to the enterprise as a whole, there's, uh, there's a lot of nice, nice stuff about that model. And you got to remove the GUI part cause that's kind of GUI as it were, but, uh, it's, it's a, it's a more decoupled like way of having your architecture set up so that hopefully, uh, you can more rapidly add new features and therefore different ways that you're operating. But yeah, the, uh, the event loop, that's good stuff. That's a, it's critical. And I think what's interesting is, you know, a lot of what, if you really kind of dig back into what software has been applied where in business, a lot of it is to eliminate clerks in the system and clerks to me are people who take a ticket off the top. Of the queue or a job off the top of the list, do that activity, whatever it is that needs to be done and pass it on to the next thing down the line in the process. Right. Yeah. Yeah. Like the workflow of dealing with a, with an event basically. Right. So, you know, and, and we see even, you know, even bank tellers, the demand for bank tellers dropping because there's more and more, uh, we're doing more and more things through software to bypass the need for, for a person that that's a customer facing clerk. Right. Um, and so that's, that's part of the evidence that I present to sort of say, you know, I, I believe what, you know, I believe what's happening here is that we will see more direct interchange between enterprises, between, uh, you know, cell phones and enterprises between whatever. And that will be, uh, driven, uh, more by an event model over time. And as that becomes open and easily consumable and everything, it becomes more and more like what HTTP did for information linking. Um, it becomes a way of doing activity linking, uh, across any number of different boundaries. Hmm. Yeah. It's like the, uh, like speaking of clerks, it's like, uh, it's like that old black and white picture of, of a bunch of people going off into the horizon of a, of a building sitting

at a desk and, you know, the joke being like, oh, look, this is a spreadsheet of, of all these people, uh, well, uh, thanks for being on. This is a great overview of things. And also, uh, I've got some homework to figure out product names, uh, correctly and, uh, look that up. I'll get, like I said, I'll get some flashcards. We'll maybe I'll get quiz next time. Although I was always a solid, uh, B student. So I think the results will be predictable. Uh, well, if you want to, uh, follow up with you or, or, uh, just kind of see what else you're up to, you had a, you had a Twitter account somewhere, I guess it would be on Twitter. Really simple. It's my full name, James Urkert, uh, at James Urkert on Twitter. I'm, I'm most active there. Um, and, uh, also, uh, just Jay Urkert at pivotal.io. If you'd like to reach me by email and, uh, happy to talk to whoever and, and, uh, debate, um, whatever, but I appreciate you guys letting me, uh, ramble on about flow a little bit, but, uh, uh, it's been really fun to be on this podcast. I appreciate it. Well, it is nice to be on. Well, uh, as a reminder, if you haven't checked out the SpringOne tours, you should go check that out, especially the London one coming up. Uh, it'll be enjoyable. And, uh, with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.