Magic Little Scripts & Favorite SpringOne Platform Talks

Episode 95 · 50:04 · SRT · archive.org · all Tanzu Talk

Now, I've got a few, I think throughout my two-year term here, I'm going to have a few highlights. The first thing I want to talk about is there are two things that are longer than we have in the U.S. Now, most people are like, you know, everything's small in Europe. You know, I think, first of all, you know, I kid. I'm not being vicious about any of this. But, you know, I think there's a symbiotic relationship between the fact that it's really hard to find a bathroom and that people don't seem to drink very much water, judging on the availability of it and the size of cups that people use. So I think that probably works out well. Now, that's a good example of things people think are small. But there's two things that are longer. One, beds are much longer lengthwise. Yeah. I don't know if they're narrower, but they're very long lengthwise. And also, each individual piece of toilet paper is about a fourth longer than our American toilet paper. I don't know what to make out of both of those if they're related, but they got lengthy things. I love your attempt at correlation there. That was unexpected. I mean, there must be some relation, right? There must be a reason. I mean, these seem like good icebreaker questions in a team meeting to see what people come up with. Yeah. Well, you know, I have learned when you ask these kind of things, you know, globally to people, it takes a little while to – I think you have to switch people's minds. You've got to switch their mode or their register out of, like, serious business, business stuff into, like, everyday things they've never really thought of. Like, I ask these questions a lot and people are a little confused. And then I explain to them, like, what I'm getting at. And I think they end up answering it. Like, a lot of times I ask, like, how do you operate this food? And it takes people some time to figure out that – I'm asking in this – if someone, like, was given a fork, you know, and they're like, I don't know what to do with this, I think we would be kind of flummoxed. But they – I really mean, like, what do I do with this fork?

Which end do I eat with? Do I put this into a cork and then put a piece of food on the other end and, like, eat it armless or something? So, you know, things like that. So I'll have to find out about the toilet paper. I'll report back. Yeah, no, inquiring minds want to know. Also, closing out that topic, in the hotel room I stayed in temporarily, the toilet paper was provided by the Kleenex company. And you knew that because every third or fourth sheet had the word Kleenex printed on it or Kleenex, if you will, which is kind of an odd choice. I don't think people normally want to put their brand on toilet paper. Yeah, I guess that – we're not using that for the SpringOne platform giveaway this year. You've spoiled it for me. It's too late, isn't it? Otherwise, we could have done that. A roll of toilet paper. Yeah, it's practical. Sure. Well, I think it's been several weeks since we recorded. Google Next was – that was last week, right? Or the week before? I've been moving, so I've lost track. Yeah, two weeks ago. Two weeks ago. That's right. That's right. What are significant things that happened last week? You know, there's a time zone difference here, so I've lost track of what's happening. Yeah, there's still a lot of good fallout in a good way of people kind of digesting Google Cloud stuff. So last week, you know, there were still some good blog posts on some of the machine learning stuff they shipped and some of the new cloud server types and obviously stuff like we'll talk about with Knative, things like that that came out. So a lot of good stuff from the last week, kind of people digesting what came out of the show. So, yeah, last week itself, though, you know, I like the news for Cloud Native Computing Foundation adding Harbor to their sandbox. This is that open source container registry that VMware started years ago. I think it's actually their most popular open source product. And so it's the only container registry in the CNCF, which is interesting. And this is part of Pivotal Container Service today. So this is already something you get, but this kind of opens up more people being able to use it. And it's not just, you know, hey, it stores images, does things like security scanning and LDAP and Active Directory integration and kind of enterprise-y things for a container registry.

So I think it'll get a nicer profile now, which is pretty cool. You probably know better than I do. How many registries do you think are container registries are out there now? There's at least like, if you don't count, I guess you would count public cloud ones, but there must be like way over five, right? Yeah, I was wondering what number you were going to choose there. Yeah, so it was way over a thousand. Yeah, there's, you know, obviously people use Docker Hub, at least for messing around. Google's got a popular one. You know, Red Hat's got one they acquired through one of their acquisitions. And now there's Harbor and some other ones that at least expose some of the Docker API. So it seems like there's at least a handful of ones that people use. But yeah, it hasn't exploded to like dozens. But it does seem like this will be interesting. Because arguably this is one area where maybe when you're getting started with Kubernetes or containers, you don't pay immediate attention to. It's just, yeah, let's just build some containers and push them up to Docker Hub or whatever. But I think as people start getting serious, they realize they want to have a lot more curation and control over base images. They want to make sure they're patched. They don't want to introduce accidental vulnerability. So it seems like as you mature, if you don't already do this up front, you pay a lot more attention to the registry. Yeah, I remember as perhaps you do back in the WS star era, there were there were many registries. And I mean, this is slightly different, but there was registries and direct I guess they were directories, not registries, but a similar sort of you've got a centralized thing that is key to your whole system. Otherwise, it kind of like comes crashing down and back then open source software in that category was not extremely popular like it is now. And so I wonder how that will play a role in consolidation of registries. Because it does seem, it would seem weird if you had like 30 of them running around there. But I don't know, maybe there is, there's ways of validly differentiating between all of the different registries that you would have such that you would have like 50 or 60 or just all sorts of ones of them. Yeah, it's a good question.

