PCF Data Services and hipster coffee scouting, with Ben Laplanche (Ep. 74)

Episode 60 · 49:54 · SRT · archive.org · all Tanzu Talk

Hey there! I wanted to tell you about a new podcast we got going over here at Pivotal. It's called That Moment. Don't get confused like I was initially. It's not the moment. It's called That Moment. That Moment explores the pivot that changes everything, moments that open doors for discovery and growth, but also brings the looming possibility of failure. Each show features different leaders and innovators sharing their stories and taking risks in business life. It's, you know, classic Pivotal stories. Also, it's fancy with all the cross-fading music and optimized editing. It's really some good pro stuff. So if you're interested in those kind of stories about how people are wangling their way through all this digital transformation, DevOps, cloud-native stuff, go subscribe to That Moment wherever you get your podcast. But, you know, for your weekly dose of unprofessional old-school podcast rambling, let's get on with the show. Well, Richard, this morning, you know, my daughter is not sleeping through the night despite sleeping on one of those very comfortable internet mattresses, which you'll see how this gets in. I later took a nap on that. But she gets up at the night and, I don't know, she's afraid of ghosts or something. I don't know where this comes from. There's no ghosts. I guess she hasn't learned science yet, but it's only about four. And anyways, I couldn't go back to sleep. It was like 2.30 a.m. So the question I have for you, well, one, I'm assuming that you're not some sort of superhuman and that you can actually go back to sleep 100% of the time. I'm assuming maybe you've got like two nines on go-to-sleep ability as the SLA. But when you can't go back to sleep, what do you do? How do you spend your time? Yeah, I usually get up because I just can't stand staring there. And then I start thinking about things to do. So sometimes you quick put on the TV downstairs or I'll do a little work and hope to get sleepy, which never works. And then I'm just up the whole time. Yeah? Yeah. Are you a big TV person? You know, late-night infomercials. I'm sure you probably have a whole sleeve of Ginsu knives. Yeah. Or maybe a juicer. Do you have any of those green fry pans from the dump lady? Is she still advertising?

Yeah, no. You know, actually, I haven't bought any late-night things before. So I'm only joking from non-experience. But, you know, those things are compelling. By the end, you're ready to lose weight and cut shoes with a knife. Oh, cut shoes with a knife. That's my favorite. How about yourself, guest? What do you do when you can't get back to sleep and you really should get back to sleep? I find the cold side of the pillow and just reflecting on the day. Oh, man. Cold side of the pillow. You know, if you're ever going to write a memoir, you need to put that in there somewhere. Chapter 32, cold side of the pillow. That would be good. Well, why don't you introduce yourself briefly, guest? Hey, so I'm Ben LaPlanche. I work for Pivotal, one of the directors on the product management team and based in London. Indeed. So what did you guys have for breakfast this morning? They're bringing breakfast, right? Yeah. It's actually kind of American. Had some, like, kind of breakfast burritos. It's kind of good. It reminded me of the Cloud Foundry Summit, actually. Yeah. Now, did they have the white tortillas on there or were they going with some sort of rainbow tortilla? Did you have, like, wheat? No. Spinach? No, it was the white ones. Oh, solid. Solid. Sausage in there. Man, that's old school. That's genuine right there. I like it. Yeah. I like that you consider burritos American. It's whatever you always seem to have in the office whenever I come out to San Francisco or to Cloud Foundry Summit. There's breakfast burritos. Yeah. Well, I mean, you know, to your point, Richard, little known fact, the burrito was originated in Turin in the late 1300s, I think. Isn't that true? Hence burrito. I don't know. No. Yeah. Come from the containers. Stay for the burrito knowledge. That's this podcast. Yeah. Well, speaking of burrito knowledge, we'll have, you know, we have been on to talk about some exciting stuff here in the second half. But we've got a little spate of news. As I've been saying recently, we're, well, I think tomorrow we will officially, by, you know, science, be entering August.

Would you say that calendar stuff is science or is that more social? I don't know. I guess it's derived from science. Yeah, there's a map. I guess it's science too. Sure. You know, I had someone correct me this week and I was, they were talking about some sort of addition thing and I was like, oh, math is hard. And then they were like, you mean arithmetic. I was like, whoa, I'm sorry. Yeah. You seem like a lot of fun. I was told no math vocabulary was going to be involved, but, uh, but yeah, so, uh, this is a little bit of news here. Some good stuff. I mean, I think, uh, I think last week, all the, all the big, I think finally all the big cloud providers have, have announced their news and, and, uh, you know, uh, it looks like Google announced a bunch of, uh, how would I characterize it? Uh, they, they sort of announced some momentum in larger accounts. Like what was the ad to go back and read this three times, but that there was, uh, they had three times the number of cloud deals over half a million dollars than they did last quarter, I think, or then they did ones underneath it, which I, um, as always, I haven't installed the, um, the Monte Carlo pack for Excel. So I'm not really sure how to figure out what that means, but it sounds like there's some, uh, big cloud momentum deals they have. Yeah. I mean, you know, Amazon got grief when a few years ago when they kept lumping AWS at the other bucket. Like it could, this could be anything. And now Google and even Microsoft, I guess Microsoft's better now, but still cloud is very chunky for them. We'll stick office 365 in there though. It's hard to pull out what we all think of as cloud from that same with IBM. IBM says they, you know, are doing bigger business than Amazon now on cloud. I, it just depends on your math, I guess, going back to what are you including in that number? But at least you're including some numbers in Google. This is also an other bucket. So it seems like cloud is doing well. That's great. But I think we'll look forward to all of these companies being a little more transparent there. And, you know, I think at this point, like at least just speaking for myself, the thing that I monitor is, uh, ongoing evidence of the theory of the, uh, we were talking about this last episode about the, the public cloud Cerebus being formed.

