So here we are at SpringOne Platform, the most awesome name conference ever, and I was catching up with someone. We'd been swapping stories about, what would you call it, kids' video games, ways of helping kids work on games. And then you were telling me about a project with Kubo that you were working on recently. So what was that project? Yeah, so we got approached by a prospect who basically wanted to set us a new challenge. You know, people already know that Cloud Foundry is a really good place to run Spring Boot applications. So the usual kind of, you know, well, we'll show you some microservices and we'll push them to Cloud Foundry and you'll be able to see how they work, just didn't really cut the mustard for that particular customer. So they set us a much more difficult challenge, which was, OK, so we've been into Sowa for quite a while. We've been doing, we built something that we call our integration fabric. We plug all of our legacy services into that. All of our sort of heritage systems are plugged into that. And this was a manufacturer that's been around for a long time. I mean, I would be guessing, but I would guess around a few years. So they had the typical, like, fabric, bus, whatever. The centralized, the network is the integration point or whatever it is. Not the network, but I just, I don't know. And they had all the... It's a bus fabric thing. All the usual middleware associated with that. Right, right. So they had an API gateway. They had an enterprise service bus. They have, you know, Sowa registries and all that sort of stuff. And their concern was, what do I do with all of these things, which are non-cloud native, heavyweight applications in this new sort of cloud world where I want to be able to use any cloud vendor that I want. Because currently they didn't have that freedom. They could, they had a lot of puppet and a lot of chef and various other things. So they could push these applications to maybe one or two IaaS vendors, but adding more or going to different regions like China or whatever it might be.
2:09And just standing up that stuff is a hassle because you have to, just the way that it has to be installed. Yeah, I mean, it's either, you know, installing it slowly or basically rewriting the installation of it to run on a new IaaS. So, you know, as they move from one region to another, maybe their preferred vendor isn't in that region and they still have to operate. So they asked us to show them multi-cloud and show running these historic heritage workloads on something that was multi-cloud. So we, we started to show them Kubo, which of course now is, is being integrated into a PKS and we used Kubo instead. So we, we brought up Kubernetes clusters and we created all the necessary scripting to push essentially these, these heavyweight ESBs and API gateways and that sort of thing onto this, this Kubernetes based infrastructure. infrastructure, which then because of Bosch is nicely multi-cloud. So you were able to essentially use Kubo at the time or, you know, PK, you were able to use Kubernetes as, as, shim is the wrong word, but a thing that you would put underneath the, this, this fabricry stuff to make it easier to install across multiple regions and things like that. So instead of having to rewrite those things or use something new, you just kind of added a, some packaging around it, a container, if you will. So it, so it, so it, so it, it essentially, it standardized the control plane, you know, Kubo CTL becomes your new kind of basic control plane for those, for those apps. So it, it, it, it gave us a multi-cloud, it gave us Bosch to manage those as well so that we could have, you know, again, a standardized control plane across how it's operated as well as how developers might interact with it. And it was a, it turned out to be quite a successful little project considering it was essentially proof of concept work.
4:11You know, we, we stood up a high availability cluster for an ESB, for example. The ESB that they had was WSO2, so. Right, right, okay. So, you know, most, a lot of people would be familiar with that. Yeah, so, so walk through what that was like. So you've got your, your WSO2 ESB, there it is. Like, we want to make it so that it's running on, on Kubo. Like, how do you, like, how long does that take and how do you start and what are the things that you have to architect around? Or do, like, what's that, what's that look like? Well, we thought that it would be quite difficult at first, you know. We figured there'd be quite a lot of work in it. But as it happens, WSO2 have already done quite a lot of work on dockerizing their containers, if you like. And also have done some work to integrate those with Kubernetes. So, so that you can do things like running a cluster using several Kubernetes pods. Okay, right, right, right. And it would know, for example, where the other nodes are in the cluster. So, so WSO2 has already done quite a lot of work on that. So, so we were fortunate, really. We got to be able to piggyback on the back of some of that stuff. So then it would seem like what you have to take. So they're already running the ESB outside of, you know, Kubernetes world. And so I guess you need to take the configuration and how everything's wired together. And somehow, and that's the main part of what you have to move over, I guess. Exactly, yeah. But, but at the same time, you know, not having to regenerate all that DIY sort of puppet and chef and, and actually push it and pave your IaaS and push it into the IaaS. Yeah, yeah. So it's a lot of time. So then, yeah, we could concentrate on moving the, the business logic, I guess you would call it. I mean, it's really, it's integration logic. Yeah, yeah, yeah. So it's, you know, this points to that and this sends messages there and all that kind of stuff. We were able to take that configuration and stand it up and show the customer, okay, you gave us these apps and you gave us these legacies, SOA definitions.
6:17We've wired it together exactly the same way as you currently have it. And we could show them and demonstrate to them the same thing that they're used to, but working in a completely new paradigm. And then the result, like you're saying, is you can run on, as they spread out to different regions, you can run on different infrastructure a lot more easily. Precisely. And then I would imagine there's like also just some raw management optimization, like abilities that you get. It's just easier to manage. Yeah. Because you've, you've, I keep using this word a lot because it's fun, but you've homogenized the sort of underlying, the layers of just monitoring and managing and updating and all of that. That's right. I mean, you know, as a customer, they'll be used to Bosch for PCF, but of course then they're managing the Kubernetes clusters via Bosch as well. So, right. So, they end up with kind of a standardized control plane for both legacy applications or, you know, middleware centric applications as well as the new sort of cloud native stuff. So, it was, it was quite an exciting project and we learned a lot about, about what it feels like to work with, with, with Kubernetes and it's sort of a hybrid between, we had some workloads on Cloud Foundry, we had some workloads on Kubernetes. So, we got a, you know, good exposure to mix in the two. Yeah. Like what do we call it now? The Pivotal Application Service? Is that right? The PaaS? Yeah. I never thought that it's sort of a pun on two A PaaS. Yeah, it's fewer A's. Yeah, yeah, yeah, yeah. We dropped an A somewhere. That almost aligns with Pivotal Culture. Not that many, so to speak, A's around. But anyways. The A bomb. But, so what is that like experience of, because that's one of the sort of promises, I guess, of having the PaaS, the Pivotal Application, classic build pack driven. Whatever, you know, Pivotal Cloud Foundry. And then you have your Kubernetes, your PKS run stuff over here and, you know, they should be able to work with each other and, you know, work with each other pretty effortlessly without knowing that they're different things.
8:25Yeah. And does that kind of pan out or what's that like? Well, we did learn lots of interesting things about that. So, so, so Kubo PKS can work in both an integrated fashion where you've integrated your Kubernetes through PKS with the PCF PaaS. Right, right, right, right. So, you can do that. You can go to the marketplace and you can say CF create service and you'll get a Kubernetes cluster. Oh, right, right, right, okay. Okay, so you can do that. But for middleware type workloads, it doesn't, it doesn't quite, it's not quite what you want. It's, the life cycle, for example, is associated with the Cloud Foundry space. Right, right, right, right, right. So, these middleware workloads, you know, they'd last for many years and they are usually independent and managed centrally. So, so the, the other way of doing that is to also use PKS but stand up individual externalized, if you like, PKS clusters. And is that like a different foundation that you run or is, or does it, it can still be the same PCF and run independently or? Well, I think I recall correctly that with the, with the service broker, so if you're in the CF marketplace, it's going to stand up, you know, based on the plan, it's going to stand up a certain size of Kubernetes cluster. Right, right. If you are deploying your Kubernetes through Bosch separately, then you have a bit more control over what that looks like. So, for example, you can give it more resources, you can have more nodes. Because, because to your point, you don't really, you don't need, whether you want to think of it as constraining and limiting or, or enabling and, you know, nice. You don't need that sort of plan stuff wrapped around it or containment. Because it is like, it's the middleware you're standing up is intended to be used by everyone. Exactly. Right, and to be long-lived and centralized. Yeah, that's an interesting distinction. But also, and probably similarly quite important, is if you're thinking about a middleware like an API gateway, you know, the purpose of that is really to be an edge service.
10:36You know, it's acting on the edges of your network. Yes. It's doing things like routing through to particular applications or, you know, looking at content or applying security or whatever it might be. In the integrated method, the, essentially, the traffic has already come through PCF before it gets to your, before it gets to your Kubernetes thing, whatever's in your pod. Yeah. So, you know, if you're trying to run an API gateway inside that pod, it's in the wrong place. Yeah, yeah, yeah. Because it's supposed to control traffic. Get an API gateway and an API gateway. Yeah, exactly, yeah. So, you end up with this kind of double router kind of problem. Yeah, yeah. So, it makes sense for these sort of middleware workloads to work in this kind of independent mode. And thankfully, PKS has got the flexibility to do both those things. Yeah, yeah. So, if you're a, you know, if you're a developer and you want some elastic search, whatever it might be, use the CF marketplace method. If you're an integrator and you need something long-lived, then use a kind of independent method. Yeah, and did y'all move over anything that wasn't luckily already containerized? No, we did, we, like I said, we managed to find containers for most things. Yeah. Although, the client had certain restrictions around versions. So, we did have some that we had to tweak and tinker with in order to make them work. But the WSO2 mechanism is to use a base container and then build on top of that. Yeah. So, it wasn't too bad. There was a few sort of small changes that we had to make. But it was a surprisingly smooth process. And I think that that's a good news thing. Because, you know, if you're an enterprise and you're thinking, you know, well, I work quite like multi-cloud for my, you know, workloads, my middleware workloads, then something like PKS could be a really good place to start. Yeah, yeah, that was another thing I wanted to ask is, I mean, there's no, it's just impressions and reflections at this point, probably.
12:37But for whatever reason, I hadn't thought about until a couple months ago the idea that, let's call them ISVs. But someone like WSO2 would be shipping their software in containers, right? Like, how does that change as far as consuming that software? Like, like, and for, if you didn't have, I haven't looked at WSO2 stuff in a long time, but if you didn't have it containerized, it would basically be like, here's like a jar or an ear or a war file. And here's how to get it set up in Tomcat. And you can kind of, and maybe we've got a VM image for you of like all this stuff built out. But basically, like, you should build this stuff. Whereas I would imagine if you put it in a container, it'd be like, I'm just making stuff up. But we've got five subcomponents to the system. And here are the five types of containers. And then you can just kind of inject the configuration into it. And then it's up and running. But I don't know, like, how do you think it's different using middleware that's already containerized? Well, there were, like I said, there was a few issues where some things perhaps hadn't had the demand on WSO2 maybe. So, you know, all the versions were quite old versions. So, you know, stuff goes out of date. Stuff doesn't get necessarily the love and attention that it needs to keep it all working. So we did have some work that we had to do. I think I recall it was perhaps around things like sharing configuration across a cluster. So in order to do that, they used subversion. Oh, okay. So you needed a containerized subversion in order to do that. That's interesting. So there were instances like that where we had to do a little bit of work just to finish off some, you know, round off some of those edges. Yeah. That didn't quite work. But I can see that, you know, it could be quite attractive to a vendor to, you know, be able to provide these container images. But from my understanding, from the press releases that I'm seeing and from some of the partnerships that we saw yesterday, for example, that, you know, more and more of them are looking to do that.
14:46Yeah. I forget the name of it, but there's like, it's not a, maybe it's a hub, but there's some directory of containerized things. I think for Kubernetes out there and there's a, there's a lot of things in there. Yeah. And also the, the Liberty bill pack, you know, being kind of included in the supported number of bill packs. Yeah. So that's a clear indication of how much WebSphere application server there is out there and how people are, you know, using the Liberty mechanism. Yeah, yeah. Try to leverage that and then push that stuff into the cloud. Yeah. And maybe we'll finally get all the advantages of like virtual appliances. Like that, that always seemed, it always seems like it'd be really a nice, really nice to have virtual appliances. And I, I always get the sense that never really pans out probably for many good reasons. Right. But just like the whole, the whole process of installing even mildly complicated middleware is, I mean, you were kind of hitting on it. It's like, well, you got to have this subversion thing over here that synchronizes with this. And, and you very quickly get into this situation of like, I got a whole other distributed application I got to deal with now. Do those appliances still come with CD drives? Exactly. Do you still have somewhere to put your coffee while you're working on it? Yeah, appliances are such a nice idea, but they, I mean, just, just the idea of like, ah, it just works. I mean, I guess maybe to some extent that's, that's like a, one of the huge reasons why like pure public cloud stuff is so attractive is it's not really an appliance, but it's already installed for you. Right. Like, and then you just have to configure it and get it set up how you want. But yeah, we'll see. Maybe one day. Appliances. We can all dream the dream coming. Well, I never, I never asked you to introduce yourself. Oh, okay. So, so, so, so who are you? Yeah. So, so my name is Ben Wilcock. I'm a solution architect working out of Europe. Yeah. I work for the application transformation team that helps our customers to move workloads into the cloud. And how many, how many people do we have on that team? Oh, it's a small team in Europe, but, uh, but across the globe, we've got something like 60, I think.
16:47Oh, wow. Okay. But the European team team is a small, uh, smaller percentage of that, but, uh, but we're growing and we're recruiting. So, you know, everyone's, uh, so, so what, what, what do y'all do? Is it, is it, um, I mean, from what you're describing, it sounds like a lot of everything, but like, yeah. What are the, what, like, what's the typical sort of like, like week or two of, of the kind of tasks that you do and the people you work with and the types of projects that you're working on? So, uh, so it's generally, you know, it's, it's usually always enterprise customers. So, so it's there, it's working with their developers essentially normally to either enable them to be able to use Cloud Foundry and to use the tools that they've got at their disposal. Or it's, uh, helping them move, you know, specific workloads. Migrating things. Or, or, do you say re-platforming or what's the terminology? We do. So we, we have, uh, we have sort of two terms that we normally use. So, uh, so re-platforming being small changes to things that are already, you know, if you've heard of 12 factors, then maybe these things would have, you know, you know, a few of those factors are already. And maybe they just need a few more in order to be able to push them into the cloud. So it's sort of like the spirit of refactoring. You're not really, this is a bastard or incorrect way of saying refactoring, but like, you're not really changing the way something operates. No. Well, no, actually it's literally that. You're changing the way something operates, but not the effect it has, right? Like you're not changing what it looks like to the end user. You're just messing around with the internal sort of. It's where it runs. Yeah, yeah, yeah. You know, rather than being on a specific box in a specific data center, you know, it's moving it. So it's a, so it's a more, uh, you know, it can be moved into any platform. Yeah, just moving to a new platform in the second term. That's the replatforming, yeah. The, uh, the modernization is where we take, uh, slightly more gnarly problems and we perhaps look at them with, you know, fresh eyes. So, uh, taking a piece of mainframe functionality, for example, and maybe, uh, separating that out into a set of microservices and pushing that into the cloud.
18:51So, so that's, uh, that's usually a bit more involved. It involves a little bit of design. Sometimes it involves thinking again about what the process is and what it should do. And very much our customers are at the forefront of helping drive that through because they know their context better than anybody else. But then, uh, of course, more recently, we've, we've also started to talk much more about lift and shift. You know, actually we've got a lot of customers who, uh, you know, there's only certain workloads that are worth the investment of modernizing or replatforming, you know. And there are, there are a lot of workloads that don't quite meet the business case. Um, they could be, you know, much more, uh, uh, uh, natural fit for something like PKS where you can take something that already exists, maybe containerize it and still get that sort of multi-cloud feel. And the management, uh, opt-in. Yeah, but without necessarily making it fully 12 factor and, and like you said, you know, getting that operator benefit where it can be scheduled and run anywhere. So it sounds like there's kind of like three areas of stuff that y'all do. And, and, and it's, I don't know, it's probably like, you know, uh, you know, 45, 45% or 40, 40, but kind of split between architecture sort of thinking. And then actual, just like development, like doing the work, right. Precisely. But then, you know, it's, it's, it's balanced. I would imagine it's balanced between that because you do have to be pretty deliberate about like, let's, you know, figure out the thing and how we're going to redo it or not redo it. That hints, the architecture part. And then, and then moving in. And then it seems like the minority of stuff though, it might be growing is, I don't know what you call it, like portfolio management. Almost like a little bit of, there's a tiny flavor of strategy in there where like you look at all the things that you could possibly move or change around or do something with. And you need some kind of input of like business rationale to basically sort through these ones we're going to leave over there on the, uh, on the mainframe.
20:55And those ones, these ones on the mainframe, we need to like modernize. And then this, this old like ESB over here, we're just going to like containerize to make it easier to move. But you need some kind of businessy input to prioritize that. Exactly. Yeah. And we, we do that with our customers during processes like scoping where we'll have a look at that portfolio and we'll perform that analysis to help them see, you know, which workloads are worth the investment, which ones are almost there. It might be worth, you know, thinking about and which ones they might want to, you know, over time, perhaps they'll retire them, for example, you know, retirement is also a valid option. But, uh, but we, we are, we are seeing sort of a, you know, we can reach deeper than ever before. We can move more workloads than ever before onto, onto the cloud. So, uh, so we're seeing a lot of engagement in that and a lot of, uh, a lot of interesting conversations like the one that we started with about. Yeah, yeah, yeah. A customer with the ESB problem. Yeah, well, that makes sense. Well, good. Well, thanks for giving me that overview. That was, uh, that was good. It's my pleasure. Yeah. We'll see everyone next time.