Dealing with Legacy, Cloud Native & Otherwise (Ep. 22)

Episode 9 · 2016-06-10 · 1:02:09 · SRT · archive.org · all Tanzu Talk

Well, we're here for our second new format of the Pivotal podcast. Now, my first question for you. So are you a Markdown user? What do you do with the Markdown? Anything? I am a Markdown user. Yeah, I've used a couple of different things. I've gotten a little more used to the syntax. It's a nice way to format things. And what's your take on that? Like what's, you know, it's sort of like, I assume you know HTML too, right? So why don't you just write in HTML? What's going on there? I know at some point it's really, is it supposed to be machine readable or human? Can we pick a side? It seems like we keep navigating between things that people should glance over or things that, you know, web pages and processors can do. But, you know, yeah, you're right. At some point I know how to do a bold tag quicker in HTML than I have to look up the tag to do with Markdown. Yeah. You know, I think, I think what makes the Markdown seem a little weird is when you put links in there and there's the alternative format of like footnoting that, uh, I don't know. I don't really ever do that because then you got to keep track of the footnotes. I don't know, but it is, uh, yeah, yeah. I, I, I always wish I, I use Evernote for a lot of stuff and I always wish that had sort of like a, uh, not sort of like had exactly a Markdown thing. Cause then it would be the perfect note taking thing. Cause I just, I just don't trust the, it's not that I don't trust the WYSIWYG stuff. It's just, it's just not very portable. It's just weird. I don't know why it's inexplicable. I don't trust it. Yeah. I still haven't figured out my, uh, my workflow. I ended up writing it in the Google doc and then trying to save it and end up doing it all over again. And whatever CMS I'm posting and that's good, very inefficient. Well, it, I, I think, I think thankfully we operate in the infrastructure layer. So all these sort of like malaises of the application layer, not our problem. That's someone else's issue that they need to sort through. That's a, that hopefully someone will start working on that. So, so what, uh, what have you noticed going on this week? What, what's, what's caught your interest? Yeah, there's been a few things going on. It was interesting. Anytime you have, you know, breathless reporting of password breaches and go reset all your

passwords everywhere, but there was that LinkedIn one and it was a, I think it was a data breach from 2012. So technically old, excuse me, old data, but you know, I think I saw Zuckerberg got, you know, his Twitter hacked, which he hasn't tweeted in four years, but he had reused the password between accounts and, but the LinkedIn stuff popped up and it's, I think the good reminder again, that it doesn't matter how hard you say it, people don't really rotate passwords very often. And I'll be darned if they don't love using the same password on site after site. So at some point you just have to assume that people will do those things and you put better things in place, whether that's two, you know, two factor security or something that says people will just behave this way. We have to figure out other ways to secure our systems. Yeah. I mean, I think, uh, you know, I, I try to use one of those, uh, random password generator things as much as possible, which, which works out well. And then you got the two factor authentication. That's nice. And I suppose having, uh, rotating passwords being like new passwords that you use, you just regularly refresh them. Right. Yep. Yeah. And if, you know, Hey, technically say you should change your password on your major accounts every six months. I don't know who does that. And you can argue that makes you less secure because now you're maybe doing things that are memorable. That's at least what most enterprise customers do, or at least I did when I was an enterprise user. And you would just keep incrementing the number at the end. Cause it was annoying to keep changing your password every three months, but that's right. You know, these things are meant to help people out, but I think we're, uh, we're probably actually hurting security with some of these password policies. Yeah. There was a, there was a good talk from, uh, at the Cloud Foundry summit a couple of weeks ago from, uh, from Justin about, about, uh, security as a feature, I think is how he opened it. There's all sorts of great metaphors for things, but you know, it wasn't really, I wouldn't say it was technical at all, but it had a lot of good practices that we should, we as, as people who create, uh, infrastructure in the software should start putting into our software just to, uh, have security as a, as a default feature. And I think that idea of rotating passwords and also, uh, taking advantage of the transient

nature of applications so that you can, uh, uninstall and reinstall it, kind of blowing away any, any sort of malware that might be there. There's, there's a lot to be said for, uh, it's, it's almost like a side effect of a cloud native approach to applications adds in the possibilities of it being secure in better ways than the way both software is. Yeah. So, I mean, I liked it. We're hopefully going to keep moving towards different ideas versus just continuing to beat people over the head about 15 character passwords with no hieroglyphics and, you know, whatever other characters in there that are hard to guess. We have to do passwords better. So these breaches sometimes I think help force that issue a little bit. And, uh, you know, I've noticed in the consumer space, the, the last thing that I think needs to be added is, is like multi-users per an account, right? It's the old, uh, it's the old, uh, whether you want to say spouse or partner or whatever lingo you want to use, it's the old, uh, spouse needs to pay my bills use case. And, uh, you know, I, you know, I feel like there are, there are some sites that have what they call like an authorized user or something like that, but it's very rare that, that you can actually set up multiple accounts, uh, and, and like family accounts, you know, like Spotify and consumer sites are pretty good at that. Cause there's a business model for it and Netflix, but man, that's like the last thing I need to solve for it because it's, and then it's also like, it raises this, uh, I don't know if it's embarrassing, but it's sort of like nerd embarrassing where, uh, where, you know, uh, you know, my wife will ask me for a password and I send her this gobbledygook and it's just sort of like, yeah, I'm sorry about that. That's I'm trying to do the right thing. And then of course I'm just telling her passwords. I mean, I get a sick pleasure when my, my wife forgets the wifi password and I have to read out the 15 digit code cause it gets funny by character 13, but. It's, uh, that's probably not helping. Yeah. Yeah. And then meanwhile, also in the fun space, it looks like, uh, I, you know, I, I try, I've tried to use Snapchat a little bit, but I just don't, I don't understand what's going