I think, I think, you know, and making sure that, uh, that the theory that it's basically Amazon Azure and Google as the, the dominant public cloud people, and maybe hybrid hybrid's a fun new word nowadays, uh, or I shouldn't say new it's returned sort of like, uh, you ever notice bell bottoms never came back, but you know, I guess, I guess I've noticed that like, uh, mom pants have come back. So anyways, uh, it's, it's good to get further input about, uh, if, if those, if those three are going to be the, the leaders by, I suppose revenue, which I'm not sure how else you would, you would do it. And, uh, this, this is certainly in the positive side of that. Yeah, I think this one will touch on our third news point. Cause I think these things are related, but the, uh, the second one was, you know, I was just looking for other interesting things last week. Everybody's, you know, it's summertime people still shipping software. So Microsoft shipped a new container service, kind of pay by the second, just deploy a container and you can still bring your own scheduler. And I guess you're getting, you're seeing the cloud companies continue to offer different models of compute. So it's a neat service for Microsoft. It's fine. It's fairly basic, but again, it's always about trying to make the on-ramp easier. And so it was, uh, just caught my eye. Yeah. Yeah, definitely. And, and then, and then, uh, and then also I think, uh, Microsoft joined the container service people. That's right. We're offering that now. Now, how, how, how, how would you two describe what a container service is? I think I was, as I was reading over that, I was realizing that I haven't really seen, there's been a lot of, are we supposed to call serverless Jeff now? Or is that too much of an inside joke that there's, there's been a lot of coverage of what like Jeff is. And then I suppose we have an assumption of what, uh, traditional public cloud is. Right. But I haven't really seen a lot of discussion of like, this is what container service means other than it's right there in the name. So like, how, how would, how would y'all two like characterize what a container service is versus other things? Yeah. I mean, I think in essence, Ben, I'll, I'll be interested in your take too, but I mean, for the most part, just like, you know, I want to run a VM, I want to run a function.

I want to run an application, which is traditional paths. This is, I have a container, which again, a container kind of has a bit of OS virtualization, has an application stack potentially embedded and now go run it for me. And that could be a few hundred bags. It could be a few gigs depending on how you build it and almost just like a virtual machine, at least in terms of how it's run by the service, you know, you run this thing for me. Now, if I want to do more advanced stuff, I have to bring in a scheduler or something else that runs these things. If I look at Google container engine, you know, that thing's meant to be a full on scheduler that you run your containers on. In this Microsoft case, it's, Hey, just run a container and it has a public IP. That's cool. And pay by the second. Maybe I put my web app in there. Maybe I put a data service in there for some weird reason. So, you know, it's take my container and run it for me. It's all just different levels of abstraction. Yeah, that's interesting. I try and reason about the value that it would give me and I land on something like it's compute as an API because I guess that's what you're really getting out there is you've got different flexibilities and the types of compute that you need. So, yeah, I find that quite interesting to think about it that way. Yeah. I mean, do y'all think it's fair just to, I mean, take it on face value of like, well, traditional cloud is VMs as a service and this is containers as a service, right? It just like runs a different type of packaging of things and there's not really anything more exotic than that. Yeah, I mean, there's this kind of ongoing debate of what is the atomic unit of compute? Is it a container? Is it a function? Is it like, what is the thing? So, yes, it could be a whole VM. It could be, again, just an application like you deploy to Heroku or Cloud Foundry. It could be just a container. I don't think there's one answer. Like, there's an evolution. We all end up using containers versus VMs versus functions. It seems like there's always going to be a continuum, at least for our illustrious careers. Yeah, no, that's good. I always like the answer that is basically, don't overthink it. It's just running this thing. Nothing more crazy. So then always, I think you and I, Richard, always enjoy a good survey.

You know, you get to see if people spell out percent or put the percentage in there. That's always nice. You reverse engineer their copybook. But I had noticed this one, but you found a fun little snippet covering one. What's in this one? Yeah, you had another survey, but showed that I think what jumped out at me is so many companies still saying that not only a small percentage of their workloads are in public cloud, but not that they're not going, they're just not going as fast as I think we might have anticipated a few years ago. And the same two reasons pop up more and more. It's sort of lock-in and security. And security is such a remarkably vague thing to complain about because it can be authentication or data encryption or all kinds of different things. But to the earlier thing we talked about with earnings, I half wonder if one of the reasons lock-in has become even more of a concern is now there's multiple viable choices. So you do feel like, gosh, do I want to bet on a horse when there's a lot of different choices here in the public cloud? It's not like Amazon or bust. I'm like, well, I'll just lock into Amazon because there's nothing else and that's the best. Now I've got three, maybe four or five legitimate choices out there. Is that screwing people up in terms of their planning? I don't know, but it seems like lock-in and security are still keeping people from going all in. That is interesting. I mean, if anything, it'll, on the buyer's side, maybe elongate your sales process because you feel the need to go talk to all these different people. But that is, huh, that is great. Yeah. I don't know if there's a paradox of choice thing there. That's all. Like when you have one choice, you just pick the cloud and you stay on-prem and you don't overthink it to that. But now when I have, again, three and you count IBM and maybe a couple others as legit choices, is that just slowing me down to your point, maybe making it harder to buy. And at the same time, I choose to kind of just spread my workloads around, which is good news for Pivotal because that's part of our value proposition. But it's interesting to see the industry validate that as well. Yeah. It's like, you know, I started making this thing that's basically, I don't know what it's called, but it's kind of like a, it's like a lasagna except with a bunch of squash and eggplant. And I think it's, it's got some fancy name to it. It's not a Ratatouille, but it's something else. And like, you go, you go to buy the 24 ounce can of, uh, I don't know how many grams that