It just seems like as long as they implement the standard API, which they do, so that, you know, in theory, when I can push a Docker image to Pivotal Cloud Foundry today, right, I can push source code or images. As long as I point it to a valid registry, it's the same API to talk to. So you're, as always, you're adding features around it to make it more useful, but the core interaction's the same. So that'll be interesting to see. Sure, is there an explosion of registries that add new features while keeping compatible interfaces? You'd suspect so, but I guess we'll see. Yeah, I mean, that reminds me of another, another, man, I'm trying to think which, which thing this was. It was probably a Steele or something like that, but, or no, it was the, it was the, the K-native or the K-native or however you're supposed to say it. I think, I think there was a video somewhere that K-native is, is, is the right thing. Is that right? And, you know, it was, it was, it was, I was watching that, the, the video that had, I only remember, DeWitt Clinton off the top of my head and, and, and one of our people whose name I should remember. And then the other guy who was in there and it was interesting the way they were talking about K-native and it reminded me of the old, you know, JEE stuff where we have basically like these interfaces and APIs and we may be sort of kind of have some code implementation. I mean, it's only in like, like alpha-ish at the moment, so it's not finished out, but, but we didn't, we maybe, or maybe don't provide the whole implementation of things. And then analogously in the same way that in the I'm, I'm way old. So I always think J2EE instead of J3EE or whatever, but back in the enterprise Java day, you would have all these app servers that would basically implement your, your stuff. And it seems like, uh, analogously, uh, similar to that, at least off the, you know, the way it was being spoken of as a standard for doing things and specking out the components. And then it would also be like, uh, insultingly fun to do some like J2EE thing and draw lines

between them of like, you know, here, here's the, the registries and here's how you look things up and here's how you manage the traffic. Hopefully there's EJBs in there somewhere. I think people love EJBs and maybe we can tweak that in somehow. That's right. Yeah. I mean, I know, you know, we glossed over the K native stuff for a moment, but you know, we did get to work on that for a few months ahead of time. It was native until like two weeks before. And then they added the K back in. It used to be, it used to be silent, which of course made sense. So trying to get back to calling it K native was difficult, but you know, without being hyperbolic, this feels like one of the more important things that gets announced in 2018 tech wise. And I only say that because if you're running Kubernetes, you're probably going to end up putting this on top. And just given how ubiquitous Kubernetes has become, this feels like a significant thing. Now, maybe I'm wrong. Maybe it crashes and burns. Who knows? But K native seems like a nice way to put app centric function centric abstractions on top of a layer that frankly, most devs shouldn't be messing around with. Like if I'm trying to focus on software, I don't want to deal with DNS and load balancers and container orchestrators. That's not my, that's not where I should be spending my time. So if I can give me better abstractions and it's a complex abstraction, it's not trivial, but if it can be run as a service and something like pivotal function service or Google's function capabilities, it seems like this might be super important. So I guess we'll go, we'll see. But this was a surprise announcement for most. It actually leaked zero leading up to the announcements, which was pretty surprising given how many people kind of knew about it. So it seems like a big deal. I'm glad we're involved in it, I guess, uh, stay tuned for how big of a deal it is. Now, no, I know you follow all this stuff closely, especially when it comes to words, you know, this is basically your business, right? Words, words, words, words, and, and, uh, pictures on PowerPoints. But, uh, so, so, you know, when they're talking about K native, it was sort of like, this is a, for serverless serverless, it was like every, every third to 20th word. And then, and then like, how, how are you thinking through how you would distinguish K native

is for serverless versus like, I use Kubernetes to run applications. Like what's the, what's the distinction that, but between those two things, if any. Yeah. I mean, I think that's going to come out over time. I mean, in essence, it's taking you up a layer saying, do I want things that are more app aware? Do I want things that are more functional aware? Do I want to deal with these primitives, which are just Kubernetes and containers? And yes, custom resource definitions and all the power that's in an orchestrator. Or should I think about if I have code, I just want that code to run somewhere, which sounds a lot like the cloud foundry sort of value prop, right? But with functions as well for K native, because there's a whole build service there. Like just give me my function source code, build it, and then run it on Kubernetes. I don't really care that it's Kubernetes, just run this thing for me. So I think it continues to try to move up the abstractions. It says, as a dev, if I'm being paid to ship software, I'm probably not being paid to figure out some of the plumbing if I can help it. So why don't I just keep staying good at software? So it seems like it's trying to move everyone up a layer and it's, it's helping you focus on source code and not necessarily having to focus on packaging and configuration. Right, right. And there was a, there was a demo by the other Google guy whose name, I can't remember. And it was just a basic, I mean, there was two demos he had. One was a hello world demo where he built his own container and then they, he had the system build a container for him. And yeah, I mean, I guess what'll be interesting to see is when, at what point do you not deploy your application fully? I'm doing air quotes here, serverless, right? You know, it would be nice to think about. So if I'm doing a, and I've gone above sort of, well, I'll just use K native as the demo example, like doing that style of programming. Could you do an entire online banking system from it? Like seeing your accounts and transferring money and bill pay, or is there some sort of, to be jokey about it, do I need some server full layers? And, and let's, let's assume there's no like legacy stuff you need to support or, you know,

