Platform as a product, cloud native education, and 2020 predictions, with Paula Kennedy

Episode 158 · 50:37 · SRT · archive.org · all Tanzu Talk

Well, uh, today, you know, when, when, when the holidays roll around, you gotta, you gotta queue up some episodes. So today for you, the listener is in the past much further than it usually is. Uh, maybe what you could do is you can use some context clues and try to figure out what day we recorded on. Um, I don't, not really sure how that would happen. Did either of you have that book in maybe like the late eighties that was like a bunch of illustrated pictures. And it would, if you solve the puzzle, it would tell you like where there was like a million dollars in gold buried somewhere. Did you ever see that book? I don't know. I think your parents are playing a trick on you. That's right. Mysteriously, I dug all these holes in the, uh, in the shape of the new fence we needed to put in. I think you were aerating the lawn. I think that's what's actually happening. Aerating the lawn. Very nice. Uh, well, why don't you introduce yourself guest? Uh, we, we have, we have, we have someone on not only to talk about herself, but also to do a participate in a little bit of prediction type of stuff that we'll do at the end, but introduce yourself. Hi, my name is Paula Kennedy. I work at Pivotal alongside my lovely colleagues, Richard and Michael. So, um, I am the senior director for platform services and education for Pivotal in EMEA. So I'm based in London and I mostly worry about platform things and education things. Is that fun? It's a lot of fun. Yeah. It's a lot of fun. Yes. I love it. I have, uh, two teams and they're both filled with fantastic individuals and we have a lot of fun and we work with some great customers as well. And so I, I think, I think, uh, we on the podcast have talked about, have talked about platform stuff, uh, for a little bit and we'll, we'll get to that for sure. But like you recently started doing more education stuff, right? I mean, so what, what, uh, what, what does that mean around here? Exactly. It's interesting. So I, I've been doing the platform side of things at Pivotal since, well, maybe three

years now, two or three years and the education side, something I've not focused on, although arguably the services that the platform team does are education as well. So we're, we're very focused on enabling our customers to do things for themselves. And so whilst I have not focused on education, it's always been actually a kind of a by-product of the engagements we do. But more recently at the start of this year, I volunteered to take on extra work. I don't know what I was thinking, but I decided to dive into the education team that we have at Pivotal and really understand what those services look like and how we can help customers learn more, honestly. And it's been interesting for me because on our education side, we focus not just on platform education, but also application developer education, which is a new area that I've not thought too much about in the past, but it's been really interesting for me to get involved, to understand what we teach at Pivotal, how we teach it, what our customers want to learn, how they learn. So it's been, it's been a really interesting few months actually diving into that whole area. Yeah. I mean, kind of like you're, you're, you're saying that the, the services that we offer have a educational component in them in, in, in, in the sense of like, let's, let's do new things together. Uh, you know, a Pivotal person and a customer person, but, um, you know, I guess there's, there's always room for more explicit education than just, uh, working on things together, but it does make sense to have that, uh, that you and the two teams would sort of, uh, be familiar with and know each other based on the way Pivotal functions. Yeah. And one of the things we've looked at a bit more this year is how we weave education more into our customer journeys. So we talk a lot at Pivotal about the customer's journey on how to get good at writing applications,

how to get good at running platforms and education is always part of it. But what we've, what I've tried to focus on a bit more this year is placing kind of short pieces of education along the journey. So if you're going to engage and do a, an application modernization project, for example, you might want to start with doing some spring training for developers. You might want to start with an overview. We have these platform acceleration labs, which really are intense, very hands-on training, but, um, teach a lot of things that developers might need before they're going into an app TX, an app transformation kind of engagement. And so trying to broaden out a program of services and make sure that customers get, get the knowledge that they need, that they can learn the theory and then straight ahead, go and do the practical. So I, I was, I was, uh, I was touring around the UK in a few cities with one of our customers recently, and they, they were all, you know, also doing an educational sort of roadshow. It wasn't like, um, they weren't to the point where they're doing like workshops, but, uh, you know, they were visiting on various sites and just kind of introducing people to the, uh, to the platform for the pivotal thing they had in place. And there was, there was a lot of questions about, uh, basically, I guess, doing cloud native apps. I, I don't, I, I always lose track of the exact phraseology, but you know, stuff that can run in containers and might be microservices enabled and all of that. And so like, do y'all get involved in doing sort of like workshops like that, you know, kind of for customers and going around and setting those up and running them? Uh, yes, it's a, it's a combined effort. So it's not just, um, my education team, for example, that would be involved in that. We, we have lots of different people in pivotal doing similar work. So we join a program together. So for example, if you're, if you're a new customer to pivotal, you might start with some workshops from our platform architecture team.