on with that. I'm obviously, and then I'm in the, the minority of people. Like I keep getting told that Twitter is not like the normal social, normal social network, but it's sure where I spend a lot of my time. It's, it's becoming like some sort of, uh, I don't know, some sort of niche or something, but have you ever figured out that Snapchat stuff? No, I mean, I obviously there's the early reputation of, of sending various pictures to people that you, you want to have destroyed immediately, but it's, you know, it's taken on its own life. Again, that was the news last week. It's arguably, it looks like it's 150 million unique users per month, or I think that's the per month. And Twitter's at one 40. So Snapchat's technically passed it. And again, kind of comes to this question of, I don't know, what are we supposed to be using? I think we all agree. Google plus is dead. So like, where do we kind of interact with people? Is it, you know, is stack overflow? Has that won the game for kind of developer Q and a, and then you've got, you know, blogs are still getting written. And it's, I don't know about you, but it seems like we had this pivot a few years ago where it was tons of corporate blogs after all the individual blogs in the two thousands. And then somehow kind of lost the individual voice and it became all these corporate things. And now it seems like we've come back thanks to medium and other things that there's a place for long form thoughts. But at the same time, I love Twitter. I pick up all sorts of interesting things. I've met interesting people. It keeps me with a pulse on what's going on without having to fully commit to it. But what about you? What's your universe for, for keeping up with stuff or sharing your contain musings? Well, I, I, uh, I use Twitter as a, as a broadcasting mechanism and I have to admit, I don't really like follow that much stuff in there. I, uh, I recently like fixed my following thing. I used to follow like, I don't know, 1500, 2000 people. And I finally found a service that unfollowed everything. And, uh, and what I'd been doing is I actually had this hidden list of the people I actually followed or the accounts I should say. And I would just ignore my normal timeline, which was, which is annoying. Uh, I mean, it's actually fine if you use like tweet deck and tweet bot, you can follow

a list instead of your timeline, but you know, it just seemed like, uh, uh, uh, a legacy hack, if you will, so to speak. So anyways, I unfollowed everyone. And then every now and then, like, uh, uh, recently I, uh, I discovered I wasn't following Abby Kearns who, uh, you know, works here and is, is, is doing a fellowship at the, at the foundation, the Cloud Foundry foundation. And so I finally followed her again and she was like, Oh, thanks for finally following her. So I get those little embarrassing situations, but, uh, yeah, I mean, I only follow like 150, 160 people, uh, or so. And it's mostly like, uh, truly like a social thing just to see what people are up to. And then also a broadcast mechanism. Uh, right. And I mean, I've noticed that like, uh, it's replaced like what blogs used to be when for in the tech world, at least for me from, uh, back, back in the two thousands, right? Like that used to be the center of conversation and activity and comments, but now it's all the sort of like center of attention for the world that I pay attention to is in Twitter. And then to answer your question more fully, I still have a bunch of RSS feeds that I use in a combination of, uh, feedly and, and, uh, newsify on my app. And that's the main way that's my main source of input. Like, cause I find sometimes I find stuff on Twitter that's interesting, but it's usually like, it's usually like the tech world equivalent of what I see when I go into Facebook, which is just like a bunch of like, um, not useful, but highly entertaining things. Right. It's the supermarket checkout. Yeah. Yeah. Yeah. That's, that's a good way of putting it. It's, it's like the supermarket checkout row at Fry's, you know, they have that big long line with all the, the, the, the aisle of temptation as you're waiting for that person in a short sleeve shirt to tell you which line to go to. I haven't been to Fry's in a long time, but it's like, it's like sort of like that, you know, cause it's got a bunch of nerd stuff in it, at least for, for I have it. And, you know, also, uh, I haven't done a survey like this in a long time, informal or

formal, but I used to sort of pull people, developers and other people about where they went for their news sources. And Twitter was always one of the highest ranked ones next to just like GitHub and things like that. So I don't know. I sort of assume Twitter is where you go for tech world stuff and, uh, it seems to work out. If you, if you look at the analytics that we have on our corporate site and, uh, my own site and things like that, we get a lot of terrific traffic from Twitter. Yeah. No, I've noticed it changes how I think about the real time web. If, if I can't access an application or a site, or I think something's good. I don't go to Google. I don't, I search on Twitter and find out who's talking about, you know, this service being down or whatever. It's, it's just fundamentally changed how I get a, what is going on right now? Question versus I hope somebody blogs about this tomorrow so I can figure out what's going on. Yeah. Yeah. That's true. Yeah. You know, with something I need to figure out one day is, is if I should have some sort of like professional Facebook presence. Cause I did a similar thing in Facebook a couple of years ago where, uh, where I just because I didn't want to do it and she volunteered, my wife went through and unfollowed everyone. She thought I, I wouldn't care about in Facebook. So that it's a total, like, like total personal life, uh, situation instead of, uh, and I, and I don't put tech stuff in there at all, but I don't know. Right. Maybe I should, who knows? It's, it's, it seems like a lot of hassle for, for very small gain. It does. Although we all want the Coté fan page. So I think that's where we, where we need to land. So I guess speaking, speaking of finding out outages, we also had, uh, some stuff last week down under as our friends at Amazon had some issues with data center. And we're out for, I think formally like 70, 80 minutes. There were some other services that, that stayed down longer, but you know, as usual, what follows that some of the gnashing of teeth of, you know, public cloud and stability and availability. And what also follows is you have to be careful because I can come across as, as condescending, but some of the counterpoints of freaking plan for multiple zones, like don't be dumb. You get the availability you pay for. And so there's always something in between.

I think to some extent, people still see the cloud as the, here's this magical resilient place that can handle, you know, swarms of bees or power outages or whatever, versus the other school that says, I don't trust anything. And I'm going to be in nine availability zones in 12 regions because everything breaks. It feels like there's something in between there. But every time this pops up, you seem to have both of these sides come out of the woodwork. You hear anything about this? No, actually, I don't really follow outage stuff. So they did, did they figure out like what caused it? No, I mean, it's Australia. So it could clearly be dingoes or something that that's happening in only Australia. But I think it was, there was a storm going on. Yeah. Dingo ate their baby. So I think it was a storm going on. And actually some of that flooding and other stuff cause problems because data centers are real things and the cloud is still, you know, a set of physical assets being served up. So you're going to be a subject to those things happening. Yeah. You know, this, this brings up a broader topic that, that I don't know, I feel, I feel like I've seen some, some reinvigoration in there. Maybe it, maybe it's because there's an analyst publishing cadence. What do we have that's going on at the moment, but there there's, there's a little further thawing of the idea that like public clouds, probably okay. And, and with, with, with qualifications, like, uh, you know, if you need constant uptime, that's really expensive, but you probably don't need that. So just move along. And I remember I've, I've been putting together some, uh, some slides for some, uh, uh, a presentation to some government people and I was looking at some predictions and there was, there was a pretty good prediction that like, uh, well, I forget what the year was, but that more and more government people will be looking to public cloud to be a good mixture of cost and security in that, uh, in that a couple of years ago, this point was kind of counterintuitive, but it's one of the, uh, the turns out sort of points that gets made a lot is that public cloud companies probably can be more secure than many organizations