any stuff like that. It's just a brand new application. Yeah, I mean, you know, being, I'm purposely steering all this conversation towards serverless because, you know, that, that's a part that we're spending a lot of attention on. But in reality, this is just apps. So apps run on K native. And yes, they're more ephemeral scale to zero apps, which we think of as more of serverless and functions and things like that. But in reality, I can deploy just apps to K native. Now, is it going to be as friendly to some legacy stuff and things like that? Probably not. I'm still going to have, as always, multiple sorts of abstractions for different types of workloads. But it feels like, I mean, yes, in some cases, I could run full systems on K native with different types of apps, some that potentially are function sort of stuff, others that are just full blown apps, and then having the eventing subsystem that works between them, which is part of K native as well. We'll see if that's a pattern that emerges, or if this kind of gets used for one sort of workload, and you still have other sorts of abstractions for more stateful stuff or long running services or streaming or what have you. But, you know, it's an exciting way to maybe have us spend a little less time on infrastructure plumbing and a little more time thinking about software. Yeah, yeah. I mean, that seems to be, that was what was exciting about that demo is here's a more concrete example of how serverless is just a new way of doing application programming and not sort of like the lesser thing of like, you know, a lot of the conversation here about serverless is like, it's these ephemeral event driven things that run and you're kind of left to think of them as like, weird little magic scripts somewhere and not just like, not just like I wrote a go application and I put it in the Docker container and now it's running. And it also is sort of like, I mean, the legacy thing is always a problem. I always think of, you know, I was never a big physics person, but I remember a lot of physics equations were like, well, first of all, let's assume friction doesn't exist. And I think that's the equivalent of like, let's just assume legacy doesn't exist.

So we just take friction and legacy off the table to have sort of a pure understanding of things which is fine. But but it does it does seem like when you started thinking about it in that way, it's interesting that it gets back to the cycle of like no ops, like a long, a long time ago, I don't think I'll look this up must have been like four years ago, everyone in the DevOps world, or not everyone, but the discussion in the DevOps world was like this no ops thing is crazy. There's there's, it's not that there's not going to be any operators. So we shouldn't say no ops. But then on the other hand, like you kind of like, think about you look at that demo and other things, and it does seem like, you know, in a less sassy way, this vision that we had of no ops in the past can sort of come to fruition. And instead there's, you know, platform ops and SRE and things like that. But it's in the same way that like, I think maybe two or three years ago, all of the all the, you know, you know, hair color tinted people, and all the DevOps stuff, we're saying how serverless was ridiculous. That was a name. And now everyone says it as a name. Like this kind of like this cycle of these phrases that come and go. There you go. I think magic little scripts is probably the title of this episode. That's right. Only quotes are magic little scripts. Yeah. So yeah, the last piece of news, I think you might have added one more was also related to this was the was the ST1.0. And this stuff's kind of plumbing for people, this idea of service meshes and control planes and sidecars. And like, gosh sakes, I can't keep track of Kubernetes and serverless. Why do I have to care about a freaking service mesh? So on one hand, I guess people could tune this stuff out and feel like it's just noise. But it is something that's important to platform builders. It's something that our pivotal post actually did a really nice job telling kind of a history story that explains why this stuff matters and why this is coming into Cloud Foundry and why this is something that platform builders should care about. I mean, should most, you know, enterprise engineering teams be deploying this stuff? I don't know. It still feels like potentially you want something integrated by a platform provider, but you can.

So but there's also gonna be some new architecture paradigms that come from this as you think of sidecars versus things embedded in your code itself or things like circuit breakers or distributed tracing and instead moving that into the service mesh. Like these are now fundamental conversations we're gonna have to have about where does this stuff belong? So I guess my advice is don't, I mean, be on the sidelines, maybe keeping an eye on it. Maybe you don't jump in with two feet on deploying these things, but don't ignore this conversation because I think it's going to impact how you are deploying software as an enterprise in the next couple of years at the latest. Yeah. And to sort of reprise something I was talking about earlier, I think as you're saying, there's sort of like this coalescing of standardization. And I don't think you're supposed to talk about standards nowadays. I think in the post like WS star like error, we can't ever have standards again. Very, very bad to have standards. You don't want that. But let's say, let's pretend like we can use that word. But there's standards that are emerging. And as pretty much everyone on the vendor side and the user side, and then the open source side, like really, things turn out better when there's standards. Because one, you know, if you're buying on the buy side, someone consuming this technology, like you kind of know what you're getting into, you understand, I want to buy something that satisfies the standard operates this way. And I can focus on if it's the best way of doing it and how performant it is, or if I like the way it does it. But you don't have to focus on like understanding what serverless means, or what cloud native means. And then of course, on the production side, people like making and selling stuff. It's good because you don't have to like, spend a lot of money reinventing everything. Like it just makes everything more efficient to have standards around this, which it's probably for the better that things coalesce towards that. And you know, it's nice to have like a period of innovation where there's all these different standards happening. And you've got your thousand flowers of blooming grass that gets cut because it's too high or something. But, you know,