is of whole tomatoes. And it's just like, it's very confusing. Lots of different tomatoes in the can options. It's, it almost makes you not want to make this thing. They get the paradox of tomato choice, but you know, I, I think, I think with these things, it's always good to add in some context. And, uh, so I, I was remembering that my old, uh, uh, job, uh, over at four or five, one research, they own this company called the uptime Institute. And they did, they'd done a survey earlier that found similar things. I mean, over a thousand data center people. And, uh, I think it was, they, they reported the reverse, like the one, the survey you had, it was like, uh, uh, man, talk about a Monte Carlo simulation, more than 65% of respondents reported that less than 20% of their workloads, uh, you know, and then I wouldn't get a good score on the SAT after that. Uh, but it said that of this thousand or so people that, uh, four or five, one surveyed about 65% of their oddly enough, same number, uh, uh, asked workloads remained in basically private cloud, whether it was co-load or, or, uh, things like that. But I think, I think that does match that's, that's, uh, as always the tempered expectations, uh, that I tend to have is that in the, um, enterprise space, if you will, that things are a lot slower as far as all of the workloads, it'd be interesting to have a cut based on brand new applications, which usually is much, much higher as far as running in public cloud. Uh, but all of the workloads tend to be, uh, meandering about kind of like, you ever read that book about the, the guy, the guy who gets an apple and walks around the village and the apple changes hands all the time, sort of like the slow, uh, slow movement of the apple. I should look that one up. It's delightful. Sounds filthy. Yeah, that's good. I mean, I'm not eating that apple at the end. Oh yeah. I never thought of that angle, but yeah. Yeah. So that's for my germaphobe model, my ideas. Uh, I mean, also to that, uh, trying to rewind somehow back from fruit, uh, you wonder that with some of those numbers in the private cloud, you, you see that that's why Amazon, that's why all these providers have started to begin to do this hybrid story, this migration story

of snowball. You have all these data movement tools because they realize you just can't sell cloud first. You have to sell some way to connect these two things. And I don't know if that was the realization five, six, eight years ago when all this was really bursting up, but now it seems like that's got to be the play is how am I getting you there more easily? Yeah. Yeah. We'll have to see. But anyway, those, uh, ongoing surveys there always interesting to see. Well, so Ben, why don't you introduce yourself more thoroughly? What do you, uh, what do you do around here? You know, what, uh, when you're not enjoying the, the bounty of the, the, the Western U.S. cuisine, what, uh, what do you spend your time on? Nice. Uh, so, uh, pivotal, I'm responsible for the, uh, the data products that we've got integrated with the, uh, the cloud foundry platform. Um, so that's pretty cool. I'm based in London, got some teams here, got some teams kind of in New York and San Francisco as well. So a bit of variety, get to do a bit of traveling around and hanging out with different customers. Um, when I'm not working on the wonderful world, there's data services, kind of enjoy a bit of cooking, mainly Indian cuisine, or if I'm out and about trying to find the next hipster coffee shop. So, uh, that's always fun when I get to visit San Francisco and New York. So if you've got any recommendations, let me know. Now, now we'll get to the tech stuff soon, but to stick to this theme of randomness that I've introduced, how, what is like the criteria? What, what, what flips the bit of hipster coffee shop? If I can go into a coffee shop and ask for a piccolo and not get a strange look, then I know I'm onto a winner. Okay. And now of course this begs the question, what, what, other than a flute, what is a piccolo? So piccolo is a, it's an espresso based coffee where you have the same amount of foamed milk as you do espresso. So you've got like a one-to-one relation ratio. So it's great if you like the flavor of espresso and you like drinking coffee, not just for kind of the caffeine kick, but also to enjoy it. Now, it's not so big that you feel ill afterwards. Now, just to clarify, is it a piccolo or a piccolo? Piccolo. Piccolo. Now, how, how, and I'm sorry, we'll get out of this quickly, but how do you, how, how,