You might come in and look at a specific application and how to break it down into microservices. We do lots of beginner workshops on our website. We've got lots of content about, you know, things to think about and, um, reference material. So as a starting point, you might use some of those materials. Then you might want to engage on an app modernization program with pivotal. And we, again, we have a team that goes in and actually does, um, reviews of architecture and recommendations about which applications would make sense to kind of move straight into the cloud, which ones need refactoring, which ones should remain where they are for the time being. Like we, we have a whole suite of services that are tailored for precisely what the customer needs. And then on the education side, if, if the decision is made to refactor an application, then it could be that this pivotal acceleration lab that we do could offer those developers really a way of like brushing up their skills, understanding the concepts, really understanding the theory before the next thing they dive into is doing the work. Yeah. I like, I like, I like that idea of like, uh, staging out educational moments. Absolutely. What's, what's, what's the word we use with kids. It's a, it's a learning moment. I've forgotten the phrase. Like it's a, it's a teachable moment. Yes, exactly. Well, it's kind of, you know, it's interesting, Paula, unique here. Cause I spent some time the last few weeks looking through the public cloud providers training curriculum and kind of mainly their certifications and most of their certifications, not wrongly, but our, here's how you become, let's say an AWS certified engineer. And it's, here's how you use our services, how you learn Lambda or Azure does the same. Google does the same. So it's very much like, how do you build things with our stuff? So what I thought was interesting as you described this and what I've looked at, what we've been doing is we're still teaching, I think some general purpose things that have nothing to do with pivotal platform. I have nothing to do with Bosch or cloud foundry, or even Kubernetes in some cases, it's learn boot, learn how you modernize an app, learn.net.

So, I mean, that, that feels kind of unique. I would, I would think, you know, the cloud version isn't wrong and you need to be experts in many of those technologies to use them. Right. But have you noticed when you work with customers and you start to think of those teachable moments that you're not trying to start up front with how do I immediately embed myself in this one environment's nuances and kind of sharp edges, but just how do I learn better programming? Yeah, it's, it's interesting. We, we are seeing demand from customers. Sadly, we had some audio issues, but here Paula fixed back up talking about what she sees out there. I just want to know how, how I should approach product management as an example. So last week we actually ran an experiment here in London where we offered a product management workshop for two days and we invited multiple attendees from different customers to come along. So previously we've run this workshop as a specific for one customer and we go to the customer site and we take a bunch of those product managers, typically application product managers and run a specific course for the customer. But last week in London, we ran a public class and anyone could come. And we ended up with a mixture of platform product managers and application product managers in one cohort for two days. And the, the, the material that we were teaching wasn't particularly product specific. It was much more about, well, what is agile and what is lean and, and how do I prioritize user needs and what are the features of writing good user stories? And so the skills we were teaching last week were not product specific, but they are critical for our customers. And we, we, we think about them a lot when we're talking about platform as a product, which is another thing I talk about a lot, but the product mindset is so important that for us teaching customers, those skills is just fundamental. Do you find that counter-cultural right now? Cause it seems like we've, as in, you know, maybe vendors were all at fault here, but that

we were almost training enterprises even specifically to almost pick their tech stack before they've figured out their problem. Like, you know, this is going to be Lambda or it's going to be in containers. Now what are we building? And it's just kind of almost backwards, like choose the infrastructure first versus infrastructure and deployments, almost the late binding choice. Like it's the last thing you do. So it seems like we've kind of flipped. So is you and the team trying to focus on lean and product management and core programming patterns and architecture, you feel like you're swimming upstream in the enterprise, but they're like, well, just show me how to use MongoDB. Show me how I should, you know, deploy this to Kubernetes. Or do you find it's a receptive audience that says, no, we need these fundamentals about just defining products and building good architectures. And then we'll figure out how this gets deployed and run. I think we're, we're certainly seeing more, I'm seeing more demand for that more kind of generic methodology training than ever before. And the most recent one we've had seemingly quite a lot of demand for is, uh, extreme programming workshops. So we have an, an introduction to XP workshop, again, that we've run ad hoc for customers as they've requested it, but we're starting to see demand, more demand for that. Um, and I think it's, it's partly a by-product of the fact that we're, we're going into customers almost assuming that everyone knows the stuff that we know. And it turns out that's not always the case. And so therefore when, when we expect a customer who's going on a big journey with us, for example, and really wanting to be all in on pivotal platform, they want everything running on, on the application service or the container service, and they want to do things like we do them because they know it's going to drive their success. Turns out that they, they, they understand that they need those other learnings as well. They can't just learn the technology. They have to learn the methodologies. They have to understand that product mindset. And so it's, it's, we're starting to see more demand for sure, which is great. It is great that, uh, those fundamentals you mentioned. So I tweeted something last week as someone wrote, just a really good introduction to like