eventually, you want to coalesce down into just a few things or it's or it's madness. So when one just little fun thing, I haven't actually used this yet. Because that because I've been moving, as I mentioned, but I saw that Amazon released this thing called part finder. And, you know, it doesn't really have anything to do. Well, it sort of does. But as I understand it, you can like point your camera at a physical object, and it will say, that is like a three and a quarter inch, or I don't know, 20 millimeter screw. And of course, Amazon's motivation is like, so you can go buy some. But it is it is like, it's an intriguing and I've noticed my son has this issue every now and then is well, actually, I'll tell you exactly what happened. We were in the airport here. And he found half of this weird little wooden thing with spikes on it. And he kept asking what it was. And I was thinking like, oh, if only we had the part finder, we could point it at it, and it would tell him what that thing was. But it's a fun idea. And I'm sure it's not this great and universal. But it'd be a fun idea that you could just sort of walk around kind of, I guess, whether you want to think of yourself as that Terminator view, or maybe the predator one, I'm sure in Star Trek, there's one that's like peace loving and non capitalistic or something. But you could just point your little camera at something and have it tell you what it was and information about it. It seems like a really interesting use of a lot of like, you know, giga technologies we've been talking about for five years with augmented reality and machine learning. That's the stuff that normal people can relate to and not all the necessarily plumbing stuff that sometimes we geek out over, but it's actually not outcome oriented. So the things you're talking about, that's the actual outcome, right? That's the things that somebody will make money on and make me want to use your service. Yeah, now that I think of it, you know, I don't know if you've had this problem. But you know how you're like, I never really know which screw I should be using for some or if you got to match a drill bit to a screw. And that's always a problem. And that would be a great little AR thing is to put like a screw down and have it say you need the three

force drive, you know, screw drill bit or you need this one. That would actually be great. That's kind of, you know, the first AR thing that I saw that was really useful was the hanging pictures AR thing. Do you ever use one of those where I have, you know, I don't know, maybe you don't have this problem over there in the Pacific Northwest. But typically, let's say you've got two people in a relationship. One of them wants to hang a picture on the wall. And the other one is like, maybe what I'd like to do is anything else. Because, because what will happen is you want to make sure the picture's even. And so you hang the picture up. And it's, of course, not even the other person is like, you know, maybe you move the left up a little bit. And then you do that, and it's not even and you know, you're trying to make it level. But there are some apps that you could use. I'm still so I'm sure they're still around. And they would tell you basically like where to put the holes so that things would be even. And so relationships be less stressful, essentially. I think also in the past two weeks, the the the a lot of the sessions for SpringOne platform were announced, I forget the exact date. But every year, we like to kind of go through and talk about ones we're looking forward to. And I think we've both been involved. And I mean, you've done some crack sharing and a whole lot more as well. So you kind of have been watching things as they evolve. But yeah, there's, you know, looking through our list, there's a few that we both chose. So we've got a good, good Venn diagram, but not not that overlapping. So I think this year, speaking of track sharing, I was as as I was last year, and maybe the year before, I don't really remember. I was I was helping out along with several other people on the the newly every year, this track gets a little different. But we have the the DevOps pipeline and agile track. And I think what's fun about that track is agiles added in there, which which has shown up here and there in the past. But it's a huge, huge part of what pivotal customers do. You know, the whole point is improving the way you do software. So they should be doing your software in an agile way. So there's a few sessions in there that I think will be interesting

to see one of them. And I remember going to this one, there's one called data driven decision making for product development, which by far is not the longest title of the talk on my list. So you can get ready for that. You know, I'm always a fan of very long titles. So I'm looking forward to it. But I think what's interesting about this talk is, you know, it's essentially, you know, we talk a lot about, or at least I do, about the point of doing software better is to put it and using all this container stuff and cloud native things, whether you're server full or serverless, or you've got ops, or you're no ops, or whatever, is eventually, you want to have good software. And the way you're going to have good software is to put a fast feedback loop or a small batch process in place where you can deploy some software. And every week, you can observe how it's being used and make product decisions based on it. And this talk, I think, is going over how you do that, what it looks like, as the title says, to make data driven decision making for product development. And I think it's a topic that is, I don't know, it's discussed every now and then here and there, but it's never really discussed as much as I would like it to. For example, now I'm gonna have to go find the link to this. I mean, I think, I think the one of the, I guess it's sort of academic, but one of the academic-y sort of citations for the idea that you should observe what your users do, and it will make your software better is this, I think it's maybe like a 2008 Microsoft write-up where I think it was in, maybe in Bing or Xbox, they were, they were looking at user behavior and they tracked, I don't know if it was all, but they tracked a lot of features that they had put into the version of the software. And they found out something that like only, I think it was like 30% of the features were used in a way that their product managers originally thought they would be used in, which is a little bit of a weird wording. It basically means that 70% of the work that they did didn't really result in what they wanted. Like the feature didn't really work out very well. So

