Konveyor.io Community with James Labocki

Media Thumbnail
00:00
00:00
1x
  • 0.5
  • 1
  • 1.25
  • 1.5
  • 1.75
  • 2
This is a podcast episode titled, Konveyor.io Community with James Labocki. The summary for this episode is: <p>Konveyor is a community of people passionate about helping others modernize and migrate their applications to the hybrid cloud by building tools, identifying patterns, and providing advice on how to break down monoliths, adopt containers, and embrace Kubernetes.&nbsp; Join us for a conversation with James Labocki organizer of the Konveyor Community.</p><p><br></p><p><strong>Key Takeaways:</strong></p><ul><li>[00:05&nbsp;-&nbsp;00:19] Intro to the episode</li><li>[00:52&nbsp;-&nbsp;03:18] James' conveyor project: What it is and the origins</li><li>[03:27&nbsp;-&nbsp;06:03] Two main aspects of Konveyor.Io community</li></ul>
Intro to the episode
00:14 MIN
James' conveyor project: What it is and the origins
02:25 MIN
Two main aspects of Konveyor.Io community
02:36 MIN

Luke Shaw: This is Luke Shaw with IBM Developer. I'm pleased to bring you a conversation with James Labaki. James and I are going to be discussing the conveyor community, digging into how it's helping folks modernize and migrate their applications to hybrid cloud. Hello, James. Thanks for taking the time to connect.

James Labaki: Hey Luke, thanks for having me.

Luke Shaw: Before we dig into the nitty gritty of the conveyor community, could you give a brief introduction to our audience?

James Labaki: Yeah, my name's James Labaki. I'm a director of product management in Red Hat's cloud platforms business, which focuses on Kubernetes and OpenShift, our Kubernetes platform offering.

Luke Shaw: So right away I was excited what I heard about the conveyor project because at modernization is a big part of what I'm interested in and what I make content about. So I wanted to ask you about the Origins. What was the impetus of creating the conveyor project?

James Labaki: I've been at this for a while with how do we get people to embrace and adopt OpenShift and Kubernetes in general. And inside of Red Hat, we've had a number of investments over the years around tools to help you migrate your applications, analyze them, all sorts of things. But what we started to realize early on in 2020 was that our approach was really about putting tools out into the market, but not necessarily actually building a community approach around them. And when we looked at just a broad landscape, even at the Cloud Native Computing Foundation and others, we really saw a gap or an opportunity where nobody's really putting out tools. When you look at kind of the six Rs framework of modernization strategies, whether it's rehosting, replatforming, or refactoring, putting together tool sets that are open, accessible and could be contributed to as well, but then also all the best practices and guidance around there. So we thought it really struck a chord when we started to talk to CIS admins and developers alike, just talking to them about, Hey, we know you're tired of hearing the words digital transformation. You want to actually see what practitioners do on a daily basis when they have to strangle a monolith or when they have to carve off a sidecar container or implement some strategy for rehosting a workload? And so that's really where we said, let's come together and put this conveyor community together.

Luke Shaw: That makes so much sense because if the tools and the know- how are there, but they're not engaged with people in a way that they are enabled and also get that feedback loop because these things are a bit of a moving target and they're going to as a landscape changes.

James Labaki: Yeah, absolutely. And that's actually another reason we took the community approach. Two more reasons, which is, one, we know that there's not just going to be one tool set to do this. There's going to be multiple tools in the bag and there's going to be tools that end up becoming less useful over time as people modernize and tools that become more useful over time. So maybe right now Rehosting tools might be really helpful to just forklift and move one of your virtual machines over to Cube Vert directly. But maybe over time we have less and less virtual machines in existence, that becomes less useful and it's more about how to transform things into serverless or those sorts of areas. I think that's the reason we wanted to build a community around this so that tools can come and go and different projects can join this community and contribute to it. But over time, we're helping continue to move people forward in the right direction. And the second reason was because if we come out there with a top- down approach of this is the tool set and this is how it works, we're less likely to be successful, I think, than if we take a series of small projects that are in this space, put them together, and then allow people to begin using them and then interacting directly with the developers who are creating them so that we can build the ideal solution.