in that they have, uh, economies of scale when it comes to security and expertise and things like that. And so it does seem like increasingly maybe, uh, uh, a cost advantage, a good, a good, a good cheaper way of making sure something's secure just to run it somewhere else, which, you know, I'm sure infrastructure outsourcers have always made that promise, but there's, there's probably a little more provability when things are centralized instead of spread out to like one off, off, off sourcers and MSPs as, as there have been historically. Yeah. Especially with this, this prioritization on some of the certifications you go to Amazon or Microsoft or others and their compliance page is just a sea of logos because they've passed every weird certification compliance thing about how do they manage credentials and rights and access and destruction and, and then these things that matter. So unlike maybe 10, 15 years ago where you outsource because now it was just someone else's problem. Now you can do it and say, all right, not only do I have some configurability of these places, but I know underneath the covers, this is not held together with duct tape and wire and stuff like that. So, so when you were at, uh, at century link being a service provider, as it were like, like what, what kind of conversation did you have around outage? Like, were you, were you like, you only need so many nines or like, like what did your nines conversation go like with, with the people you talked with? Yeah. I mean, I treat arguably every SLA is nothing more than a promise. It doesn't guarantee anything, you know, an SLA is a promise. And it says, we are doing things architecturally business-wide business-wise to give you a certain level of availability. We've got redundancy, we have, you know, Hey, multiple network pads into a data center. We've got all these sorts of things makes tons of sense, but at the end of the day, things can still go wrong and you still may be down and break quote unquote, break that SLA. So I think it was, you know, we spent a lot of time explaining what is an SLA. It demonstrates a certain level of commitment, but that does not absolve you, the customer of responsibility. Instead, it says, look, these are the things you can count on from us, but heck, these are

infrastructure SLAs in most cases. And almost, you know, everybody gives you availability in some cases, you know, how many nines of availability, but not performance or not resilience across sites in some cases. So when you start thinking of the app tier and above your cloud provider, unless you're using a PaaS or these sort of platforms that sit above infrastructure, you, you, you can't give up the responsibility to say, how am I resilient across sites? How am I making sure that performance and latency isn't terrible if X breaks? And I think we're seeing some, some good discussions at conferences and some good practitioners that talk about building resilient distributed services. And I spent a lot of time trying to do that at CenturyLink because customers can sometimes assume that again, they've outsourced all the responsibility when in fact they have not. Yeah. I think, I think that's, that's a good point that, uh, I don't know if it's become a widespread best practice, but it's, it's, uh, it's, it's, it's one of my, as I always like to analogize it, one of my flossing things, like everyone knows that you should floss, but you know, no one, very few people do. And similarly, it's accepted wisdom. That's, that's more or less proven that at the application layer, you should write your applications to be resilient. And that will mean different things for different applications and infrastructure. But, but the flip side of that is like, you know, getting an SLA or a promise for availability for just raw infrastructure is, is good. It's, it's, it's sort of like, what's the phrase necessary, it's, it's necessary, but it's not sufficient to solve all your problems. Like you're going to need, and, and then, you know, it's sort of like cherry picking anecdotes and data and stuff like that. But it does seem to come up that, that, uh, system failures happen, probably happen at the application layer. I shouldn't say system, but failures often happen in the application layer more than at the infrastructure layer, especially in a cloud environment. We were trying to normalize and, uh, have as few options down at the infrastructure layer as possible. So it's, uh, you need some resilience above that. Hence the opening comment you had is like, well, you should run in more than one zone. Right.

Well, I mean, what's interesting, and there's a good book on, on ops I read, uh, last year that, you know, as you think about infrastructure at scale, when you're at Google scale or others, they have hard drives probably failing every 10 minutes because you're there's so, so many, even if those things have a meantime between failure of once every 10 years, you've got a million of them. So they're all going to eventually, and you're going to constantly have infrastructure failing. So you rely on your cloud provider to, as you say, kind of normalize that, cover that up because they build the appropriate fabrics that, you know, Hey, fail over cleanly when a hypervisor goes down or storage drive or a network device. So again, you need to know your providers doing those sorts of things, but at the same time, I think we're seeing good application architecture practices that say, you know what? Meantime between failure is no longer what matters. It's meantime to recovery. And that's about building resilient apps, not assuming things will just work forever if I buy the best hardware possible. So we were, we were talking before we were recording that you had actually read this roundup of, as I like to think of it, dis-economies of scale, a good write-up, a collection of papers going over how essentially the, the larger your team size when it comes to software. And I guess going back to Aristotle, non-software, but as, as the, the, the blog post is actually titled, but you know, it, it, it seemed like a good roundup of, of something that we kind of all intuitively know that like, as you grow the size of the team for solving a problem, uh, things don't go so well. It's better to have a small team, but since, since you actually read, and I hope understood the piece, like what, how, how would you summarize all of that? Yeah. I mean, like you said, you know, I think many of us who've been in any sort of IT landscape for a while are familiar with the, Hey, the projects behind, let's add some more people. And that almost never goes well because it's a whole, you know, nine women aren't going to give birth in a month sort of thing. It doesn't help. So in some cases, sure, when you're remarkably short staffed and people are, you know, not doing well, adding additional people, but there's a common understanding, as you say,

that, you know, five to 15 people is the right team size for almost anything. It doesn't matter what you're doing, that that's a good team size. And that once you get beyond that, you hit the communication problem and the friction of, you know what, now we got to synchronize. Now we got to do some status. Now we have to start, you know, it becomes this, this burden to keep the team in sync. So some of the premise of the paper was as well, does open source buck that trend? Because look at these open source things being Cloud Foundry has hundreds of committers. Linux does open stack. So aren't these disproving it? Because I'm increasing velocity with something like Cloud Foundry, even though we've got hundreds of committers. So maybe there's open source disprove this conventional wisdom. And a lot of the research went through in the paper that looked at frequency of commits and a number of other things that still said, look, there's a lot of core people who are involved in these things. Open source really isn't that much different. Smaller teams are more productive than larger ones. And you can look at that by the extent of the commit. You know, you could have a lot of committers, but if they're changing a line, that's different than people rewriting stuff. So I was trying to look at who are the people involved and can you still prove that this matters? And by the end of it, again, still proving that the end of the day, smaller teams are going to be more effective, more productive because they don't pay this tax of synchronization and communication problems. And again, I think we all see that in every aspect of our technology jobs, whether you're an enterprise IT or a software vendor or a service provider, smaller teams of talented people, right? They'll just grab the four people you find on the street corner and say, run my service at scale. But give me, you know, a handful of talented people that I'm not going to overburden by giving them this assignment. And then, you know, if it starts needing to get too big, then it gets bigger and maybe you split it off again. And I've worked in multiple cases where that's the case where once you hit a critical mass, you know what, maybe the scope's gotten too big. Now it's time to actually split the scope. And it's taking a very active role versus just kind of kingdom building, saying I want a, you know, 200 person PMO versus, you know what, maybe I don't need that.