software architecture. My, my comment was, you know, I've seen people talk about this at conferences too, that we have to go back to basics sometimes because we just get so obsessed with, oh my gosh, here's this latest thing that you can't even use yet. It's on some experimental branch, but this is crazy. Meanwhile, people are just like, can you under, can I, can you describe like even just basic 12 factor apps? Cause I don't really get that. So is there something that is an industry we're assuming is common knowledge that isn't right now, especially as you go talk to enterprises and they go, Hey, Hey, can you back up a little bit? Cause we're not even, we're not at this step yet. Not cause we're not dumb. It's just, we get in our bubble and we think everyone's further along. It's so interesting. I had this conversation today with someone in my team. We were talking about, um, Kubernetes, obviously it's like the, the word that just, that we talk about all the time. Right. And, um, it feels sometimes in our echo chamber, everybody knows what Kubernetes is and everybody wants it. And it's the, it's the thing to have. Um, but I had a recent experience where I hosted a hackathon in the London pivotal office and it was the NASA space apps hackathon. So it was very interesting. It was open to the public. We had a 48 hour hackathon and it was a complete cross section of individuals that came into the office. We've probably had 60 to 70 attendees of all different backgrounds. Some were students, some were enterprise, some were startup, some were developers, some designers, product managers, like a complete real cross section of the tech industry. And so I stood up and did my five minute pivotal pitch, uh, which was fun. And then I talked about Kubernetes. We, very briefly, I had my, my VMware Tanzu t-shirt on with the Kubernetes logo on the back. So I turned around and I was like, and you know, if you're like Kubernetes, come work at Pivotal. Um, and then I asked the question to the audience, who's actually heard of Kubernetes? And out of 60 attendees, I think two put their hand up to which I was like, Oh, sometimes I forget that we're in this, this world where Kubernetes is the thing that everyone's talking

about every single day. And actually there's like huge swathes of people that have never heard of it and don't care about it. And it's just an implementation detail somewhere off in the background. And it surprised me and, and gave me a little reality check that just because, uh, we think it's like top of mind for everybody doesn't mean it is. Well, on that topic and something you mentioned earlier. So also the other, the other area, uh, you're involved in is the, the, the platform operations or platform as a product or platform as a platform, uh, area. I don't know. We were discussing what the, you know, various names for it, uh, a while ago. I don't know if we came up with platform as a platform, that, that would be fun. Uh, but, uh, so, so what is, uh, what, what does that team do? So my other team, the platform services team, I think is what we like to be called. Now we, we help customers, uh, figure out how to run their platform basically. And we, it's, it's an interesting thing. I've been talking about it a lot and it's a, a similar problem where I sometimes forget myself that just because it feels like I've been talking about this for a long time and other people I know have been talking about this platform as a product for a long time. It, it doesn't mean that it's, um, well understood within our customers or in the, in the kind of the broader market, like, um, essentially to try to summarize what it is. Uh, we think about the platform as being kind of the foundation within your, your company within enterprise to run your applications on top of, and as the people running that platform, the platform team, your customers, therefore are those developers who want to deploy the applications onto your platform. And so what we typically see is what we've seen in the past, let's say is companies will, will buy a pivotal platform.

They'll form a project team to install the platform and then it's installed and then it's done. And there's, there's not really a sense of the fact that the platform should be an ongoing product. It needs to meet developer needs. It needs to continuously evolve. It needs to have, um, kind of outreach to the developers to make them excited to use the platform. Basically it's everything we think about for, if you are launching a product, we want to have that same mindset for internal platforms. Yeah. The, the way that, you know, the thing that I find interesting about it, well, there's many things, but one, one thing in particular is that product part where there's a, I don't know, you have basically a product manager or you have multiple people who are, um, product managing it, which, which, uh, you know, I don't think people in operations think about product managing too, too much. It's they, I, I don't know. I mean, you tell, tell me what you encounter, but I think the, when, when I've talked about it with people, the thing that I, I encounter is they still have, uh, or not still most everyone has a service delivery mentality, kind of like what you were describing, right? Like we set up this project and deliver a service. And then like, if you want to change it, let's start another project, but it's not, it's almost, and I feel like this must be unfair, but it's almost like there's not this proactive, uh, gardening of the set of features that the infrastructure might have that you would see, see in a product. But, um, I don't know, what, what do you, what do you encounter when you sort of introduce this idea of like, Hey, you need a product manager or many of them? Like how does that conversation go with people? It's not the easiest conversation, honestly. Um, and, and, and I, and I can understand it. I mean, if I put myself in the shoes of a, someone who's been sysadmin for years or running the infrastructure part of an organization, it is a change in mindset and change is hard.