how is that distinguished from a cappuccino and a cortado? Cortada? Yeah. So I think cortado is probably the closest. To be honest, I think a lot of coffee shops, they're almost kind of interchangeable. Cappuccino, in my mind, would be a lot bigger. So there's a lot more milk. You've got kind of your, your different layers of milk in there and your chocolate sprinkles on top. So it's a good drink, but just not my preference. Okay. So a cappuccino is kind of like a nod to a milkshake as, as like a piccolo. Piccolo is more like, maybe more like a kombucha. It's sort of like this hardcore thing. It's not intended to be anything reminiscent of, of pleasurable unless you're into that kind of thing. I don't know. I like it. I'll see how, I'll see how that works. Piccolo. I'm going to start ordering that. All right. That's good. I'm too much of a rube to apparently go out for food with either Ben or David Brooks or anyone because I don't know these food choices. That's good to know. Hey, it's interstitial mid-roll stuff. I just wanted to promote a few upcoming pivotal things here. Through June, July, and August, we have the Cloud Native Roadshow coming to all sorts of cities. This is a free day-long event we do with Google that goes over what exactly Cloud Native is and how our customers are using pivotal and Google technologies and approaches. The cities, and this is a long list, so get ready. The cities are Stuttgart, Dallas, Denver, LA, Seattle, San Francisco, Amsterdam, Seoul, Hong Kong, Sydney, and Singapore. There's a big list of dates that you can look at. You can check out the show notes for a link to it. Or if you just want to go and Google for Pivotal Cloud Native Roadshow, you'll find it pretty easily. We also have Spring Days Atlanta coming up July 18th and 19th. It's chock full of sessions for developers who want to learn more about the Spring Framework, Cloud Native style development. And of course, to be fully buzzword compliant, microservices. If you go to springdays.io, you can get more info. And that's the last Spring Days we're having so far that we have scheduled this year. So get that one in if you're over in Grits and Porkland. It'll be good stuff. Finally, while it's way in the future, we also have SpringOne platform coming up December 4th and 5th. Now, registration just opened recently for this.

I think you might have missed the early bird thing for it, but that's fine. There's also still the CFP open. It closes on September 1st. Now, what goes on at this conference? Well, it's full of what I would call the suit track and the technology track. In the suit track, you've got case studies and managers and developers as well, but organizations talking about how they've transformed their company and what they're doing with Cloud Native and their organizations, how they're getting good results by switching over to doing things in more of a pivotal way. But then there's also plenty of events for those of you out there who enjoy more nerding out and doing technical things to check out. I'm one of the chairs of the DevOps pipeline and monitoring track that we informally call it. We've already got lots of excellent talks queued up from the likes of Home Depot, Express Scripts, Allstate Northern Trust, and of course, plenty of pivotal people. I'll be speaking in that track if that's anything. So come on there. Again, it's in San Francisco, December 4th and 5th. And if you just go to springplatform.io, you can check it all out. And with that, enjoy the episode this week. All right. So yeah, so tech stuff. Ben, managed service data services. So you mentioned that we do the data services here, that you run them. And we've had some different ones over the time, over the year. So I mean, specifically, what data services, and sometimes we refer to them as managed, do we offer? What does Pivotal offer in the box if you're a PCF customer? Yeah, so we've got four main products that we're focused on at the moment. So the first one is our Pivotal Cloud Cache product, which is based on Pivotal's GenFi product, or Geode, if you're looking at the open source distribution. We've also got RabbitMQ, so the popular open source messaging system. We have a MySQL product. And lastly, we've got Redis integration as well. You mentioned interesting words there in terms of like the managed data services. I think when people first hear managed, they think typically kind of outsourced. You've got another team kind of outside your building who's running those for you.

That's not what we're referring to here. We're talking about kind of platform-managed data services. So kind of think of Bosch. Bosch is almost human, and that's what we're talking about here when we mean managed data services. So what does management entail then? So what are we doing on behalf? So if I'm just a, you know, you listed four very popular open source things. So, hey, I'm a good technologist. I can stand up MySQL. I can deploy a Rabbit container. That's not hard work necessarily. So what is this adding to that? Why would I use this? Sure. So we're using Bosch, the technology underneath, the same technology we use to deploy Cloud Foundry. And what that really gives us is that kind of infrastructure portability. Almost gives us that kind of platform as code mentality. So we get all of the benefits of Bosch, where it's really strong around things such as day two. So our ability to kind of roll out updates to these services, our ability to pass to patch the stem cells to the underlying operating system. All of that flexibility is really powerful for us. And it allows us to then bake in the rest of the day two stuff that you would expect, such as the ability to upgrade without losing data, the ability to do things like rolling upgrades. All of that we get from basing it around kind of a Bosch deployment. And these are all super critical value-add activities. But that's not necessarily where the value is for your customers. So we want to make sure that these activities are done in a reliable and repeatable way. And that's where all of the stuff that people have come to know and love from Cloud Foundry itself, we're trying to bring the same operational mindset to the data services as well. Yes. I mean, you touched on kind of the build and run phase then. So we're saying really the value is, again, when I've used these, I can use CF create service and then build out these things. The idea is that it's very repeatable to build. And I'm not asking different teams to set up credentials or what the right proper settings