Yeah, it's, you know, going back to the realm of intuition and anecdote. I feel like when I and other people go out and talk to organizations about how they need to change to be more cloud native and things like that. Not all of, but a large amount of what we're saying is you need to change the way your organization is structured because currently it's almost like your organization structure is the product that you're working on. Like you're, you're, you're spending a lot of time, uh, like moving information around, having meetings to synchronize things like reviewing people, like taking care of the organization versus focusing on the product. And I think, I think a lot of companies or a lot of organizations get that way when they've, they've confused like, uh, mission criticality with being validated by a large amount of people working on something. And, and there's almost this, uh, it's hard to disabuse if that's the right word, people of the notion that you need a lot of people to be successful on software projects. Like, you know, I don't know, I don't know the construction industry too well, but I wonder if there's similar things for like building highways and things like that. Like how, how many people are actually useful for doing like physical work, like building a house or something like that. And, and it seems like, you know, there was a bunch of like fancy scatter plots and things like that, but it almost seems like there's a, there's should be a way of measuring complexity of software, which is always a terrible canard of a thing to do. Like, remember people used to have like story points and not even, I mean, if you have story points, what were the units they used? Code points. I remember looking that up from the old crusty books a long time ago, but if, you know, a way of sort of plotting complexity of software and like number of people where, where the advantage of having that number of people drops off. And we have all sorts of, uh, anecdotes that fill that in, but this, this, uh, this roundup seemed to be a pretty good analytical look at like the, the, the core size of people you

want is always a lot smaller than you would anticipate it to be. Yeah. I mean, sometimes you can just mistake output for outcomes and that sometimes just right cranking through stuff. That's not actually an indicator you're making progress. Yeah. It's, you know, it's important to make sure you're focused on value. I got a master's degree in engineering and some of the focus was on lean and agile and, you know, professor going through stats at 95% of most processes are waste because it's just, you know what, you're dealing with duplication, you're dealing with communication, you're dealing with all these things. And very little of that would your customer actually pay for if they came in and said, what am I going to go paying for when I buy your product? Probably not the three hour status meeting. Yeah. And, and, and those, those hit on like, uh, uh, a, a very brief, but, uh, rich little writeup that I found recently. I'm, I'm always like on the lookout for, uh, I don't know, or organizations writing up. Here's, here's things we found out about doing software. And it's very rare that you find them in of all places. I think this new source is from like Singapore, this Govan cider place, which is really weird. Uh, but, uh, it's, it's, I guess it was, it was listed in tech me and that's how I found it. And it was just this quick interview with someone who used to run the, uh, the UK is like digital services branch. And there's, there's a tremendous, there's like three or four good little points in there. And one of them is exactly what we're talking about is like, whenever you're writing software to wrap around a government provided service, like registering for a restaurant or like finding how much taxes you owe or things like that, you probably only need like eight or 10, 12 people on the team, like, which for having, having talked with a lot of government agency people is an astonishingly small team for a lot of government and contracting work. And, and, you know, so, so that, that kind of anecdote was pretty good in there. And then there were a couple of good examples. One of the main emphasis I really liked in this piece was being very, uh, they say citizen, but, you know, user centric and thinking about like, as a user, what is it you want to do? What are you trying to accomplish? Um, and it gets to the point of like, instead, when you have a large organization, like government

organizations and large enterprises are there, their software tends to match the silos that they have, and they didn't really like eludicate this example very much, but there was a good example of like, if you're, if you're registering to be a, uh, to have a license to open a restaurant, there's multiple agencies you have to go to, to get all the licensing. Whereas like, uh, you're just opening one restaurant and you really don't care if there's multiple agencies. So you'd like to just fill out one application that, that would go to all of them. And, and I remember, I remember going to, uh, hearing some customers in the, um, mortgage application business many years ago, like making a similar point where like when you fill out a mortgage application, there's all of these parties and stakeholders you need to fill things out for. So there's a tremendous amount of streamlining that can be done to make it faster. And this was back in the heyday of just like, you know, signing up dogs and cats and everyone else for mortgages. So making it, making it a rapid streamlined process was very, it was of interest to people, but, uh, you know, and, and, and then finally, the last thing that I thought was kind of interesting was, uh, a, a position on a native web apps versus mobile apps. And it was, it was almost saying that for governments who are always very cost conscious, it's probably a good idea to look at doing mobile applications because one, they'll work on a wider variety of, of devices for the one thing that you use, which is probably as always kind of sort of true, right? There's always compatibility stuff you'll need to do, but maintain, maintaining the applications is where a lot of your cost savings will come from. And, and, and there's a quote from the, the person who was interviewed kind of alluding to this, where he was saying he was looking at, uh, I guess, I think it was Singapore again, how they had like 300 native mobile apps. And he was, he was remarking that like maintaining those over the course of many years with all the updates that come up and having to update the toolkits is going to be a, uh, a large job versus mobile apps, which again is one of those kind of sort of things probably, but it was, uh, it was, it was interesting sort of take on that because normally in a, um, in

a, in a profit driven world, I think the default would be more to look at native apps because you have the money to, uh, to sort of put into that, you know, you're more focused on maximizing profit than really maximizing costs. I don't know how to phrase that, but, but minimizing the costs you have. Whereas I think there was another point he made in there that was, and he, I'm putting words, I'm rephrasing this in my own way, but he made this point of like, yeah, we used to have a bunch of like nice images and pictures on some of these pages. And then like, we realized that those don't really help. So we just stripped that out and they're pretty basic looking pages, which I think is again, probably a okay for government stuff, but you might want a little more pizzazz for differentiation when you're in the consumer space, because not, there's a very small percentage of the people who can choose which government they're going to go with. Right. They're kind of stuck with the government they have. So while design, uh, as far as productivity is important design, as far as like pizzazz is maybe not like, uh, really high on the list of things that you need. Yeah. Like that makes sense. User experience. Yeah. Always matters, but that takes different flavors based on your audience. So now that's interesting stuff probably leads into our main topic for the day. And as we think about, you know, how do you look at your portfolio and figure out what you're doing? Yeah. I mean, that's, that's something you and I have been, uh, uh, working on some, some small pieces and things here and there. And definitely something that comes up all the time is, uh, what do I do with all of this legacy stuff that I have? And, uh, yeah, I mean, it's certainly something I've, I've spent a lot of time writing about, uh, I don't know, at a high level and talking with people with, but it, but it is, uh, yeah, it's a difficult issue. There's not really, as, as I often like saying, there's not really great answers. No, there seems to be bad ones, but there don't, you know, it might not even be right ones, but there's wrong ones as we think about this. And as we're framing this, you know, for people, it's this idea of what do I do with and legacy, we can even argue if that's the right word.