I bring that up because that's sort of like the most widely known citation of like data-driven things. So it's always good to get a lot more of those things out there because, you know, I guess that was a decade ago or more. And, uh, but it'll be interesting to see what, uh, the two speakers in there go over. So how about, how about you? What's a, what's one, we'll go back and forth. Yeah, we'll go back and forth. Yeah. I know for those who, uh, haven't attended SpringOne before we did update some of the track stuff. I know Coté, you had mentioned that, you know, not specifically just a DevOps track. We're doing some agile stuff in there as well. We added some serverless attention this year, a Kubernetes track, just kind of reflecting reality of what are our customers doing? What is pivotal offering? So the tracks continue to evolve. The mainstays, stage, which I'm responsible for, uh, has come together really nicely. There's actually code every day on stage, including the third day. So you're always going to have code demos and then kind of people talking about outcomes and then back to some product updates and just keeps a, hopefully a good vibe. We also have different MCs every day just to mix it up. So people like Josh Longman and Dormain on day one and Diogenes and Lauren on day two, Peter Humphrey and Andrew Clay Schaefer on day three, just kind of keep up, uh, keep things unexpected. So it should be fun. Just the, the vibe continues to change every year just for fun. So you don't get bored. But when you look at the talks that I'm, I was flipping through, you picked more than me and I was trying to down select, I guess I shouldn't have. Uh, one of the ones I picked was, it was use cases for STO and Envoy integration with Cloud Foundry with, with Shannon and Usha and, and Shree as well. I think they've, uh, two or three of those have been on the podcast before, but one of this was, as we just talked about, you know, as we think about STO, as we think about Envoy and Cloud Foundry, like who, who cares? Like what is all that doing for the platform? So for them to be able to come in and they explain this stuff well as like, what is this going to enable in the platform? How is this going to make it possible to have potentially clusters talk to each other or different abstractions talk to each other? You mentioned Coté, this idea of, Hey, would maybe my whole banking architecture just be on

something like K native or does it still spread across? And if we assume the answer is it spreads across, how can the networking be transparent? Like, I don't want to care that this is on K native and this is on some other Kubernetes cluster and this is on Cloud Foundry. I just want things to reach each other and talk to each other and it doesn't matter. So what happens when networking becomes just this sort of connected mesh that spans clouds, spans different facilities, spans different clusters, abstractions? So I think that's where we're starting to go with this. So I'm interested in this particular talk just to see how we're starting to plant those seeds. Yeah, I know that there will be a good, good to see that. I mean, I think that's like looking through all of the talks and I won't go over all the talks because I did, or the ones I selected, but there is a, there's like a whole lot of new topics even from, from last year as we're going over. I mean, we've had a, there's, there's of course some Istio things and there's, there's another good one. I forget the name of comparing Spring Cloud to Istio, which I would be eager to see. That's always one of my first questions. And there's also, you know, also in the, as I mentioned, the DevOps track talks about pipelines now, which, and I remember making sure we selected a sufficient amount of pipeline talks, which I think is another thing that is good to start highlighting because it seems like, I don't know which one would be number one versus number two. That's always kind of a false distinction, but it seems like one of the most important assets you have is your build pipeline, right? Like a lot of, a lot of problems that get solved, get done in your, your build pipeline because of the automation and the tracking and the kind of non-manual way of doing things all the way from compliance things to handling security to just like making sure your code works. And then the, the ability to roll back and run multiple versions, all of these things are made a lot easier by your build pipeline. So there's a couple of sessions on that. And one of them that, you know, I always like actual customers talking because us people at

pivotal are great and brilliant, but, uh, then it would just be, if it was only pivotal people talking about how we did stuff, it'd be a conference about software vendors, which might be fun, but not as widely applicable. So there's one called, uh, uh, as short a title as you can have two words called extreme pipelines that has a MasterCard person and a pivotal person on, and it goes over how, uh, MasterCard built up their pipeline and, and, you know, some lessons learned with it. And so that'll be a good talk to look at for people who are, uh, you know, curious about actually building out a pipeline. And I say actually, because, you know, what I tend to find is, uh, based on questions people are asking and what they're using, they might have like a continuous integration, uh, pipeline, so to speak in place, but they may not have the full blown pipeline, uh, that you would expect from people. So, uh, that, that'll probably be a fun one to check out as well. Yeah, no doubt. Related to that, you had mentioned one, uh, in your, in your notes about this, but it was one I flagged to around zero to multi-cloud related to that. Cause that point of, okay, how do I actually kind of take what I'm doing in probably multiple environments, multiple clouds, even, and just have some automated deployments to each of those. It doesn't feel unique each time. And actually, frankly, right before I jumped on the, uh, the podcast, I was reading some thoughts from, from Mitchell at Hashi Corp who had some good answers today around what does multi-cloud mean? What's the point of it? And again, it was kind of consistency of some of these things across environments and what does it take to achieve that? So, I mean, this talk by our folks from John and, and margin thinking about that and how they use Spinnaker, how they use spring cloud pipeline. I think that's important stuff. Cause if we assume the future is I have lots of infrastructure in different places, how can we at least have consistency to all of them so that your choice of cloud is made at the last responsible moment, not the first thing you're figuring out. And if we can do that, that seems to offer a ton more flexibility. Oh, and I think also, as always, Marcin has figured out how to get multiple talks accepted. He's, he's always clever. Yeah. I think the other one he's talking on is, uh, is going over at Zipkin,