Change is always hard, but for those people that, that embrace it, those are the customers we see the most success with. And it's a difficult thing. I sometimes have, again, remind myself that just because I know it works and I know it works because I've seen it work, it, it's hard for people who haven't seen it to actually believe it. I remember going into a customer and an early customer of Pivotal, uh, and having this conversation and we, we tried lots of different experiments with our customer. We ran a product management workshop, we introduced, um, people who were running products in other parts of Pivotal to do kind of lunch and learn topics for the customer. We really, really went in with them and trying to position this product mindset. And in the early days, one of the, uh, platform operators gave me feedback that said, this is all well and good, but it sounds like marketing nonsense to which I was like, yeah, well, let's just, let's just suspend disbelief. Let's just plow on. Um, and actually that's now one of our most successful customers in Europe, honestly. Um, but it is tough. It is a tough conversation. And especially when, uh, typically within an organization, those people with the skills aren't in those teams. So a typical infrastructure team doesn't have product managers or they don't have people that have come from that background. So we see, uh, people who get given the job title of product manager who might be project managers or, or system administrators, or just the most senior engineer on the team. And so trying to teach the skills of how to manage a product is, is a challenge. That's where education can, can really help actually. Yeah, it's, it's like you were discussing earlier. There's, uh, there's always an interest in general topics, the general topic there being just product management. What does that look like? And, and I guess, I guess that it, I mean, that's, that's a good example of, of what,

what you and Richard were talking about earlier, where it's, uh, uh, I think, especially if you work at a software vendor, like you kind of, you at least have a halfway decent knowledge of what a product manager does and is, and, you know, cause it's become a huge part of creating software, but, uh, yeah, I mean, I think, I think if you don't work at a vendor, it's probably, uh, a strange role that you've only maybe heard about before. Yeah. I mean, what's the, then what's the need, Paula? I mean, cause someone may look at this and go, that sounds cool, but man, like we heard it SpringOne, right. When Schaefer talked about the change, you actually have to have a need. There has to be something that really triggers you. So you walk into a company and say, platform is product and they go, that's marketing or that seems goofy. What, what is their pain point that would say, shoot, we'll give it a try. What do you see over and over? One of the biggest challenges that we see is competing priorities. So, um, if I give you an example, you have a platform team, customers spent some money to buy a new platform. It doesn't matter really what it is, whether it's application servers, Kubernetes, new platforms come in. This is the answer to solve the enterprise problems. This is it. This is the one thing that's going to fix everything. So the platform team are responsible to build, configure, start the running, even if they're going to hand over running to some other team, but there's, there's a effort to get the platform installed. And then typically, I mean, hopefully, but also typically within an organization, you've then got all these different teams who've all got applications that wants to move onto the new shiny platform. So then for the platform team, one of the biggest challenges we see over and over again is how to prioritize, which, which things do they start with? If everybody's shouting, which, which is the first service that they should implement? Which database should they use? Which messaging service should they use? If there's a hundred apps within an organization and each one is using a different thing, how does the platform team drive the standardization?

How does the platform team know which thing is the most important thing? A product, what one, one pain a product manager could help solve for is precisely that it's acting as a heat shield between the platform team and all of this noise around them. So actually filter out all the noise, allow the platform team to focus on getting things done and actually prioritizing the list of things that are coming in and being able to give status back out again. It's like a, a, a kind of a wrapper around that platform team that can just increase their efficiency and increase communication back out to the business. Yeah, that's good. So I was, uh, I watched the video of you and Colin at SpringOne talking platform is, I'd say it was research for this podcast, but I'm not that good. I was actually preparing a Pluralsight course and that video popped up for me. I'm like, I should watch this. Um, one of the breakdowns you did in your talk was talking about the personas that make up a platform team. So humanize this for us a little bit. So what are the, the major roles that form these sort of product teams that run a platform and what kind of skills do you need in those to be successful? So we normally talk about, um, in a, in a sort of the smallest, the smallest possible configuration. Ideally, you're going to have at least two platform engineers and a product manager. So I mentioned already one of the, one of the activities a product manager does is helps prioritize the backlog, helps, um, shield the platform team for the platform engineers. Some of the things that we look for, I was thinking about this, like, what's a, what's a key skill to be on the platform engineering team? Um, and then I thought, well, is laziness a skill? Like one of the things, one of the things that someone in my team described is you want platform engineers who really hate manual toil. They really hate those repetitive tasks and they will do anything they can to just automate the toil away, which comes back to kind of a, a site reliability engineering practice from

Google. But you want to automate as much as possible. You want to reduce kind of like manual intervention and effort. Um, you actually also want to look for folks who are quite curious. We talk about like engineers being curious of really wanting to, um, add the next thing, do the next thing, make the platform as, as good as it can be. We ask the questions to the developers about what they actually need. Um, and the team doesn't have to be, like I said, it doesn't have to be particularly big. Actually, it, it can start small with just two, uh, a pivotal. We talk again about extreme programming. So we like to have pairs of people who compare together for us. That's really important for kind of sharing knowledge, um, and producing very high quality code. When you've got two people working together. Um, and then as your team grows, you might bring in specialists, kind of, kind of people in the team with slightly different skills. You might have someone who's got more, um, software development skills, who's really going to be focusing on, on doing more and more coding on the platform, adding more and more things. You might have someone who's more focused on infrastructure side, but you, you want to have a balanced team and a balanced skillset within that group that then means that platform team is just highly efficient and running extremely well. Yeah, that's good. So I want to run digital ads. It says, if you're lazy and curious, apply here. Like just see what kind of candidates we get. I like it. Yeah. Yeah. Yeah. Yeah. I think that there probably is a word that, uh, in a, uh, uh, judgmentally positive way, uh, encapsulates that laziness. Uh, you're, you're efficient is efficiency laziness. I'm never really sure. Or, or, uh, more efficiently use your time. It's like, yeah. Have y'all ever seen that cartoon where there's like, there's like two tigers watching, a human jogging. And one of them is like, why, why is he jogging? He's not chasing any food. He needs to conserve his energy for when he's chasing food, which, uh, you know, much more