There was a tweet storm earlier in the week from people saying, you know, it's legacy even the right word or is legacy typically has a positive connotation. Like, Hey, you know, it's a legacy for my family, but we're using the same word to paint the, you know, the dumpster fire of it that is sitting in our data center. Is that different? Is that just old stuff or is it production apps for the positive things? They're actually generating me money. Nonetheless, we're meaning what do I do with the stuff I have? And then I'm looking at new technologies, platforms, containers, whatever. Is there a migration story? Is it a rebuild it? How am I supposed to approach that stuff is what you and I went to chat about here. Yeah. And to that point, like there's, there's, there's a two main ways that I try to define what legacy is. And, and, and, you know, the first one is, and you kind of characterized it are basically like existing, I'll just call them systems, but existing software that I have that like people, our organization is using to run things. And for some reason, we're afraid to touch it, right? Like, like, like if you don't really have a fear of modifying and messing around with, with that, the software, you usually don't think of it as legacy. Like legacy, you usually only call something legacy because there's some problem when it comes with dealing with it. Like whatever, whatever application, your applications, you're looking forward. Well, I don't know if you're looking forward to it, but whatever applications you don't mind messing around with, you usually never call that legacy. They're, they're fine. And so it's almost like that's the first filter is it has to be some existing system that's you fear changing it. But for some reason you do, you probably need to change it. Like, I guess there's another category of existing systems. You never really need to change that you've kind of forgotten about. You could call those like ROI maximizers, right? Yeah. I mean, there's no reason you could never justify the cost of switching it or it doesn't make a difference because it just doesn't do money. It does what it does.

Yeah. They don't go swap it out. Yeah. And, and, and then, and then often as, as, as I joke at this point, those are applications that make you a lot of money, right? Like, or, or somehow fulfill a lot of whatever mission you have. And that's, that's part of what makes you afraid of messing with them is you're afraid of like, uh, the risk benefit analysis of, I might screw this up often doesn't, uh, fit well with whatever, whatever money or whatever process you're benefiting from, from it. And then the second one, like from a more technical level, I just steal from that old, uh, that old Michael Feathers book, which is, which is, uh, a developer centric way of explaining what, what, what we were just talking about, which is legacy code is code that doesn't have good test coverage or, or it doesn't have ample test coverage, which makes you fearful of changing it. Right. Like if, if you had good test coverage on your code, then you wouldn't be afraid of changing it because if you changed it and something broke, you would catch it in tests. But often, uh, you know, that's, you know, legacy is defined by stuff that's untestable or you don't feel confident in testing. And so there's kind of that definition. I think maybe a third one, especially in our, our line of work is, uh, runs on old platforms or, or runs on a platform other than what you consider your new default corporate platform. And so, and so therefore it's like a one-off thing that you have, uh, running around somewhere. Yeah. I'm sure Microsoft access is still in heavy use in many places from a database. Somebody wrote in 2003, you know what? And it does the job. That's right. And, and speaking of government, like there, there, there's, there's, uh, there's some good Senate testimony from a years ago that the IRS still runs some core processing on Kennedy era, like IBM machines. And then, and then I don't know why this came out, but there was, there was some, uh, some articles recently, maybe it was from some floppy disk, uh, manufacturers that, uh, some sort of like us nuclear and Norwegian medical association stuff still runs on floppy disks because, uh, as, as, as, as people said, because they work.

Right. And arguably are more secure because no one's hacking that stuff. Right. Right. That's, that's what they said about the, uh, the ICBM stuff is like, well, they're also not on the internet. So they're inherently more secure despite all that war game stuff. We, that propaganda we were given way back in the eighties that they, they were reachable by a network. No one's dealing with floppies. I mean, so one reason we're, we're talking about this, cause this stuff seems to pop up every few years in this approach of, of what do you do with those things? As you say, they're on old platforms or don't have good test coverage, or maybe they're working okay, but you know, there's some inflexibility in whatever that existing technology is. It's holding me back from doing new crazy mobile stuff, or it's keeping me from integrating with a partner or whatever. So it seems like we up every few years, or maybe it's all the time. Talk about a migration approach, or do you re-platform, or do you leave it where it is, or do you just do some light refactoring? Am I supposed to lift and shift legacy stuff is maybe the question to ask. So why do you think that's appealing? Why does, why does a CIO look and go lift and shift? That sounds kind of awesome. Hey, I'm using Pivotal Cloud Foundry. I'm using a new Docker container service. Hey, I'm using an Azure cloud environment. Can't I just take my stuff and run it there? Why do you think that's appealing? I think, I think, I think there's, there's a handful of reasons. One of them is, and they're both the same reason. Like, I think one of them is just like the business case. And whenever, whenever you end up buying a new platform or a new IT system or, or whatever, some chunk of enterprise technology, I mean, at the, the, to, to do, to do sort of like a platonic, you know, uppercase T truth, like analysis, the, the ultimate form that any piece of enterprise software has to meet is solves your business process, your business problem in a way that's affordable. Where affordable is defined as you don't lose money.

You may not profit, but you're not going to lose money doing it. Right. It's, it's sort of like a, to, to mix in more ancient Greek people. It's like a Hippocratic oath for enterprise IT. Like do no harm to the CFO. That's like the promise of enterprise software. And so, so when you, when you buy one of these big platforms, you want to like stuff as much stuff as, in it as possible. Cause that's how like a ratios work and division is like your ROI is going to be so much better if you put a whole bunch of stuff on whatever side it is such that a cost and spin come out looking good. And then it starts turning off the old stuff. Yeah. Yeah. Supposedly helps. And, and, and then also, you know, whenever you, whenever you're looking at a new platform, there's often a lot, the productivity gains are often sold as there's more operational, uh, um, productivity and more development productivity. So like one of the things, you know, we, we talk about with Pivotal Cloud Foundry is like, um, like there's all sorts of ratios, but like you can run hundreds or thousands of applications with just like five or 10 ops people to run the platform. You may need, you may need a lot more software developers, right. Who are focusing on the application layer, kind of like we were talking about earlier with SLAs and stuff, right? Like all of your activity goes up to the application layer, but running the default infrastructure, uh, you get a lot of benefits from that. So if you're, if you're considering that those kinds of benefits, you look at your existing infrastructure and you're like, Oh, I don't have those kinds of ratios. I have like, however many, many admins to as however many servers and applications I have. So why don't I just move everything over to this new platform and then I'll get all those benefits. So, so you get that kind of stuff. And so it's, it's really just like, uh, it's kind of like the debate around bimodal IT. It's like, well, if operating this stuff is so awesome, why don't I apply that to everything? So that I'll get, I'll get more awesomeness. And then I think the second thing is like, um, you know, over the past, what is it? What is this? 20, 10 years or 10, 15 years, like, like VMware and virtualization was kind of this.