are for clustering for certain cases that we're provisioning at all. But then the runtime too, right? Because Bosch takes care of it. If that node happens to fall over, Bosch can resurrect it and bring it back online. So again, that management is meant to be no touch, right? Yeah. Yeah, absolutely. So you touch on some of the powerful things there, such as the recovery. Absolutely. And that goes up the stack for us from things like the process monitoring that Bosch gives us through Monit, like you say, all the way up to kind of the Resurrector if the VMs go away. That's really powerful. You touched on one of my favorite features there around the CF create service as well. That is where I believe the value is. And we want to enable that self-service mentality for the application developers. So if we can provide that as a service and allow customers to focus there, and we bring the rest of this stuff to the party for them, that's, I think, a real differentiator. And so, I mean, just as from the top instead of going from the bottom with stuff. So when you look at across all those services that you're managing in there, like what do you think the more popular ones are? Like what are people using out there of the ones, that little clutch that you're working on? So RabbitMQ is a really popular product. We see a lot of people using this, especially as they're adopting kind of microservices mindset. If you look at a lot of our Spring examples and documentation, even things like Spring Cloud Services, Spring Cloud Dataflow, example applications, they've all got Rabbit integrations. So there's a really strong groundswell there, which is really cool to see. We find that messaging in general is quite popular of enterprises, but they're used to a different type of technology and almost a different mindset. So you can have some really interesting conversations of people there around how they can take some of those concepts of kind of asynchronous messaging and bring it to microservices and then backing that with things like RabbitMQ on the platform and combining that with the other pieces we have. That I find to be a really compelling story.

The pencil cloud cache, that's one that's really resonating with customers at the moment as well, talking about where it's appropriate to use caching in your application. Again, it's one of those things that a lot of people are familiar with and already using kind of in their enterprise or platform kind of stacks, but really helping them rethink where you can use it and how you can be a bit more self-service with that. Again, layering it on with the other tools in your box, such as RabbitMQ or maybe a bit of MySQL, you can start to build up more of a relevant architecture. And so when you're running these managed services, like what's the expectation of, well, I don't know. Let me ask this a different way. In the traditional world, you might have a DBA who runs your database. And in this sort of world, whether it's like the queues that you have or various data stores, like how are things in practice? Like do you have dedicated people who are babysitting those or not? Or like how does that all kind of fit in as far as staffing? Sure. Yeah, that's a really interesting question. Can I paint you my vision? Yeah. And what we're seeing with customers? And then you can see how different customers kind of level up in that. I think this early in the week, it's all vision until we meet the practicality of trying to wrap up at the end of the week. So let's go for it. This is a piccolo-fueled vision. So you're familiar with kind of the balance team concepts, right? Of course. Where you want to have that team that's got all of the skills and responsibilities in there. And when you start layering on the whole, you build it, you run it, you learn from it mentality, that really gives that sense of empowerment. And to me, that's how you, as well as all of the agile kind of lean techniques that you get and product management, et cetera, there's a lot of things in there that allow you to kind of move fast. So if you started the question with saying, how does that compare to how enterprise is using these things at the moment? And the favorite customers to go and talk to are the ones that have really adopted and

embraced the concept of CF push and having these balanced teams. And they're absolutely flying along. They're doing all this good lean stuff. It's all very user-centered and they're knocking features out and everybody's having a great time. And then you start looking at where the friction is in that process. And it typically tends to be around all of their off-platform integrations. So things like, we wanted to start this new project. We knocked out the basic API. We mocked up kind of the iOS kind of UI and all that kind of design flow in a week. And then it took us a month to get access to a database. Right. And that's because of the usual organizational kind of boundary silos, all of the things that we're kind of used to. I'm sure you've covered in depth on here before. So my vision is that when you take a lot of the transformational stuff and learnings that we've done with application teams in general and start applying that to data, you can take the same patterns and achieve a really powerful outcome. So the dream is that in those balanced teams, the app developers now also have perhaps a DBA hanging out in there who can help up-level and kind of pair, if you're into that kind of thing with all the application developers and teaching them not just how to use MySQL, but how to optimally use it. And ideally do a lot of the data operations themselves as well, such as determining when appropriate is to scale versus actually go and kind of rewrite that query, for example. And that to me just continues to round out that balanced team concept. Now, I think you still end up with what we kind of refer to as the data specialist, which might be a smaller team of DBAs that are more central, who are kind of keeping their lights on and looking across all of the many MySQL instances out there. But the goal is to make their job as amazing as possible with all of the platform tooling so that, again, they can continue to focus on the value-add activities that those balanced teams are trying to hit. Yeah, you know, this is an interesting accidental topic here. I mean, this function comes up a lot.

And it seems to me in the balanced team world, the, well, we need a phrase for whatever this interloping tech expert person is, right? Because it's sort of like, in theory, it's sort of handy to say, like, we could take another topic like security. You should just have a security person there. But there's probably like kind of a consultative role where whether it's a sort of like a data sort of expert or, or a security person or someone who just kind of like has perhaps a residency, you know, a temporary residency in there to, to, I don't know, I don't know, it's a combination of like advising and training about doing these things. And, and to get meta, I like to think about this as kind of the set of responsibilities that that team needs, because if that's a new team, or perhaps it's a really advanced use case for social security or the data products, then you might bring in that kind of SME or that domain expert. But over time, I think, and again, in the balanced team concept, the goal would be to kind of up level everybody else and share those responsibilities around and kind of teach everybody the relevant skills that you need to. Right. No, I like that. I think that's a, you see a lot more of that, even with ops teams, again, not that ops goes away either, but some of the activities you'd have to do, maybe that low level work gets automated a bit. Now your higher level expertise actually comes in handy. So it's, yeah, it's fun to talk about that. One of the other things, you know, I think that's interesting, maybe related to this is recently we, we shipped this sort of on demand broker. Our team built that at Pivotal and then we've open sourced it as well. How does that change the game from this idea of having maybe single shared clusters that everybody uses and manages to this sort of, hey, you know, you get a cache and you get a database and you get a cache and everybody can stand up their own instance of things. How did that kind of change things? And I guess summarize for folks what the on-demand broker is. Yeah, sure. So the on-demand broker is the CF create service command that Richard mentioned earlier. That allows an app developer when they run that command to basically self-service provision

