Guest: Wayne Seguin (LinkedIn, Twitter)
Company: Stark & Wayne (Twitter)
Show: Let’s Talk

Kubernetes has become the de-facto standard for container orchestration, which has a direct impact on Cloud Foundry users. The Cloud Foundry community already saw what was coming and started preparing for the Kubernetes-driven world. But what about the users who have invested heavily in Cloud Foundry? What options do they have? How do they retain the Cloud Foundry’s experience for their developers while benefiting from Kubernetes? Is there any easy migration path? Should they worry about these changes? To get answers to many such questions, I sat down with Wayne Seguin, Chief Technology Officer of Stark & Wayne.

Talking about the megatrends he is seeing in this space, Wayne said, “A lot of customers want to stay with the benefits of the Cloud Foundry’s experience for their developers, but at the same time capitalize on the standardization of technologies around Kubernetes.”

To help such customers, the Cloud Foundry community came up with many projects to assist with migration from Cloud Foundry to Kubernetes, but most of these projects failed. One of the most successful projects has been Google KF which has become a bridge between these two complementary projects. Wayne talks about why other projects failed and what lessons we can learn from there. This is just the tip of the iceberg. Major topics we covered in this show include:

• What are some of the megatrends you have seen in both Cloud Foundry and Kubernetes space? What kind of concerns are there due to changing dynamics with Cloud Foundry?
• You mentioned that many migration-related projects didn’t succeed whereas Google KF succeeded. Can you share if there are any lessons we can learn from Google KF? Why did it succeed when many other projects failed?
• What challenges do you face when you help customers migrate from Cloud Foundry to Google KF?
• Can you share if there is a playbook – the right steps one must take to ensure a smooth migration? What mistakes can they avoid?
• What does the timeline for these migrations look like when Stark & Wayne helps customers with such migrations?
• If you look at the evolution of Stark & Wayne itself, you folks started as a consulting firm. But are you also building some tools and platforms to help users?
• Should Cloud Foundry users panic because of all these changes?

[expander_maker]

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to TFIR Let’s Talk. Today we have with us, once again, Wayne Seguin, Chief Technology Officer at Stark & Wayne. Wayne, it’s great to have you on the show.

Wayne Seguin: Thanks, Swapnil. It’s great to be back.

Swapnil Bhartiya: Today, we are going to talk about some of the mega trends that we are seeing in both Cloud Foundry and Kubernetes space. Wayne, what kind of changes in terms have you seen in the Cloud Foundry space in the last couple of years? What kind of concerns are there for organizations who have invested heavily in Cloud Foundry?

Wayne Seguin: Actually, I think your question summarizes extremely well. A lot of customers, they want to stay with the benefits of the Cloud Foundry developer experience for their developers, but at the same time capitalize on the standardization of technologies around Kubernetes. As far as their futures are concerned, there’s been a few what I don’t call false starts showing promise, but archive now. One of them was the KubeCF project, that was trying to get Cloud Foundry reported over to running on top of Kubernetes natively. There was another one cf-for-K8s, it was the other one. So cf-for-K8s and again, that one has been archived. And then there’s a newer version of, hey, let’s take Cloud Foundry and get it running on top of Kubernetes, and that is Google KF and all these efforts have a pretty neat idea.

However, they haven’t materialized into something that’s, let’s say production usable because clients of ours at least have tens of thousands of applications running on their Cloud Foundry. That doesn’t exactly port well over to running on top of Kubernetes directly. There has to be some sort of a mapping. You’re introducing more systems, more clusters, more this, more that. There’s also not a trivial easy way to map it today, as it stands. That said, I’ve been following a project from Google called Google Kf and they are trying to achieve the same thing, yet their approach is not… Let’s take Cloud Foundry’s bits and pieces and make them run on Kubernetes so that we can kind of switch over. But rather let’s preserve the developer experience and APIs of Cloud Foundry as our core tenant and enable workloads that were deployed to Cloud Foundry to be simply deployed over using Kf tool. It’s basically, you substitute these. Instead of using cf push, you’ll be doing kf push, or you can still cf push, but in the back end, it’s the kf.