It was just like, yeah, you just sort of drag your applications over here and it all works out well. And so, so a lot of people have been trained, like the, the current, the current, like high level middle management and even executives, they all came up as it were in an age where you could do that. Essentially, you could just optimize, you'd like do very little changes to the application and just virtualize them and get huge benefits from it. So you kind of like look at IT in that way and you think you can just move legacy over and you start to just expect that. And to a certain extent, I think SAS is kind of like that, right? Like at least when it comes to like email and messaging and some other stuff, whereas like moving from an on-premise enterprise application to an off-premise application, like you can get those similar, uh, one-time pain of like migration movement and then everything's all happy-go-lucky and fun. But I don't know, I mean, I think that's what makes people think that there's a lot into, uh, lift and shift stuff. And then, and then finally, like, I think it is possible with, with sometimes with, with new technologies to get out with new platforms to get all those benefits. Like, like, uh, there, there, there was, there was a story that, um, like someone was saying that like, you could move like 20 or 30% of your existing applications to a Pivotal cloud foundry instance, which I have no idea if those numbers are accurate, but it does sort of make sense. Like, like knowing the internal numbers for some of our larger, uh, accounts, like the applications they move over. There are, there's some, there's some customers who use Pivotal Cloud Foundry and they very rapidly move hundreds of existing applications over to the new platform to get all those, uh, those benefits. Right. Man, that was a good story. I relied on some, some shadowy pivotal figures for quotes and overall pointed out some, some good stuff that, you know, PCF isn't just for new stuff. Now at the same time, I mean, think to your point, I think where I feel bad sometimes for the CIO, because vendors aren't helping this case. In some cases it's, it's, here's our new product. Yeah, sure.

Move everything over here. Versus, is that the right call? And you know, I mean, Pivotal talks a lot about 12 factor apps and we talk about cloud native. Now you can argue cloud ready versus cloud native. Maybe it wasn't built with these sort of stateless, scalable, quick startup philosophies in mind that kind of define cloud native, but you know, it's cloud ready. It's a good looking Java app. It's a smart Ruby app. It has decoupled dependencies. It's something that already goes through a continuous integration chain, pushing that to Cloud Foundry. It's not gonna be a big deal. You'll actually get a lot of advantage, but do I pick up my, you know, four terabyte teradata data warehouse and containerize it? Like, am I going to get any benefits from that at all? Or, you know, this tightly coupled application that has a lot of local state or, you know, it doesn't scale out well because it's going to crush the database, whatever it is. Some cases you just leave it put. And I hopefully, I know Pivotal tries to make sure we give some pretty practical advice there, although we can also get excited about our own platform. But how do you start to frame these things when you'd be talking to a customer about cloud native versus cloud ready versus just leave it the hell alone? You know, how do you frame that so they don't accidentally spend a lot of their precious IT dollars doing something that won't actually return any value to them? Yeah. And that gets to the, you know, I was joking earlier about how there's not really great answers when it comes to dealing with legacy, right? And the answers are like, yeah, it's hard. Like there's, there's, if, if, if it's technically possible to replatform your application and you don't have to spend a lot of time rewriting it and you've got enough test coverage so you can change it, like, you know, it's and, and, and then like everything's dandy. But the reason you're asking this question is because you can't do all those things, right? And so, so you're looking for like a philosopher's stone of alchemical magic to like, like, do you have the magic answer? And this is why I always reference like the virtualization stuff is like, well, at the moment, there's not really a lot of magical answers like there used to be.

So the, the, you know, this, this leads us to the, you know, like you were saying, like identify things that can run on a new platform and be replatformed and do that. And then there's this other stuff, which is like, well, make sure you've actually virtualized everything as much as possible, which despite, despite what we in the vendor world and people who hang out in Twitter, as we were talking about earlier, you may think like not everyone is virtualized as much as possible. So that's still a big project that they can do. And then, and then after that, you also like the other thing, like I've, I've, I've, I've learned after many years, never to assume that, uh, people are following best practices. And so, so I tried to, it's the flossing thing. I tried to emphasize like, oh, you should really do that. And so like the, the thing I've settled on now is like, so, uh, you should be doing portfolio management. I'm sure you do that. Right. Right. Like you, you sit down on at least an annual basis and you kind of sort of look at all the applications you have and you rank them by their importance, however you do that. And you think about like, what's the next two years of this application? How am I going to ensure that it has what it needs? Or should I shut this application down? And then how do I even set up a process such that I do that instead of ignoring doing it? And I think, uh, you know, I, I haven't, I haven't read up on enterprise architecture, um, like best practices in a while. Uh, because, because frankly, as an industry, we don't really talk about it. We spend a lot of time talking about, um, individual applications instead of aggregate. And I don't think, I don't think doing things in a cloud native style has been in practice for like a decade or so such that you could go out and study those things. Correct. But as a substitute, I mean, as always, if you borrow from the vendor world, you can start to get a good template for how to work out on the enterprise side, if you will. And, and I realized that like the, uh, the old, the old three horizon way of thinking as explained, as explained for vendors, for software vendors by Jeffrey Moore in this book, what's it called?

Escape velocity is probably a pretty good way for enterprises to start out, which is, uh, just to, just to like go on about that a little bit. Like the idea is that the reason large software vendors or large technology companies suffer, one of the reasons is because they always sacrifice, um, short-term gains. Uh, they always, sorry, they always sacrifice long-term R and D investment for short-term gains. So they're always worried about the next 12 months. And, and the, I even phrased that wrong. They, it's easy for them to spend stuff on like three years out, right? Like on moonshots and experimental stuff. Cause it's actually really cheap just to do R and D. Like you just get a team of five people and have them go sort stuff out. But what's really expensive is something that's like going to be come to market in the next two or so years. Uh, and, and something that like makes no profit or money right now, but you've just got to like burn a bunch of money to get to market and get the market fit and do everything right. And instead you'll just, as a software vendor, keep selling the same thing over and over again, cause it brings in profit. But then what happens is by the time a new, uh, a new way of doing something comes along because you've been sacrificing your short-term thing, you haven't worked on that next new thing that you can just slot in there really easily. So he has this whole sort of like, it's actually pretty direct for a business book, a whole way of setting up your process. So you pay attention to those middle things, the second horizon. And you don't, uh, you don't find yourself like, uh, lacking for a, uh, a new technology there. And so how do you apply that to the enterprise space? Like, I think, I think if you kind of like read through that book and you kind of as recommendations, you can start applying that to the enterprise area where like, so I've got these three tranches of applications. I've got like my experimental labs or whatever stuff that probably are not ready for production. And that's always really easy. That's just like a two, $5 million budget that I spend if that a year. And that's just like, that's fun stuff. And then I've got my, my present, how I make money right today stuff.