efficient to not jog. I think that was in your treasure hunting coloring book, but that's right. That was the back pages. That explains my, uh, my, my attitude or lack thereof when it comes to exercise. I learned from the tigers at a, at a young age from the tigers. Yeah. That's your autobiography title. When I've got to run to a FIBO and pick up a burger. Uh, so yeah, uh, the, the, uh, the, the, the, the last question I had on this topic and then, and then we'll do our, our, uh, our prediction stuff. But, um, so like, like part of the platform is that like you're running stuff in it, uh, and running people's applications. And I think like what, when, when I've sort of lost track and I think most everyone has of like where, like when it comes to DevOps, like where the lines are drawn, which I guess ironically is the point of it. So that's why you would lose track. Um, but presumably there's some sort of set of like production level operations. The platform team does versus like some set of production-y type of stuff that the product teams, the developers do. And like, what are, what are, how do, how are people never, never minding the ideal state of things? Like, what do people actually do? Like, like, are, are there, are there actual like product teams who are like solving production issues or is it more just like this theoretic thing that they would be, you know, carrying a pager for their apps in production? That's a good question. So there's what we, there's the ideal state that we would love to see happen, which I should describe, um, is where application teams have kind of as much autonomy as they need. They've got self-service access to the portal for their platform. So therefore issues come up, they can fix them themselves. They're running their apps. They're, um, writing the apps.

It's DevOps in a, in a nutshell. Um, but we don't. We don't always see that. Um, I mean, I'm working with a customer. It's going to sound very snarky, but I was, I'm working with a customer at the moment where we were talking about DevOps. What's the definition of DevOps? Um, and this customer said, well, I have a DevOps team, but that's excellent. Excellent. What do they do? Well, uh, actually what, what happens is the DevOps team are the engineers who install the platform, but there's a whole other team. Um, the ops team who run the platform. So I said, well, that's, that's interesting because that sounds a little bit like you've got a dev team to do the building and then you have an ops team that do the running. So it sounds a little bit like dev and then ops. It doesn't really sound like DevOps. Right. Right. Which I looking back was a little bit not kind. Actually, uh, I wasn't, I wasn't fulfilling my, my pivotal values very well when I tried, but I tried, I tried to say it kindly. I wasn't trying to be sarcastic, but, um, it's a thing that we see a lot. It's still the case that you've got, you've got people building and people running and DevOps isn't really happening at least at the platform level. I think it's better at application level. I hope it is, but it's, it's not, um, the ideal state is not, it's not running everywhere. I hope that, uh, I hope that interaction had a lot of awkward pauses because I just think of a British comedy with you doing that. I was really trying to be very kind. I really was. It was just difficult. Did that work? Like, do you feel like you were talking them through to a point where they realized that like maybe, maybe they had separated that? Like, do you think that that helped at all walking them down that path? I think it, it highlighted the issues that that customer currently has, but I don't think

yet we have reached the place of being able to help them change it. It's a very difficult thing. Um, you know, big customers have ingrained practices and ingrained compliance and reasons for the way things are. And it's, it's not just a technology problem to solve. It's not just as easy as saying, well, now you're going to have one big team and they're all going to do everything. Um, and sometimes it feels like I was thinking about the quote where they say the future's here. It's just not evenly distributed. I think that's true for practices as well. It feels like for some of our customers who are able to like really, really kind of change their practices and follow a DevOps methodology. That's where we see the success for other customers. It's just very difficult, very difficult to change. And so I'm trying my newest resolution. Let's think about the future. My newest resolution, have a bit more empathy for our big, big customers and how hard some of these things really are. That seems fair. I think, uh, you know, the, the, the main thing being hard, like the, is the, uh, I don't know, uh, to, to, to return to a snarky level. It's sort of like people often forget that like, you know, transformation requires doing things differently. And, and so it's, uh, it's important to sort of make sure that you're trying to figure out what things you should be doing differently and how you should be doing them. Otherwise, you know, no need to suffer through all that change remain the same and not do anything, uh, if, if everything's going well, but, uh, all right. Well, those are, those are good overviews. And, and, you know, like we were saying, it makes sense how those are, uh, intertwined together. It's a, it does seem like fun to answer the question at the top, but now we should, since it's the end of the year, we should have our predictions. We had a new year's resolution, which is good. More, more empathy. I haven't even started thinking of my new year's resolutions. Uh, resolution, such a, for, you know, foreboding word, like it sounds like some law that you're going to pass somewhere. Maybe it should just be like, you know, a new year's try.