which, uh, will be exciting. Uh, it's always fun to see tracing, you know, for someone, for someone who used to, uh, walk SNMP MIBs, I always like a good tracing story. Do you ever do that? Do you ever get like a home router or home wifi access point and you're very excited because there's SNMP on there or, or, you know, you can turn it on in, in, uh, I guess it was OS 10 back then. You can turn it on in Mac OS and you can just sit there and look at your SNMP stuff. Man, you have more fun than me. I need to change my routine. That's a good response. You have more fun than me. Uh, yeah. What's your next one? Well, I think, uh, there's the, speaking of, uh, people doing things as a world of customers, there's, I, I didn't write down the whole, uh, the whole title for it, but there's, uh, Boeing has a talk that they're doing, uh, with a little person and I'm, you know, other than it being from, uh, you know, Boeing is an interesting company to see how they do software because, um, I guess most people know them for airplanes, which, you know, important that that stuff works. Uh, and also is a huge enterprise managing the supply chain and all the contractors, let alone your own people and the parts to do it. So they have big complicated problems, but they also do, uh, you know, defense contracting, which has to be like regulated and secure. So, you know, they're one of these companies that sort of like, if they can do it, what's your problem? Um, and the other, so they're, they're just a good case in general or company in general to see how they're improving the way they do software. And then also last year at SpringOne platform, uh, Nikki Allen from there, she gave a, um, she gave a talk. It was pretty short keynote. I mean, as, as it should have been, but it was a good sort of like, here we are launching on our initiative to improve how we're doing software. And she gave a good, um, what I'd call sort of like vision level, uh, thinking about here's what we want to do and how we want to do it. And some early lessons of how we motivate people, which, um, I don't know if you're a developer and you hear the word vision, you probably like tune out and go check, read it or something like that, or read it, however you say

it. Uh, but it is like, it turns out at the enterprise level to be extremely important to, uh, figure out your vision and your leadership and your management and your teams and then individual staff contributors to kind of like walk down the higher speaking of MIBs. And so it'll be interesting to like, uh, I've watched that talk many times from my booklets and stuff, but it'll be interesting to see, uh, the connection between those two and how those practices are being put into place. And I think sort of analogously also from last year, uh, there was, there was like a keynote talk from, uh, I forget his name, but this guy from, uh, is it synchronicity? I think the, uh, the card synchrony, there you go. I think I have an Amazon card through them, but this, this person was laying out on the keynote, kind of like the vision of what they were doing at a very high level thing. And then there were a couple of sessions last year that were, you know, like 40, 50 minute sessions about, uh, how they had done that work. And it was fun to see the connection between the high level vision of like, we want to shoot towards these, uh, I don't think they call them KPIs, but these end results, uh, and we're kind of on this journey because of this reason. And then like, here's how we set up the little cloud downgrades and, and how we connect through those two things. So you'll make a nice little suite of, uh, talks. Nice. Yeah. And we have the Boeing CIO, uh, Ted will be on stage for main stage as well this year. So kind of a progress report and different update on what they're working on. So it'll be nice, nice bookend to what Nikki did last year. Good. My, uh, I got a couple of spring ones. I, I pointed out this is SpringOne. So I guess I should make sure I'm picking spring talks. I'm interested in, which isn't hard. There's a great spring track. Uh, one of them. Yeah. I always love watching Dave Sire speak. And in one of his talks is how fast is spring? Because I think one thing that we can worry about is, you know, abstraction on abstraction on abstraction, like what's the performance penalty? What, what tax am I paying for simplicity? And that's often a concern. Even, you know, I had a customer asking me last week, like, Hey, if I'm using Kubernetes, what's my performance drain when I'm hitting the app in there versus bare metal. And that's,

you know, kind of a, sometimes you're not really paying much of a tax, but it's good to understand those things. You do feel like there's layers of layers of virtualization. So what's the actual impact? So it looks like Dave's talks in the focus on kind of what, what's all spring doing? What are some of these preconceptions you may have about slow slowness and how these apps start up and auto configure. And so he's got some new benchmarks. I've seen him working on some stuff in the Slack channels. And so I think being able to come in saying like, look, look, spring is actually helping you build high performance apps. You're not really paying the tax, but here are things to know. So I think that's really important. So that how fast does spring is one I'm looking forward to. And then related to spring then is one by guy who is the CEO of sneak, one of our partners. And he's got some really interesting thoughts on serverless. I've seen him present before. And so, and he's written up some great stuff as well. So I'm excited that he's coming to the show and he's going to talk about securing spring functions by breaking in. So again, what does it mean to create a vulnerable function? Like just because you're using these abstractions doesn't absolve you of some responsibility for security. So what are the weaknesses in things like serverless apps and apps and functions? And how do you avoid those mistakes? And what do you have to think about with dependencies or whatever, all those sorts of things. So serverless doesn't mean I don't worry about security anymore. So this talk from Guy and thinking about spring functions, I think will be pretty compelling. Yeah, there's probably there probably shouldn't ever be a movement called security list. That's probably I hope not something to go for. I don't know, maybe maybe a Hello world app could be security list. But I'm sure there's some way that could be exploited as well. Well, so I'm going to save the one with the longest title for last. But I think the runner up for longest title of talk that looks interesting. It's called buckets, funnels, mobs and cats. Now they're missing that last comma before mobs. I forget if that's a Cambridge Oxford or Harvard comma. But maybe I should put that in there. That's just gonna drive me crazy. All right, buckets, funnels, mobs and cats