And I, as management had to set up a structure where it's actually okay to start developing businesses and therefore software that's not making any money currently. And I have to really make sure that the way that we manage our portfolio is aware of the fact that at one point, the way we make money nowadays is not going to be effective. It's like, it's like, when you explain it like this, it all seems to make sense. Yep. But the, the, the, the point is the management has to set up structures such that they actually behave that way and don't, don't just give it lip service to it. Yeah. Do you think, you know, so as you're thinking about that, I think one reason when you and I were talking about this, it was, you know, it's not even to say that certain apps won't end up in these platforms. But is that the place you start versus saying, as you said, you're looking at certain applications that make sense to migrate? Do you look at the things that, you know, what are some of your rules of thumb that might say, look, if your app already goes through a CICD pipeline, it might be a good fit. I feel like I'm doing the Jeff Foxworthy redneck thing. But, you know, if, you know, what are those things that we can say is a 12 factor? Has it been written in the last three years using a modern language? I mean, there's some things you can potentially do versus, I don't think I start by trying to figure out how to containerize Siebel. Like, that's probably not my first thing I go after. So, you know, where do you start to hit those thresholds? And this may only be a 12 month journey. You might get the skills in house. You might start recognizing patterns. So now, you know, as people start doing these things, you do start to recognize the right patterns. You start to see. And then when you start, then you put that perspective on some of your existing workloads. You might say, you know what? This is when we're just going to leave put because something that might have looked attractive 12 months ago. I know what it means now to run efficiently in these platforms and where we would take advantage of it. We wouldn't get any benefit here versus just boiling the ocean to start with. And I would think most people don't look at these platforms and start with a boil the ocean approach. That are there things, you know, from your advice that you would think that say, like, if I'm doing a slight checklist to get started, these are ones that feel like these are going to get you a good sense of taking use of these platforms and prepare you to do migration later on.

Yeah, I mean, to your point of what you're alluding to, I feel like there's two things. One is, like, size of the application. Like, if it's a relatively small application, chances are higher it doesn't fit – it doesn't key off the second thing. But chances are higher it can be pretty – you know, you can replatform it, right? And so, you know, when I was mentioning moving hundreds or thousands of applications, I would imagine a lot of those are what we might call, like, departmental applications. They're basically custom-written applications over some sort of, like, weekly data source or some workflow approval thing that are, like, not really complicated or sizable. But for the individuals or teams that use them in an organization are, like, vital for what they do, right? Like, there's just – you know, some people would derisively call these, like, craplications or something. But, like, the right kind of craplication will save, like, a handful of people a ton of time and be very profitable for that group versus, like, manually having to do things. And so, you know, and a lot of it can come down to just, like, basic, like, ETL and data manipulation and approval types of things, right? And so those are very valuable applications but are relatively small. And so, you know, to mix topics a little bit, those are a good tranche of things to pick because it's likely they'll be – you can replatform them. And then, two, they're small enough that you can start understanding how to do things in a cloud-native way and moving things over. And then, three, they're actually, like, valuable and have users you can go interact with and do things with. So they're not, like – they're not, like, fantasy projects or, like, science experiments. And then, I mean, the only other, like, things are just so variable that the only generalization I could hope to make is, like, the fewer dependencies to weird things the application has, probably the easier it is to replatform. And, like, I put it that way because I'm remembering a few, like, whiteboarding sessions I've had with big organizations.

And they'll, like, whiteboard out, like, their entire system for, like, very popular, like, web applications we interact with to do, you know, whether it's shopping or travel or whatever. And you look at all the dependencies that the entire system has, and there's just, like, an endless amount of weird things it integrates with to just, like, you know, all the way down to, like, here's how we upgrade the images. And that requires this, you know, once you map it out, this very baroque process of things. And it's just, like, just bizarre stuff that you have to integrate with. So, the more and more dependencies you have outside of, like, a cloud-native environment, the more difficult it would be. Now, there's, like, ways around that that basically amount to, like, having API gateways and even doing things like having a strangler approach where you kind of hide this weird dependency and make it so you can kind of rot out the tree underneath and replace it over time. Which, again, is very commonsensical, almost nonsensical sort of advice to give people. But, yeah, I mean, I think a lot of it is just, like, choosing those early wins that will let you learn how to do something on the platform. And then after that point, you left this bucket of stuff that, like, isn't really easy to move over. And you just have to, like, systematically choose, like, you almost take a book out of, like, the Toyota production system way of thinking is, like, don't really, or I should say consultants in that area, don't worry about how we're going to do it. Give me, like, the top three things as an organization you would like to do and problems you would like to solve. And then let's go solve those issues and see if these new technologies can help us with that, right? Like, and, like, maybe you can't run it on a new cloud-native platform, but you can use a lot of the processes and thinking and the people, the soft skills and culture to solve that problem. And then eventually move it to a new technology if it makes sense. But, you know, as ever, like, it seems like the important technology is, like, the meatware technology, all the thought technology, if you will.

And so I think from a portfolio management perspective, it's important to go to the business and have them say, like, the big problems they want to solve and then go and investigate how to solve those problems. And don't necessarily start with, like, step one, install a cloud-native platform. Like, look at the process that you're using to solve that problem and how people are organizing around it. And then it's sort of like, you know, eventually you'll get to using a platform if that makes sense. And if it doesn't, you'll save yourself some hassle, but you'll solve your process problem in the meantime. Yeah, no, that sounds good. I think the key is everyone wants to run fast now. You're getting asked to run fast now, but it's got to come down to, is it adding value? Am I doing this just for the sake of it because it's fun? And you know what? And do those for small R&D things. We should be having fun. We should be experimenting. I guess don't experiment with crazy stuff. And to some extent, make sure there's value before you embark on a nine-month effort to replatform some core system just to get it into your, even your Pivotal Cloud Foundry environment. I don't want those things if it's not going to add value to your company. I mean, maybe that's blasphemy to say, but I'm not quoted, so I don't have to worry about sales. You should be putting things in there that add value to you. And everything else should be taking, be on the back burner. And I think if more vendors took that approach, we'd have less confused customers. Yeah, and I think, you know, it's always this weird line of skirting the bimodal razor, right? Which, I don't know, I'm still undecided about, like, the goodness or badness of that. That would be another good discussion topic at some point. But to some extent, it's about prioritization. And I think when it comes to brand-new applications, Greenfield applications, it's just like, yeah, obviously you do them in a cloud-native way. So that's a solved issue. And I think on that topic, you know, I don't know if people would be surprised, but to put it another way, there is an endless opportunity for profitable Greenfield application development in most large organizations, right?