Luke Shaw: So give me an idea of how this is laid out. We'll look at the community part first and then we're going to look at maybe what the projects are like today. So what are your community efforts look like?

James Labaki: Yeah. So right now there's really, I would say two main aspects of the community. There's the projects themselves, so the tools that we're building, and then there's a series of meetups that we're running on a regular basis. If you go to konveyor.io, you can click on the meetups tab and see the previous meetups. You could watch them all, they're all recorded out on YouTube. You can click on the form and join if you actually want to get invites. So we're running meetups. We've had folks from the VMware team join us and talk about their cloud suitability analyzer and how it works. We've had number of consultants that have been working on projects taking monoliths and breaking them down into microservices, present how they've done this, how they've built helm charts, all those sorts of things. So the meetups are wide ranging and they're not necessarily about using the projects and the tools in our community, but we try and stay away from anything that's vendor or proprietary, I would say from a tooling standpoint, as long as it's open source and the code is available, come out and talk to us about it, show it, explain how people can use it. And then the second piece is those projects. Right now we have five projects that we're focused on. One is called Crane and it helps migrate your applications between Kubernetes clusters. So you can imagine the scenario where you have one version of Kubernetes you want to move to another, Crane can help you actually begin migrating those applications and their persistent data. We have another one called Forklift, which helps you migrate your virtual machines into Cube Vert. Cube Vert is the project that makes virtual machines orchestratable by Kubernetes and first class citizens. Another one called Move to Cube. It was actually open sourced by IBM Research in the middle of last year. They had been working with some customers helping them migrate from Swarm and Cloud Foundry to Kubernetes. And so move to Cube helps with that replatforming and being able to collect and transform those assets. And then another one is called Tackle, which is primarily focused on refactoring. And that one's really just at its infancy and getting started. A lot of the learnings that we've had in several other open source projects are being brought together. And the IBM research team is also joining us there to work in that project to start to help with the refactoring use cases of assessing, analyzing applications, and then actually all the way out to executing code generation for refactoring. And then the last piece of this whole thing that we've recently pulled in is a tool called Polaris that we're working on bringing over to the source code to the community. It was developed by some consultants who were looking to measure software delivery performance. So if you're familiar with the Dora metrics and how do you improve your change failure rate or your meantime to recover from an error, that's introduced, and some of those metrics like that. So our goal there is to hook not only the actions you're taking to rehost, replatform, refactor, but also taking into account the metrics and how you're affecting your software delivery performance based on those.

Luke Shaw: That's so interesting. I'm curious too about the tackle and refactoring. Is it language specific or agnostic, or is it... I'm imagining Java seems to be like the obvious place to start with that.

James Labaki: Yeah. So Red Hat and certainly of course IBM are both contributing in this project right now and just starting it out. Certainly they have a lot of tooling. If you look in the past, there were a number of tools inside of IBM to help with analysis of Java applications. Similarly, at Red Hat, we had an open source tool called Windup that would do static analysis and help you understand which libraries and dependencies would've to change to maybe move from one version of a Java application server to another. Or for example, from one version of Fuse to another, or a business rules management system to another. So there's a lot of expertise in those areas as far as Java application analysis specifically. But the idea behind Tackle is actually to be more language agnostic. And so a lot of the assessment questions are actually coming from some of our services teams who developed a framework and a tool called Pathfinder that would allow you to answer dozens and dozens of questions about your application. Do you have access to the source code? How regularly can you change it? Is it deployed by a pipeline? How do you patch it and maintain it? So those sorts of questions that you can't necessarily get from code analysis are also part of that Tackle project. And so the idea is building a common application inventory and then allowing multiple teams to integrate with that application inventory to provide things all the way from assessment to analysis and beyond.