New year's suggestion. Yeah. Yeah. Or, or it should more, maybe what to use another, uh, old word, you know, just like a resolution. It should be a petition, you know, in the sense that like, this is, this is an idea that I have. If only the monarch would look at it, just imagine all these people with paper standing outside the hallway trying to petition and, uh, maybe one of them gets through anyways. Uh, yeah, but you know, it's fun to do predictions and, uh, we, we, we've, we've each come up with a few of our own, but why don't, why don't you start off with one Paula? We'll put you on the spot. Okie dokie. Uh, so when I was thinking about predictions, um, I've been thinking about it over the weekend and, um, I, I, I kind of went a bit big, honestly, in my predictions, my predictions were, were not kind of, were not focused on like the day to day. I was trying to think about like, in an ideal world, what would 2020 look like? And, um, the first thing that came to my mind was, was really the focus on climate change. So I was thinking about 2019 and how much we've seen on, you know, um, like activism and we've seen like more awareness of just how things are in the world right now. And if we don't do something drastic, it feels like we're not going to be around much longer. Honestly, the world won't be around much longer. And so my prediction and more my hope, honestly, is that we will see 2020 as the year where more technology is used to solve our climate change problems that we're facing. That's my hope. Yeah. All right. You're going to also have to do your second one. Cause I'm not following that with something about the tech space. So yeah, you're doing, you're doing two predictions up front, Paula. Ah, fine. Okie dokie. So my, my second one, these are all much more hopes and wishes than the, uh, uh, practical

applications for technology. I think, I think that's the secret. That's the secret of all predictions is really, it's just like things you want to happen. Well, unless you're a real downer of a person and you're like, oh, I don't know, world will end. Oh no, mine are very optimistic, right? So like I say, I hope that technology is going to save the world. That's the first one. Nice. Uh, my second one is more in the kind of ethics space. So again, it's felt a little bit like, I don't know if it's just me, but it feels like 2019 has just, it's just, there's been a lot of bad news. There's been an awful lot of stories of like companies doing bad things, whether it's the employees doing bad things or companies signing up for contracts to do bad things. It's just felt a bit sad and awful at times. I mean, maybe that's because I spend all my time on Twitter actually, which is, can be a dark place, can be a dark place at the best of times. Um, but my hope, my hope for 2020 is that we see a rise in ethics in technology. I hope that we see more companies pledging, making ethical pledges or, um, choosing to do things like, uh, consequence scanning, which is the thing I've, I'm starting to read up about recently, um, understanding that technology can be used for good and can be used for bad. And we have to try to, as technologists, we have to try to do good, honestly. And so I'm hopeful that maybe 2020 is the year we see more good than bad. So, so what's, uh, what's consequence scanning? Well, yeah, I like the term. So it's interesting, right? There was, uh, there was a very specific example this year where we saw, um, Seth Vargo, who, uh, I think used to work for chef.

He had some open source code and then it was being used in a way that he didn't, uh, ever intend it to be used. And so he pulled it from GitHub and so, um, or from open source completely so that people couldn't use it anymore. And so it's where, um, you build something, take facial recognition as an example, right? You might have very, very positive intentions for why you want to build facial recognition software. Maybe you want to make it easier for people to log into their phone, for example, but then it turns out that governments can use it to track people and can use it to start building databases of people. And there's unintended consequences for the technology that you've built that had you known about them in the first place, maybe you wouldn't have built that technology. And so consequence scanning is a, is a framework. Um, it was actually created by, uh, an organization in the UK called dot everyone, which is a non-profit organization and it's a, it's a way of trying to just ask a few questions of the code that you're writing or the thing that you're building. If, if some evil mastermind was to get hold of this and use it for bad, what's the worst thing that they could do, for example, and just try to put an ethical framework around what you're doing, why you're doing it and asking some, some basic questions. So I quite like it. It's something I, I, like I said, I hope to see more, more ethical considerations being thought about in, in 2020. Yeah. I think it's fascinating when the cat gets out the bag though, that if you're years into said technology, then all of a sudden there's a certain implication of trying to pull it back when it's being used in all kinds of good and bad ways. So if you try to harm the bad way, you're going to impact the good way. And I wonder if next year you see companies not doing business with companies that do have a strong activist point of view because you worry that, well, maybe they'll pull this technology in a few years with a eager employee.