What kf does is its several bits, it’s a CLI and then several bits on top of Kubernetes that basically handle the behind the scenes things that need to happen in order to take, here is my source code, run it for me. I don’t care how, right. That’s the premise of Cloud Foundry. Well, kf delivers on that and at the end of the day, the same cf push or kf push in this case, that happens, ends up with running application code on Kubernetes as the orchestration instead of Diego in the Cloud Foundry world.

They’ve actually delivered on that about a year ago is pretty rough shape, not going to lie, but this year, especially the second half of this year, we started kicking the tires of it again and for real. It’s come quite a long ways and it’s definitely a viable path for companies looking to migrate as many workloads as they can from the Diego based orchestration to a Kubernetes based orchestration, so that the developers and operators can use kubectl or use the Kf CLI for interacting with application workloads, but it gets them on to that Kubernetes future that they’re looking for, so that could be just go ahead and own and operate it like that. Or that could be as a stepping stone to then migrate to whatever future they’re looking at in the long term.

There’s a number of good things happening over there. And I feel very strongly at this point it’s worthwhile taking a good look at. It is one of the most promising and viable options for those looking to migrate their workloads onto Kubernetes, in my opinion. Similarly, I have to say, it’s not just for running on Google, like Google Cloud, right? It can be actually used to deploy to Amazon and Azure and all… Actually several public Clouds I think, and also On-prem and bare metalWhat excite me is On-prem bare metal. So they have all kinds of options for that via their Anthos system. So you basically deploy Anthos wherever you want, and then you can just migrate your Cloud Foundry workloads with Kf directly on top of it. It’s a really compelling story to be honest.

Swapnil Bhartiya: Thanks for explaining that in such detail. You mentioned couple of products that did not succeed, whereas Google Kf succeeded. What lessons are there for the community to learn from the failure of such projects and success of Google Kf, so as they do work on migration, these lessons will help them.

Wayne Seguin: I think the biggest lesson to be learned is you don’t have to always assume you need to take what is existing and transform it to where you want to be, but rather sometimes it’s actually very good to step back and say, “Hey, what is it that we do want to preserve?” What is the actual APIs or experience? What is the contract with our end users that they love about us, that we want to preserve going forward? And how can we fulfill that in the most straightforward manner, by leveraging as many of the target platform native things, in this case Kubernetes that we can. I think that’s… You don’t always see that happen. Watching that evolve and seeing exactly what happened is pretty interesting. That is a lesson that I take away from that anyways, because there are all those older archive projects went On-premise, okay, we’ve got all these bits, let’s now make bits run over there versus let’s take the actual use cases and stories that this provides and move that experience over there specifically.

Swapnil Bhartiya: When Stark & Wayne helps customers in migrating from Cloud Foundry to Google Kf, what are the challenges that you often see both culturally and technologically?

Wayne Seguin: The biggest challenges actually occur what I would call the edges, right? If somebody has just leveraged Cloud Foundry for what Cloud Foundry is, and not tried to extend it, or do highly unusual things. If they stick to the best practices of here’s how you use it, here’s how you run your apps and stuff like that. It tends to just work out of the box and is super effective and efficient migration from Cloud Foundry to on top of Kf.

So those edge cases where they’re modifying the Cloud Foundry platform to do different things underneath that it either wasn’t meant for or it’s a little awkward to do that, and instead of consuming application workload communications via the routing in, sometimes folks will go around behind the scenes and reach in underneath, instead of going through the official routing path, they’ll go underneath, start communicating with apps behind the scenes and things like that. That stuff is not necessarily a good fit for this, but what we find is like 80 to 90% of the workloads for most customers probably are a good fit for being able to migrate over to this pretty straightforwardly, and then there’s a bit of a lift for an effort, let’s say for the remainder.

Swapnil Bhartiya: Now if ask you, if there are any steps or if there is a right way of doing things that you would recommend to folks who are doing these migrations, because they have to avoid mistakes that most people tend to make in their process.

Wayne Seguin: I mean the first thing is obviously, or maybe not obviously, but the first thing is to identify where those edge cases might be and come up with a plan for how you’re going to mitigate them. The Kf tool actually has a facility for helping out with this. Fans of Excel will love this, but basically the Kf CLI has a built in command where you can have it scan a cluster. It calls a scan cluster, but it’s basically going to the CAPI for a Cloud Foundry, and it’s going to query the Cloud Foundry and pull back a whole bunch of data and information and dump it into an Excel file. It also adds annotations to that Excel file, indicating places that you might want to look for that might be concerned that might need a plan. That’s a really good approach actually.