their own Bosch deployment or dedicated instance, as we refer to it, of one of those services. So that means they've now got kind of tenancy isolation at the resource level. So their own set of VMs, for example. And back to the kind of the pre-provisioned multi-tenancy world. What we really found there was that looks quite similar to the way a lot of these customers are operating today in terms of having a centrally managed and run, say, big database, for example. And that works fine when you know the constraints, that you know all of the applications that are going to be on there and that you know all of the kind of constraints around uptime, for example. And you're happy with having a slower moving, more change control kind of pace. And of course, there's also issues in there around kind of noisy neighbors and kind of people accidentally overrunning the cluster. So that didn't really kind of fit with the flow that we want to encourage app developers and back to the balanced teams concept to be working in. We really wanted to get people into more of this flexible mindset. One of the things I love about hanging out with Pivotal Labs developers is you hear them talk a lot about choosing the right tool for the job. So the on-demand broker is something that allows us to do that. So if you've got two different application teams at a customer and they both need MySQL, then they can go into the Cloud Foundry marketplace and choose the service plan that is relevant for them. And because of the power of the platform, the on-demand broker and Bosch, they can get stamped out in the different kind of VM sizes or different MySQL configurations are needed for them. And by doing that and decentralizing some of that, it really allows the app developers to move a bit faster. They can iterate faster, which means they can focus on the business value. And of course, you've removed a lot of the concerns around accidentally stepping on each other's toes, for example. Is there a cost to that, though? I mean, besides licensing, I guess. But I mean, this idea of having this sort of just now explosion of instances, if you will.

Now, operationally, I think we talk about the story of these are Bosch managed. So the incremental cost of adding another database is near zero. But is there a sort of cost of kind of can we accidentally switch too quickly to this model of maybe slower moving but centrally managed clusters to kind of per microservice databases, caches, even messaging? I don't know. Where do you see that spectrum? What would you have to look out for? Yeah, sure. It's interesting seeing different customers adopt this approach. And if you find a customer who's taking kind of their big classic monolith and breaking that down, then the challenge there is to start to find the seams in that as you're defining the APIs for the different parts of the service and identifying which of those could be split out into their own kind of databases or messaging systems. And for the customers I spend time hanging out with at the moment, you find that some of them have always still got a connection to their big legacy off-platform database. And that's fine because that's relevant for that part of that application. It's got different types of constraints. So you can end up with a bit of a mix there. In terms of the cost, I mean, aside from the resource cost that you get here, you do inherently get a bit more of a kind of more of a collection of MySQL instances associated with that application. I think that comes back to the balanced team again, and they're being responsible for running these. And you've got to view that cost in kind of respect to the value that it's really unlocking for them as well in terms of their ability to be a bit more flexible here. That makes sense. One of the, you know, as you have so many of the choices you talked about here with databases within our platform. But then if you look at the market, I mean, Cloud Foundry offers tons of stuff, right? I can use DynamoDB in Amazon. Obviously, I can use Cosmos in Azure. I can use all sorts of things in multiple databases, plus bring in great ecosystem things like Cassandra and others. So how am I supposed to really choose, if I'm a developer, between the cloud provider's

native database, right? I'm going to use Dynamo, I'm going to use RDS, or I'm going to use just kind of a standalone outside instance that I just do a lightweight broker to that I manage outside the platform, or then actually a Bosch-managed service. Now, maybe you touched on it there that there's going to be, you know, the answer is always it depends. I get that. But, you know, in some cases, you may have that line of business database that shouldn't go anywhere. But then you have a more lightweight microservice that now defines some new data entity. And that thing should have its own database. It's kind of, where do you choose, you know, how do you pick the spectrum? How do you decide to go native with the cloud provider versus saying, look, I know I'm running on Amazon, but I'm still going to use the PCF MySQL service because I like to have the same abstraction on every cloud. What are your thoughts on how you make those selections? Yeah, sure. So I think you could start this conversation with a couple of different angles. I mean, if you go at it from the app developer angle, and we just focus on the tool that they're choosing, say a SQL offering versus a no SQL offering, then I think that depends on the app developers actually understanding the different kind of pros and cons of choosing those technologies and making the most responsible decision in terms of which one they choose. If you think about the services API contracts, which is one of the most powerful things in Cloud Foundry, I think, that powers the Cloud Foundry marketplace, then actually the app developer shouldn't care or even know where that database has been provisioned. And that, I think, is really powerful because if you've, say, got a MySQL offering that is powered by the Pivotal offering and, say, a NoSQL offering like DynamoDB that's actually on Amazon, they can both appear in the marketplace side by side. And the app developer can choose them and they get the same kind of CF create service, CF bind service experience. Now, from the operator's perspective, the teams that are really offering this platform as a product internally, I think they're the ones that can then make that decision around whether it's appropriate just to expose all of the RDS offerings or perhaps mix and match.