It's like, it's a very inter intermingled conversation we're having right now, which is fascinating because things that can be used for good can be used for bad. And those definitions of good and bad are different. So it's such a fascinating way where you can't step back and just say, well, let's see what happens. But at the same time, there's a lot of real implications of pulling things offline or taking source code away or things like that. There's a blast radius. It's hard to calculate now. Absolutely. And it's interesting around, I've seen a lot of discussion online about open source licensing and how you could somehow have a license that, as you mentioned, like only would allow your technology to be used the way it was intended. And if it's used in a different way that you as the creator don't agree with, could you refuse to give someone access to the source code? It's, um, it's not an easy area actually, but I, I think the more, at least people think about it, like that, that's, that's the only hope I have. Like, I don't think there's an easy answer, but, um, if we all, if we all had good intentions, it would be, it would be good. No, good. Those are two good ones. All right. So what do I have that's, uh, not remotely as meaningful? Sorry. I just did a very big picture. Yeah. Good Lord. Paula goes third next time. Uh, no, I mean the one, now that I'm thinking more negatively, I think that we're going to hit a, uh, call it the trough of disillusionment, whoever's, whatever analyst says that term on things like microservices, Kubernetes, some of these things that are now, we're finally in year two or three of probably being deployed at big places, right? Like we're not first year kicking the tires on these things. Now, as you said, that could partially be our bubble because plenty of people are still brand new on this, but it seems like for a decent number of companies, we're far enough along now where maybe now you start hitting scale challenges, skill challenges. Everything feels more fragmented. The open source explosion is amazing and all this choice, but all of a sudden now the complexity is, is getting pretty intense. I just wonder if we're going to hit a point mid year or sometime next year where people

are back to like, Hey, modular monoliths. And Hey, you know, back to platforms that have a higher level abstraction because all these primitives while powerful have this such a more tricky configuration and monitoring surface and security surface. And maybe we don't all need these raw primitives to build our own stuff. We really should figure out something like Zite, something like what we have with Paz, something like all these Heroku, these other things that still simplify things. So I mean, you're always going to want the primitives. I just wonder if there's going to be a little bit of a whiplash back to something that hides more of the complexity because now people are going to start hitting a scale point where that complexity emerges again. Yeah. You know, like for the listeners trying to place when this was recorded game or dig some fence posts in the backyard, you know, like there was a, there was reinvent last week and it like every time there's a, that laundry list of things that are available, plus everyone else's laundry list. I always think like, man, I'm glad I'm on this, this, this side of, of the technology sort of usage, because like, if not that I'd have to like know all this stuff and like evaluate it all and figure it out. So there, there is like, it's almost like there's too much stuff too frequently to sort of get a handle on, which I think, you know, on the one hand it's a lot of work to decide what to use, but I think that also has kind of a slowing down effect that you, you enter analysis paralysis of just like looking at everything and evaluating it. And then you go back to just doing things the old way because, because you know, you know it works, but yeah, it's a, there's a lot of stuff out there. And so, you know, there could even be the, I don't, I don't think the, uh, the hype cycle or the, uh, well, I forget what that's based on, but there should also be, there should be something before, uh, something between inflated expectations and trough of, uh, like disillusionment, which is like, you know, I don't know, oatmeal bowl of overwhelmingness of just like, there's, there's just too much stuff and, and, uh, you can't get this disillusioned if you think there's all this other stuff fogging up your vision, but I don't think that stuff standardized.

Yeah. That stuff's not going to go away. I mean, Steven O'Grady wrote my, my favorite summary of re-invent. He just had some really thoughtful points in there. One of them is that look, Amazon, I think actively resists the sort of integrated solution approach. They just build a lot of primitives partially because that's how their org is set up. Partially that's what their customers ask for. So they, you know, I was expecting it reinvent some more of these integrated experiences kind of hide me from more of the muck, roll these things up and they didn't do it. And I don't know if they ever really will, or if their thing is just, that's not what they offer. And so for some people, look, those primitives are going to keep growing like crazy because people love them, but it still seems like that opens up a slot in the market for people who say, maybe there's a lot of people out there who really don't want to stitch it all together and you're going to want both, right? I don't think either one wins, but I think you will potentially see a return to things that are just helping me focus back. As we first started talking about, help me just build good stuff and make all the infrastructure the last thing I get to decide. I don't know. I personally think we're going to move more back towards that. All right. Do you have another one, Richard? Yeah. The last one I'll put in, I added a couple of mine together, was back to the explosion of everything space. It feels like we're going to see some of these database vendors join forces next year, potentially acquisitions. Same with APM, which is seemingly harder to be differentiated among all these different monitoring logging observability vendors. It seems like it's harder and harder for all of them to differentiate a little bit. So I wouldn't be surprised to see a number of those get picked up or consolidated just because is there that much differentiation there among all these different databases, all these APM vendors? I wouldn't be surprised to see the cloud vendors pick some up or a couple of them to join forces. Well, you know, definitely there needs to be some acquisitions in the APM market because the way that market operates from my being in it and observing it for the past 25 years is there's a team of people who do some revolutionary. I guess it's not revolutionary. They do some innovation and then they have a good company that gets acquired and then they quit that company and start another company which gets acquired and they start another company. But I think that original set of people from Wiley is probably getting close to retirement.