or colon. See, this is my kind of title, how we learned to love scaling apps to the cloud. Now this is from three of the people on our application transformation team. And you know, it just promises to be about that, how how how they took some legacy applications and started working or, you know, legacy is always a weird word, some existing applications, sure, and started transforming it around and tips and tricks they had from it. And so I think I think that's always a that's that's always an excellent talk, topic to see people going over. And then there's also a another another application that looks like it's a way. I mean, another session called rethinking legacy and monolithic systems. See, that one's straightforward. And it looks like it's going to be going over how to apply domain driven design to basically pull apart your monoliths, which, you know, when you sort of I mean, not really all the way back to like Michael Feathers, like dealing with legacy code, a lot of what you're doing to what would be the opposite of legacy? I don't know on legacy. Anyways, a lot of what you're trying to do when you're trying to rejuvenate your legacy applications is breaking them apart and finding finding ways to back to the feathers book, how to test things so you can change them. So finding the scenes where you break things, break them in a good way, split them. And I think I think a lot of why something like domain driven design is so helpful is it's that exact kind of architectural science, so to speak, how would we, how would we come up with a method to divide an application with components? And then the method that we want to use, as far as I understand the voodoo of data driven design is from a, maybe not an end user, but from a business perspective, what are the different components that this business has? And then let's directly, as directly as possible, divide our system up into those business components. You know, and then that contrast with like, you could also divide your system up into

technical components, like, I don't know, the three tier application layer where you've got your data layer, your controller layer, and your UI layer, and then all of the layers in between for things. So I think, I think when I look at look at how people are doing application modernization, a lot of it involves putting a domain driven design in there. So these, these two talks together should be some interesting fodder to chew over. Good. What else do I have? So I picked one as well. Then we think of customer stories, automation and culture changes for 40 million subscriber platform operations, but it's the story of Yahoo Japan. So I haven't heard a ton about them, but they are, you know, Yahoo Japan supports like a third of the Japanese population. They have tons of services, most of them on PCF. So they have some really interesting stories that just candidly, I haven't always heard a ton about. So interested just to hear about the non-traditional stories that, you know, we love our, kind of our flagship customers at Pivotal, but, but frankly, I like hearing completely fresh stories from folks who've been using this for a while, that just haven't been as public with their consumption. So looking forward to that talk. And then as we think about the Kubernetes track, another one I flagged was cloud-native streaming platforms. What's it mean to run Kafka on PKS? You know, we've got folks from Confluent, as well as Pivotal talking about Kafka and PKS and what does it mean to run kind of, again, these complex platforms on something like Kubernetes, which is where it makes a lot of sense. One I didn't flag, but I'm also interested in is the one we have that's about running Pivotal Greenplum on PKS. What does it mean to actually run an enterprise data warehouse on containers? And what does it mean to engineer for that? What do you have to consider? Frankly, the, or candidly, the tech preview just hit Pivotal on Friday. So if you want to mess around with Kubernetes and Greenplum, you can actually do that right now, kind of leading up to the conference. So I think I'm interested in seeing these more complex platforms come to Kubernetes, not just custom apps, which still will probably make a lot of sense for Cloud Foundry and Pivotal application service. But what does it mean to run a streaming platform like Kafka or a warehouse like Greenplum on PKS? I think there's

some things for us to learn there. You know, on the way over here, I saw the new Pacific Rim movie. I think it's called Uprising. Yeah. And it, you know, people like to use Voltron as an example of things coming together. But I think there's a potential thing in there. There's this like, I don't know, it's, it's, it's distressingly analogous to the, I forget the name of it, but the new Star Wars movie, you know, with like, not, not like this Han Solo one or the rogue one, I forget what the new series is called. But you know, you have sort of like, you know, this, this sort of orphan girl who's developed her own, not giant robot, but I could, they call them Jaegers. Right. I don't know why they call them Jaegers. There's probably some reason because they're trying to be global in their movie stuff. They got all the great cultures. And I don't know if they have Latin America in Pacific Rim, but whatever. Anyways, she creates her own like little robot out of parts that she's found, which is kind of similar to a DIY platform. But then there's the very well-made fit together gigantic Jaegers, which have these big booming voices. And, and so I think that's, that's like, I think you and I have like observed this over time and it's kind of like the standards we were talking about, but there's all these different parts that are like coalescing together into like a nice, you know, big chunk of Jell-O with the little fruit suspended in it. And that's evolving more and more. And there's, there's a couple other talks about, you know, hey data, you might want that in your application. That'll be interesting to look at. So my final one, and this is the one with the longest title by I think maybe five or six characters. And then there's another one related to this, but it's, let me take a breath here. Building digital capabilities in the energy sector, leveraging agile processes and cloud technologies. And this is, this is from Singapore power. And as always, I enjoy hearing what actual enterprises or organizations are doing. But I think also the other reason I'm, I'm eager to see this one is we have, we have a lot of

customers who are industrial power company, IOT people, but we don't, we only have a handful of them that seem to publicly talk about it. And so there's a lot of industrial companies out there and a lot of interest in IOT. So anytime there's something like this that comes up, you know, a power company sort of hits all of those, those things. Uh, it's really good to like, see what they're doing and how they're, uh, you know, whether they're doing IOT stuff or planning out or strategizing it. And also just dealing with like physical stuff, like a power grid and how those industries are evolving. I think those are fascinating to see what happens. Cause you know, um, it was, uh, over my software defined interviews podcast, I talked with John Mitchell at Duke energy. It seems like a long time ago now. Uh, but what's interesting, at least in the U S about that industry, as he was saying is that traditionally they've used a lot of off the shelf software. So, and I imagine, I don't know who it's from, but, um, package software to manage grid energy sector stuff. And what he was saying is the, uh, the speed at which that software innovates, for example, to give you mobile apps just wasn't fast enough for them. And so probably I'm guessing globally, it's that same way that people have been using vertical specific software and I don't know, power company management. And, uh, as those companies want to evolve and do all this, like IOT grid management stuff, they're, they're finding that they need to write their own software for it. So this is probably like a common pattern that plays over and over again, that these companies need to, uh, improve the way they do software. So that one, it'll be fun to see if, uh, it delivers on my hopes and dreams. And, and then, uh, since that's from Singapore, there's another just transformational one, uh, from DBS, uh, Singapore bank, uh, going over the traditional things in a good way that are nice to see of how we, we basically wanted to go digital. If you will, we wanted to have a more, you know, just better software. And it looks like it'll go over the, uh, the strategy that they put in place, thinking through like what types of