Luke Shaw: And I think one of the reasons I got really excited hearing about Tackle is something that came up during the app modernization series I worked on last year, and it was actually Duwan up in Canada, Duwan Ahmed. One of the things he talked about was everybody wants to build the new bridge, cut the ribbon, have this opening, but who wants to maintain the old bridge? But that's so essential for civilization. We need to maintain things, we need to deal with that. I like the term heritage, has been taught to me, versus legacy. We still have these things there. But people, they think that maybe refactoring is a boring process or it's this chore. When in reality if you think about it, you're enabling yourself and your organization to keep all this value that you've already created and move it forward and give it and extended its life.

James Labaki: Yeah, and I think each technique, whether it's rehosting, replatforming, refactoring, has its pros and cons for sure. It all depends on what's the business driver for the application and what's the goals. If you're looking for the lowest friction way to check the box and say, Hey, I moved to cloud or I moved to hybrid cloud, you could absolutely rehost your application in Cube Vert and bring that over as a virtual machine, but you might lose many of the benefits of scalability that you'd get if you refactored into microservices using containers. I think it's definitely a spectrum and hopefully people understand that and also realize that it's not necessarily just a one- time thing, but more of a once you get it there, you continue to improve it and refine it over time.

Luke Shaw: I really like that point too, because something that came up with an interview I did with someone from the IBM Garage, it was Andrea Crawford, she taught me the heritage over legacy is this idea of, I think there's a term called lift and shift where maybe it's more like move and improve. Because even if you're just rehosting, if you implement, say a more modern DevOps pipeline around that, even if you've rehosted it, you've still now put it in a place that you can make those incremental changes moving forward.

James Labaki: And I think that's what we're trying to expose a lot with more around the meetups. So the tools are great, people like tools, but those meetups are really where I hope both outbound from the tooling actually showing, Hey, here's how we think you should use it. But then even inbound, here's how people have used it with customers, and here's the reality of the process and culture change that had to go along with it for sure, because I remember early on as a field engineer at Red Hat working with government customers and they had built this cloud environment, they were all very excited and they said, it took us two days to transfer the money from one government agency to another. So they couldn't actually provision their machines as you're only as fast as your slowest process.

Luke Shaw: It sounds like from what you're doing there'd be lots of interesting stories.

James Labaki: Actually, I think one of the more interesting meetups that we had early on was around basically how do you translate a real world scenario of translating your application requirements into helm charts for deployment on Kubernetes. And so it was like, here's the hello world with Helm charts, and then here's the reality when you're in a large financial services customer. And they have these applications and these security requirements and all these things, and so it's really one of the next levels down of just like your boots on the ground or you're in the bunker with shots firing around you as you're going through trying to modernize an app and take this customer's security stance and actually make it work with helm charts and all those sorts of things, which I think really it's invaluable. It goes beyond the hello world to hopefully saving somebody some time when they're thinking, how do I make sure I'm PCI compliant when I'm doing this? Or I get through my audit or whatever it is they have to face in their specific industry. It could be very challenging even for people within highly regulated industries to be able to understand what their peers are doing and how they're doing it. So hopefully some of these meetups end up doing that. We're always looking for new speakers, whether it's from global system integrators that have their hands on the keyboards that these customers do in modernization. At Red Hat we're small relative to the rest of the world of app modernizations, but we're hoping that we can bring more people together, whether it's customers, other partners, users, that sort of stuff.

Luke Shaw: So I'm going to put links in the show notes for the Slack community for where you have your online meetups posted as well as current page of the GitHub projects. Do you have any closing thoughts or advice for our audience?

James Labaki: Yeah, poll requests are welcome as always, and we hope to see you on meetups. And really would welcome any kind of contribution and attendance as well as use and feedback on the tools to help us accelerate people's journey toward Kubernetes.

Luke Shaw: Excellent. Thank you so much, James.

James Labaki: Yeah, thanks Luke.

DESCRIPTION

Konveyor is a community of people passionate about helping others modernize and migrate their applications to the hybrid cloud by building tools, identifying patterns, and providing advice on how to break down monoliths, adopt containers, and embrace Kubernetes.  Join us for a conversation with James Labocki organizer of the Konveyor Community.