So we need to get a new little core team together that's going to go through all these companies and continually reinvent and evolve APM monitoring, which is always fun. Yeah. Well, I'll just go over one, which I think is related. So I was asked to do a predictions thing a while ago, which made me think we should do one here. But I was, and also like those people I was talking with recently and other things related to what we were saying. Yeah, there's just like, I think there's a lot of people who would just be kicking off their modernization programs. And the reason I think about that is a lot of the questions that one of the blocker questions I get very frequently when I'm talking with people out and about is like, well, what about if there's this one team who doesn't ever do anything, right? And therefore it's this backing service that they control and we depend on that service and it's not really evolving as quickly as we need to do. And it's not always like a mainframe team. I mean, sometimes that's, you know, it's actually kind of a minority of the case that it's someone there. But there's inevitably in, if I haven't used all the time talking and there's actually some questions, like one of the questions will basically be like, how do I motivate other people, other teams to do stuff? And part of that do, and that doing stuff is like, you know, you don't just want them to do stuff because you enjoy watching motion. I guess that could be a reason, but you want them to actually change something you depend on or like provide access to something. Like it could be something as simple as like, we need to, uh, use the inventory system to know which store a thing is in and getting that is difficult. So it's, it's made me think a lot over the past several months that really like there's a huge amount of modernization efforts that, uh, that need to be going on. And so I was, I was looking up some figures of, of like how much there is. And, you know, there's all sorts of various things like that. But one of the, I think a good rule of someone is that Gardner had one last year that basically

like 70% of most people's budget is spent on legacy applications, which makes sense, right? To keep them up and running. And there's a lot more legacy applications than new applications by definition. But I think, I think what's important about that is just realizing that the bulk of all these things, uh, exist out here and they need to be updated and changed. And, and indeed, I think, uh, I see little hints and pieces of that, especially in talking with people about platform stuff. So I think, I think that'll be a big topic and what we'll see people doing a, uh, a lot of in, in next year. Now, you know, and, and I think, I think the other driver for that is like, I, I think everyone's decided that Kubernetes is what they should be running. And, you know, then you got to select a distro or whatever and, you know, get it up and running. But like, as, as we were kind of talking about earlier, pretty soon what you're going to encounter is like, Ooh, we got this cool new infrastructure running. And now we need to make it so our applications can run on it, uh, which is basically modernization. So in moving things over, you'll have to, uh, fix them up. And hopefully, hopefully my life insurance company will do this. Cause you know, it's the end of the year, you got to pay your premium and, and my life insurance company, I don't know if y'all have seen this, but it's does that thing where like, it's got a shiny new UI. And then you actually click on some things and it goes back to this really old UI. So they've got like a hybrid, uh, hybrid transformation happening. And, and most comically, uh, I, you know, they're, I'm sure they're a fine company. I won't name them, but most commonly they just added this, this past few months, this feature to do auto pay out of your banking account, instead of having to fill out a PDF and upload it to them to, uh, authorize auto payments. So, uh, way to modernize. I think there's a lot of that to, uh, to, to work on over the next few years. And then, and then, and then in, in, uh, in the vein of Paula's like, uh, predictions are just wishes. I was thinking earlier, I really liked that iPad mini. I don't know if you've ever used one of those. I used to have one, but they have one that only works with the old Apple pencil. So I keep thinking I should buy an iPad mini, but then, you know, when you buy a new computer thing, you want to make sure it's, uh, you got, uh, forward compatibility.

So like, I'm hoping I'm predicting they're going to come out with an iPad mini that works with the new Apple pencil and not just the old one. So I will feel much better about buying this mini one. Cause that one will actually like fit in a jacket pocket and, uh, various small places. And, uh, it's much easier to hold if you're like reading a book as I did. Do you, do you, do either of you have dedicated Kindle devices or like ebook devices? I have a Kindle. What's, what's the, what's the theory of operations of that? Why don't you just use like your phone or an iPad? Like what, uh, Oh, well, my phone is too small and I don't have an iPad. Oh, there you go. I'm a Paula's, you know, American doppelganger then. Cause that's what's what I have. I mean, that's the same thing. I don't read on my phone and yeah, I don't have a tablet. I like my Kindle. I can take it everywhere. I love my Kindle. 30 something books a year on it. It's just easier to carry that around. Yeah. Yeah. All right. I tried out one of those paper whites at the airport and I still, the refresh thing on it still bugs me. Like whenever you turn a page, like, I don't know, I read on my phone. So I must be the weird one. That'd be fun to see what the divide is. Well, thanks for being on Paula. I think. Thank you for having me. I've had so much fun. We'll see what happens over the next year. I think, uh, I think all our predictions will come true except the bad ones. You have to go through the trough of disillusionment to emerge at the plateau or product. That's right. That'll be fine. Even that's a good one. Uh, well, as always, this has been a Pivotal Conversations. If you want to get the, uh, the back catalog, the wonderful multi-year back catalog of, uh, of this podcast, you can go to soundcloud.com slash Pivotal Conversations. And, uh, usually every Thursday we post the full show notes, uh, at pivotal.io slash podcast. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.