Some of the criteria that I've seen customers choose there is around kind of whether they care about cloud lock-in or whether they care about portability. Sometimes it comes down to skill set as well. Like MySQL is a technology that's been around for a long time. A lot of our customers have got highly skilled employees and DBAs are really adept at running these things. So they'll tend to lean towards some of the more Bosch-managed stuff where they can be freed up a bit to go and work more with app developers but still retain some of the control. So there's a few different criteria there. Does that answer your question? It does. Yeah, I mean, it seems like in a lot of cases, if there's a differentiating reason to use a native cloud service, do that. Either that's for operational purposes or functionality. Otherwise, it can be helpful to have that same sort of portable option everywhere I go, especially if it's managed. I'm not really signing up for a lot of operational headaches. So that was good. Absolutely. And where you see customers running kind of PCFs across different infrastructures as well, then we've got customers who are using the same RabbitMQ products, the same MySQL one across both of those infrastructures as well. So just get that consistency of experience, both the operator and the app developer as well. You know, something that if you've been with a Pivotal customer for a while, you know, we've talked to you about HA and high availability of data solutions and what to think about in those and the kind of products we offer. Are they clustered? Are they single instance? How do I do cross-region? How do I do cross-site? Like there's a lot of considerations now and things like Gemfire work across regions. So there's things to factor in there and certain relational databases, you can set some things up. But how do you think, because I know you have some good opinions on this. So how do you think about HA with managed services like these? Are there any changes to how I traditionally design, you know, that clustered solution? Do I, are there certain criteria that maybe I don't, shouldn't put the same weight on? Kind of what's a modern approach to thinking of HA with data solutions? Yeah, sure. So this is one of my favorite conversations to have with customers.

One of the things that we often start with is talking about the definition and trying to get that shared understanding of what high availability means to people. Because often high availability is conflated with clustering or having redundant components such as lead a follower. Whereas actually high availability is a behavior. So if you look at the classic definition, it's actually talking about what's your tolerance to uptime. It's like how many nines does your application need? And that's really interesting. Because clustering and redundant architectures, things like that, are a great way of helping you achieve a higher degree of uptime. But there are also different considerations and different implementations that you can choose, as you were kind of alluding to there. So when I have this conversation and we get that shared understanding, I like to then try and tease the problem apart and understand what people's expectations are. I find that in the world of kind of a monolithic kind of application connected to an off-platform database, that these things end up with really high SLAs. And that's because people don't change them. So you want to impose some kind of strict contracts. But also there's like really specialist teams that are running these things and forcing you to go a bit slower. If you think about a lot of the concepts that we talk about in the cloud, and particularly with microservices, in terms of you should expect failure and design for it, and you should be building resiliency into your application and kind of your architecture as a whole. And then combining that with, okay, I've got my microservices architecture, I understand the different kind of domain areas inside that. You can then start to get a bit more granular about it. And that's really interesting, because you can almost end up with different levels of uptime per part of your microservice. So that then translates into me for having this shared responsibility between the application team and also the database team on deciding where it is the right place to build in some of this resiliency and choose the right redundancy in terms of components.

Yeah, because you know firsthand there's complexity in setting up a highly available relational database, right? I mean, it's different even than these sort of consensus-based systems or NoSQL ones. So I think to your point there is that sometimes easier, not easier, but there's a trade-off to say, look, I'll make some sacrifices on the data tier because I can introduce caching or I can do asynchronous messaging or I can do some other things that protect me against maybe a database blip that prevent me from over-architecting the data tier. And maybe this is the same question, I'm just having another run at you. But like, so when you are like negotiating the SLAs, so to speak, or I don't know if they're SLOs, I need to go back and read my SRE stuff because I've forgotten what an SLO way, you know, whatever EOL like music stuff. Anyways, like what are the like tools you have in the toolbox, right? Like when it comes to, I mean, just pick one of the managed services or something, but it's sort of like, well, if you want one more nine, we're going to have to build a data center. Or is it that straightforward? Is it sort of like, you know, like you meet with someone to fix your kitchen and they're like, well, if you want granite countertops, we're going to have to do this. And you're like, oh, hey, buddy, I'll take the linoleum then, right? But like, is there sort of like a set set of things that are sort of on the table if you want more resiliency and HA and things like that? Or is it just sort of like, you know, crazy town? Each project is different. I think each project is different, but there's definitely some commonality that you can bring to it. And if you've designed your microservices to be independent, again, by all of the practices that we'd expect people to, then you should be able to reason about those pieces independently. So if you then want to select something like a MySQL leader follower offering off the shelf, that's fantastic. If there is a small window of opportunity where perhaps the deployment's happening and the nodes are changing roles, for example, then, of course, you can start layering on other pieces on top, such as caching for the most kind of critical parts to that application.