applications they would do. And as always, uh, things that worked for us as we tried to get more of that, uh, as we used to say, Silicon Valley mindset or whatever. But, uh, so we have at least, there's probably some more, but there's at least two people coming over from Singapore to talk, uh, which, which is great. It's always good to find an excuse to go over there and get some crabs and also just meet with the, uh, super friendly people there. Yeah, no, I mean, one of the goals for the show this year was also to be a little more international and not so us centric. So excited. We have rabble bank on stage for main stage. We have DBS also doing a main stage talk. And, you know, again, I think it just, it brings not only diversity in terms of use cases, but in terms of just, you know, the cultural background and what goes into your choices and look, is DevOps trickier here versus there because of some other sort of inbuilt or traditional thing. I love that, right? That's, that's, it's not all just a roadmap from here's how you go from A to A to Z. It's going to zig and zag based on all sorts of characteristics. So I love when we have a different type of audience there. Yeah. So the last one I had, I think we both had it was, uh, our own Nate Schuda's thinking architecturally, you know, I've, I've really gotten to enjoy his series on microservices. He's been working on right now on our blog, you know, book stuff coming out and, you know, just a really a thoughtful technologist. And so this talk looks like it's focused more on how are we thinking about technology choices on projects? How are we actually making sure we're, we're factoring in the big picture when we're making some of these choices and how do we choose things at the right level of maturity and all those sorts of things that Nate does a good job chewing through. So I'm excited for that talk. I mean, I always appreciate his take and I think both of us flagging, it's probably a good sign. It's, it's going to be a good one. Yeah. I think I've seen him give that talk a few times. I mean, not that one, but you know, an early version of it, uh, coincidentally, when we're kicking around Europe and, uh, I, he, uh, he, you know, usually I don't like the, uh, the, the one word per slide thing, but I think he does that pretty well. And, uh, you know, there's a certain entertainment level of that, but I think as he goes through the talk, he's got, uh, he's got that sort of way of doing

the presentation down and then, you know, you, uh, you accent that every now and then with a funny picture of sort of failure or celebration. There's never just sort of like, uh, you know, funny picture where nothing interesting is happening. Just know, just a field of flowers. That's right. You know, but that would be a fun challenge is to have a, uh, I think we're going to have ignite talks. It's our, you know, ignite karaoke talks. We should try to get one that is, uh, every single like windows, like, uh, field background image and just see what people, uh, make with that. And then the last one could just be like Clippy just sitting there. And you got to tie it all together with Clippy, you know, that's going to be for Microsoft. Bob or whatever. Yeah. See, you clip it together with Clippy. That's, that's, that's how that works out. Or you could have that. Remember that little dog they had? That was, that was, yeah. Can I help you with a new resume? Like, yes, you can dog. Thank you. Well, I mean, there's a whole lot more, uh, talks that are out there and then, and it's, it's pretty easy to go look them up. If you just go to SpringOne platform.io. Um, and, uh, I think are these all the ones that have been announced or there's some that still haven't been announced yet. Yeah. Good question. We've got a last batch that are going to be going online soon. We're actually pretty early. A lot of shows don't put the whole agenda online until a couple of weeks before, but we wanted to give people a chance to plan. So yeah, the whole agenda will be online in the, in the coming week or so, and then get your ticket booked and hotel booked and it really should be a pretty wild four days. Yeah. Yeah. We'll have some good Maryland crabs, all sorts of things. I hope. And, uh, if you're interested, all of us have discount codes, but if you want to get $2 off, uh, $2, $200 off, see the monetary conversion. It's got my mind clunking here, but if you want to get $200 off the ticket, I'll put this in the show notes as well, but you can use the code S one P 200 underscore Coté. That's my name, C O T E. And, uh, as I'm fond of saying, I think if, if I, if I people uses a few times, I might get a fancy pin. Now this might be the same pin that you get in your gift bag, but

I'm going to think that it was a reward for all of my effort in getting people to register. So yeah, if you're interested in all this, just go to SpringOne platform.io and you can check out all the other sessions. Uh, you know, there's all sorts of fun pictures of people. You should find the one picture where the guy has drawn some sort of a dinosaur spikes around his eye. That's a, that's a good one. You don't see that too often. Uh, and, and with that, this has been another episode of Pivotal Conversations. If you want to find all the, uh, the archives and the, uh, the shows find an RSS feed you can subscribe to. You can go to soundcloud.com slash Pivotal Conversations with no space or anything, just one word. Um, and you know, you can also search around whatever podcast listener you're looking for. And every Thursday, usually, uh, I put the full show notes. We keep mentioning over on pivotal.io slash podcast. And with that, we'll see everyone next time. Bye. The dog was perfect. Perfect. Perfect. Just right. That's right.

Tanzu Talk · 🍕 Get more pizza.