Swapnil Bhartiya: Can you also talk about what does the timeline look like? How long does it take for such migrations and it would be great if you can also share how Stark & Wayne is helping customers to speed up their journey.

Wayne Seguin: As far as the migration journey, the timeline depends on which category they’re in. If they’re in the, hey, we’re doing all the right things the right ways, then the timeline for migration is actually a lot shorter because it’s literally just, okay, we’re going to redeploy over here, switch over and fully macro. That was cool. Right? So it’s more of a hold [inaudible 00:10:40] watch this moment versus all right, let’s roll up the sleeves and dig into this. So what Qarik and Stark & Wayne are focusing on doing is we’ve basically built a program around their tooling to work with them and their customers, Google Kf and Google to basically we have a way of assessing their workloads. Basically all that data that I was talking about earlier, we have a way of basically getting a single pane of glass visualization of the state of their system.

We have multiple views within that pane of glass for trying to identify what’s the low hanging fruit. What’s the mid-range, what’s the hard problems and trying to sort and categorize and things to assist, like prioritizing which application workloads should go when. So we have a systematic way of approaching that. We built a program around ends. That’s how we approach helping them in anyways, and try to work very closely with both Google and the customers to find the best path for the outcome they’re trying to achieve. But it also usually, I’m sorry, but also, usually we start with a small MVP where we’re like, well let’s show that it can work in your environment because let’s be real, everybody’s environment is very unique because of their particular industry and regulations and choices over time and things like that. So we usually start with an MVP, show that it could run and we can port some subset sample of applications over and after MVPing it, we then can say, “Hey, let’s go do the rest of them.”

Swapnil Bhartiya: If you look at the evolution of Stark & Wayne itself, you folks started as consultation, but are you also building some tools and platforms to help users?

Wayne Seguin: Yeah, so we build… Fundamentally we have over the last eight years, what we focused on is specializing in building out tools that help with all of the undifferentiated heavy lifting that you have to do around owning and operating platforms such that they can be owned and operated and maintained long term effectively. Coming into this new world where folks are looking at trying to migrate from Cloud Foundry to Kubernetes. One of the things that we often find is, well, that’s cool and all, but like, how do we look all of these application workloads and the buildpacks and the services. There’s just all these different concepts that we have to consider when we’re going to think about migrating to Kubernetes.

And as I mentioned earlier, we’ve been working on this single pane of glass sort of project for helping to look at understand and visualize the state of the system, everything from the pipelines, the operations things, and then obviously what’s running on the platforms themselves from the applications, the application instances, the services, the buildpacks, the stacks, stemcell, all of the things, right?

So it’s pretty important to have a clue of what you have today, if you’re going to make a plan for where you want to or how to get to where you want to be tomorrow. That is exactly what we’re trying to solve for. I think we’re coming pretty far along on that. If I had to some special sauce, then we’ve got a little bit of special sauce in that sort of single pane of glass assessment style approach for identifying Cloud Foundry workloads and helping to prioritize them. That’s basically what we’re really trying to solve for, pretty hard right now.

Swapnil Bhartiya: We have covered this topic earlier, but I want to hammer that point across again, which is, should Cloud Foundry users panic or worry about with all these changes that are happening around in the community and ecosystem?

Wayne Seguin: That’s actually a fantastic question. There is a lot of fear, uncertainty and doubt flying around these days on the future of Cloud Foundry and all those things. I would say, don’t worry about it. Stark & Wayne was sponsored or powered by the Qarik Group. We’re going to be around long term to offer basically enterprise support for owning and operating in Cloud Foundry. So it’s not going anywhere. You got a solid three to five years, I’d say, if not longer on that. There shouldn’t be a sense of urgency. Everything should be approached with what is the best future for us and our company type of mindset, and as such slow down, survey the landscape and let’s place some good bets on the future and figure out what’s going to look instead of what’s new and shiny and up and coming. Let’s look at what’s going to serve the company, the client companies much better for the longer run.

Swapnil Bhartiya: Wayne, thank you so much for taking time out today and share these insights, and as usual, I look forward to talk to you again soon. Thank you.

Wayne Seguin: Thank you. It was awesome to be here again. Good to see you.

[/expander_maker]