Or maybe even thinking about how you can fail gracefully with inside your application so that you can continue to read, but your rights are just kind of stacked up somewhere else to the side. And this is where I like to think about it in terms of responsibility. Like the whole microservices, you must be this tall to go on the ride mentality kind of applies here as well. That as an app developer, you could push everything down to the data tier if you wanted. So offloads that responsibility to somebody else, perhaps going back to a centralized team model. Or you could meet in the middle and use more of one of these more flexible architectures. Or at the far extreme, we've got some customers who are looking at some really interesting things around the way that they actually architect their application. So using things like event sourcing and CQRS, for example, to really give them a really powerful architecture there, which allows them to use really simple data stores, such as single node MySQLs or single node Redisys, for example. And in an attempt to comically, brutally summarize it, like is getting resiliency in data more about like how many safety nets you want to deploy? Or is it something more basic like, well, this is just a better hard drive? I mean, I guess, or is that kind of the same sort of thing? Because as we're going over these things, it's sort of like, well, you want to add in this caching in case something goes wrong. And you want to add this thing in case something goes wrong. And it seems like in thinking through evaluating this stuff, like if you have the right kind of mentality of like, what we're talking about is how much money you want to spend on handling failure versus spending money on higher quality stuff. I don't know. I mean, is that is that anywhere near the right way to think about that? Uh, yeah, kind of. I mean, it's good enough for me then. I see where you're coming from. And I think I go back to what's the customer value. So if that balanced team is responsible for, say, a particular part of their application, then as well as really understanding their customers, they should also understand the business rules behind that.

So what does it mean if part of that application goes down? If you really understand that, then I think influences your architecture from kind of the top down, the top kind of being the customer behavior that you want to achieve. And if you end up with a kind of a NoSQL store behind the scenes for part of the microservice, because that's what you need in terms of the availability over consistency there, then that's fantastic. If you really need kind of strong consistency for another part on your SQL offering, then you might be better off with something like a leader follower setup and accept the small windows of downtime, a couple of minutes a week, for example, and architect your application to be able to code for that. Now, that makes sense. So it's not only like thinking about safety net things, but it's sort of there are there are well proven ways for your data not to get lost. Some of them have constraints they impose on your application. So what we should understand is like it goes back to that thing of like, how good do you really need this to be based on based on the constraints that are going to be imposed on you or the costs that you're going to be have you're going to have, which I don't know. I mean, at least to me is reminiscent of the old, the ancient sort of, I think it's scrum, I forget, but there's there's some scrum notion of like a, a story is just a reminder to have a conversation later, which, which is sort of a way of saying like, yeah, you should go talk to people and figure out what they actually need on these things instead of just blanketing, like, we have 100% availability, and that'll be $5 million, which sounds kind of nice. Yeah. And yeah, it really does. Although a little bit expensive. But again, if you go back, if you go back to the SRE model, like that's really cool of bringing that up, like when the teams then have to build these things, and they understand the kind of customer behavior they want to get to, and then they understand the complexity of choosing and pushing a lot of this stuff down into the data tier or kind of finding the right balance between the app and the data tier, then I think that firsthand experience as well will influence thinking.

Yeah, that makes sense. Well, good. I'm glad I could provide. This is the phrase that I'm going to use for I don't know what I'm talking about. So I'm playing the role of Caillou, if you remember that guy. But I'm glad I could play the role of straight man to people who know a lot more about it than I do. I think I think we're gonna have to update the list, Richard, in I think in order things I don't know about networking, security and data. So yeah, we got that. I think I think maybe the only thing I'm an expert on is pagination. So we could we could put that down there. But hey, thanks for being on. I think this is good stuff. And not only did we learn about how you should remember to have a conversation about negotiating thing, but I've got some new way to torment the baristas around Austin. That I can deploy out, which I think is always handy. And hey, if you ever need any consulting on burritos, or other Tex-Mex food, I my service is free of charge. Nice. If there were I think I'm kind of an ambassador for melted cheese plate food. I'll put that out there. But anyhow, if people want to follow up with you, or you know, follow you in Twitter, stuff like that, you got you got some deets to give them. Yeah, I am Ben underscore Laplanche on Twitter. Did you decide on the underscore or was the non underscore taken? It was so long ago, I set it up. I can't remember. I think somebody had already taken it. Yeah. And my favorite is when the underscore is the beginning. At least you didn't do the Laplanche like, yeah, or you do like the underscore and then like 2014 to recognize when you signed in, which now seems ridiculous. So I'm glad you didn't do that either. Yeah, those are good. I think I think it's I think it's maybe the generation before us, who's always putting dates like years into their login names. I don't know. That's my theory. We'll have to see if that pans out. Well, as always, thanks for listening. This has been Pivotal Conversations. If you want to find the back catalog of what we have, a little link to subscribe and this episode and a little arrangements we have, you can go to soundcloud.com slash Pivotal Conversations, no underscore in there, just just no spaces or anything.

Also, every Thursday, more or less, when we've met in our SLAs, or I don't know if it's an SLO, we post on pivotal.io slash podcast and we'll have the full show notes there. I went and looked up that that thing, that recipe I was trying to remember, where you can get overwhelmed by tomatoes. We'll put a link to that. And and also the coffee and other related things. And it's always great if you actually just if you haven't already just subscribed to this so it automatically gets downloaded and you'd be doing us a favor. If you tell people word of mouth about this or word of Twitter or even LinkedIn. I check in there every now and then. It's a very thriving community. But it's always nice to make sure that if you enjoy this program, other people you might know about will find it as well. We've got a program going, Richard. We're going old school with the vocab here. But with that, we'll see everyone next time. Bye bye.

Tanzu Talk · 🍕 Get more pizza.