Like, you may be saddled by legacy applications, but there's always a new application that you could develop that would make your customers' lives or users' lives better, right? Or to your strangler point. I mean, there's stuff that you can do around the edges of your existing systems. They're not silos. Like, go put a great gateway in front of it so that now your mobile users don't have to be on the VPN to enter their timesheet. My gosh, you'd be a hero. So use these platforms to augment existing systems versus your first thought being, how do I move this system to that platform? Right, right. And, you know, I should put a link to this. There's a good, as always, there's a good Jeff Bezos thing here. It's something about, like, there was some big discussion about rewriting and replatforming. And then he printed out and made everyone read this, like, three-page memo from some, like, Navy nuclear reactor scientist that was basically saying, like, people love debating technical problems. And so let's have a framing for theoretic solutions and pragmatic solutions. And, like, it's actually – and the point of the memo, as far as I could tell, was the only people – it's translated into this discussion – is the only people who should really discuss replatforming and rewriting are the people who are going to actually do the work. Everyone else should not be involved in that conversation because it turns out to be more than just theoretic, right? And it's – but it is a good framing for that. And I think, you know, I think that's – the point you said is kind of a good way of leaving it is, like, so you've got all these new applications. And then replatform the ones that you can. That makes sense. And then extend and sort of wrap APIs and all this extension stuff around the other legacy applications. And then the very last one is actually rewriting things. And you really only rewrite things if you really need to. Otherwise, it's probably a good idea to just write brand new things around it instead of rewriting it.

And my theory is a lot of what that ends up looking like is – and this is why microservices to word salad it, like buzzword salad, it becomes so valuable – is a lot of it ends up being – instead of rewriting the legacy stuff, you figure out how to provide services around the legacy applications that you have that new applications are written on, which is sort of a high-level overview of Strangler stuff. No, I think that's such an exciting – I don't know. I like that development. Like, look, put Spring Cloud Dataflow in front of your database. It doesn't mean you have to change your database. It means you can do some things with streaming data or processing. There's just – I like that idea instead of saying it's all or nothing. I either completely rebuild this thing or, you know, I'm stuck with it. No, you're not. Again, work on what matters. Small scope. It's for microservices, DevOps. Let's keep going with your word salad. You know, having the stakeholders actually involved in these processes. Again, do the work that matters. Use the platforms to help you get there faster while at the same time not extinguishing the joy of programming your devs have. You should be using stuff that's fun. But let's not lose sight of the fact that you're in a business to actually make money. Yeah. And then as a final thing, I think it's probably the easiest people to convince to pick up the habit of flossing are someone – people who don't have any more teeth, right? And so, you know, if you find yourself mired in all this legacy stuff – I forget how you were putting it earlier. Not to be all, like, you know, snarky and pedantic about it. But, like, this is a good reminder that you should try not to get yourself in this trap in the future, right? Like, you should develop the good habits, like, you know, test coverage and, like, having good portfolio management, all these things that prevent this problem from happening in the future. Which is – it doesn't help you with your current issues, but hopefully it's motivation that you can have to avoid creating that problem for yourself in the future. Absolutely. All right. Good discussion. Yeah. So, you know, and also this goes into our little self-serving ad at the end.

Like, I think we announced most all of the talks for the SpringOne platform conference. We did. There's a good melange of, like, Greenfield stuff and legacy and all sorts of things in there. I was looking through them, and there's several sessions in there that kind of go over large companies figuring out – large organizations figuring out how to deal with legacy and do cloud native and things like that. Like, there's one by Matt Curry at Allstate. I'll have to see what it's about, but it's basically managing multiple pipelines and managing multiple things. And then we'll also have, like, Brian Gregory from Express Scripts talking there and all sorts of other people who – among the code level stuff, there's a good track of how to think about enterprise architecture and management and even the business side of things going on there. And we just got a bunch of discount codes, or at least some people did, that we can get – so you can get – if you go – so SpringOne platform is August 1st to 4th. And I'll put a link to this in the show notes. If you just search for SpringOne platform, you'll find it. But if you register, you can use the code Pivotal-Coté-300 to get – you probably can guess this – $300 off registration. But there's a little special for podcast listeners there. But I'll be there talking about, like, my DevOps talk, like how it's going and how regular people can start using it. And there's a whole lot of other good talks there. But most of the things that we talk about in this podcast will show up there as a topic. And you'll get to talk with people face-to-face. Yeah. Yeah, really impressive session list. If you use my code, PivotalSuroder3,000, I'll give you $3,000 off. So that's – no, it doesn't work that way. Yeah, that works. Suck it, Coté. Yeah, it's a bit better. That would be awesome. That would be awesome. But, yeah, no, check out that session list. I'm, you know, hey, as someone who's new to Spring, I can't wait to go to this thing. Because not only is it Spring stuff, it's Cloud Foundry stuff, it's DevOps, it's Agile project management. You could be a data scientist. You could be a PM. You could be all sorts of things. You're going to find interesting things in a conference like this. And, you know, I tweeted this out today.

But things are changing so fast. I want people to stop and invest in themselves a little bit. Take three days and learn from some of the smartest people I know on just what's going on versus, hey, I know I picked up a book on vacation. I read some stuff. I'm keeping it up with blogs. That's not sustained learning. Like, spoil yourself a little bit and take a deep breath and just learn new stuff. That, I think, reinvigorates all of us to go back to our day jobs. Yep. Yeah. It'll be fun stuff. Well, with that, this has been the Pivotal podcast. You can, as always, you can find it at pivotal.io slash podcast or by searching in iTunes for, I think if you just search for Pivotal, you'll find it actually. And we'll, we'll see everyone next time. You can, you can feel free to reach out to us. I'm, I'm Coté in Twitter or just Coté at pivotal.io or you can email podcast at pivotal.io. How about yourself? Yep. You can find me at, at rseroder or rseroder at pivotal.io. Well, that's great. Well, we'll see everyone next time.

Tanzu Talk · 🍕 Get more pizza.