Jesse Gorzinski on Apache Camel and Open-Source System Lifecycles
Charlie Guarino: Hi everybody. This is Charlie Guarino. Welcome back to TechTalk. I am thrilled to have as a guest today Jesse Gorzinski, who is the business architect of open-source on IBM i, or I should really say, Lord Jesse Gorzinski. Jesse, welcome to our podcast.
Jesse Gorzinski: Absolutely Charlie. Thank you for having me on today.
Charlie: Great. I'm so happy that you're here today Jesse. It's always a pleasure to chat with you. The first thing that I said which really popped out is when I've seen your title recently and the word "Lord" has been added to that. It's a curious talking point that I would like to know a little bit more about that. What's the origin of that?
Jesse: Yeah absolutely. So I am now technically a lord of Ireland. My wife and I like to travel a lot. Of course, when traveling used to be a thing, but you know one of the places that we recently traveled to was Ireland. I went over there for the Node conference over in Kilkenny, Ireland and Ireland was one of those destinations that really spoke to us in terms of the beauty of the landscape, the people and their personality and their culture. We really liked Ireland as we do a lot of the destinations that we go to; that kind of stuck with us and so when I saw the opportunity for a Groupon roll across my ad feed on whatever platform I was on, I saw a Groupon that said hey you can become a Lord of Ireland for some trivial amount. It was $12 or something along those lines and so I leapt at that. So my wife and I, we're now officially land owners. We jointly own a small plot of land in the County Kerry, Ireland so not only are we officially Lord and Lady of Ireland but we also have a place that we need to visit the next time we head over to that island.
Charlie: It is a legitimate piece of property.
Jesse: Yes.
Charlie: I could go there?
Jesse: You could go there, yes. It has a nice view. They have some—there are some picnic tables set up. You can look over a nice green valley and a nice lake and take in the scenery.
Charlie: Wow.
Jesse: Yeah.
Charlie: Maybe I will as long as I'm not going to be greeted by people saying get off my lawn. That would be—
Jesse: Yeah, yeah. I'll give you the GPS coordinates and you can drive over there the next time you're in Ireland and check out the land that we own along with probably many thousands of other people.
Charlie: Great. Well for $12 bucks I mean—
Jesse: Yeah, yeah.
Charlie: It sounds like a steal so well great and I look forward to going there. I'll even send you a photo of me—I'll send you a selfie.
Jesse: There you go.
Charlie: Okay great. Well so every time I see you from now on, do I have to refer to you Lord Jesse or just Jesse is fine?
Jesse: Just call me Jesse.
Charlie: Okay, then I will. Thanks.
Jesse: Yup. It hasn't—hasn't quite gotten to my head yet.
Charlie: Okay, great.
Jesse: I reserve the right to change my mind.
Charlie: Exactly. That's great. So the real reason why I wanted to talk to you today, Jesse, is because you and I, we talk from time to time and we were talking about this project called Apache Camel and I know it's something right now that you really have a true, genuine and deep interest in and you've been promoting this on many of the social media platforms. I've been seeing articles about it or certainly tweets about it. So tell just what is Apache Camel and why is it relevant to me as an IBM i developer, even RPG in any capacity? What is Apache Camel? What is it? Why do I want it? Give me the why, the what, the how, all those things.
Jesse: Yeah, I'll try to give you a quick little what is it and why you'd care which is it's an enterprise integration framework and that probably doesn't mean a whole lot to anybody by itself but Apache Camel, they call themselves the Swiss knife of integration and what it really allows you to do is integrate IBM i regardless of what language you're using. If you're using COBOL or RPG or PHP, pick your language but it allows you to integrate IBM i with pretty much anything else, right. There's a huge list of Apache Camel components that provide these integration end points if you will and so that means it allows you to relatively easy hook up IBM i and integrate your solution with things like IoT, if you want to do enterprise messaging solutions that are open source like Kafka and ActiveMQ, social media stuff like Twitter and Slack. It does—it knows how to talk to SFTP sites. It knows how to send email. It knows how to integrate directly with the database right so you can perform transactions on the database. You can actually be hooked into the database to trigger events when database activity occurs right so being able to integrate with IBM i and also be able to integrate with countless number of other technologies is really important because we find that a lot of IBM i shops is they are looking at adopting open source for one reason or another. A common use case is that they need to integrate IBM i with some type of external technology right whether that's email, whether that's social media, whether that's IoT, whether that's quantum or block chain and that's what Apache Camel does is it provides you this ability to integrate pretty much anything with anything. I sound a little bit like a used car salesman without a demo sometimes, but it really is worth checking out. We do have samples available as well that show you with just a few lines of code how you can integrate you know with something like IoT devices and IBM i message queues or data queues or with the database.
Charlie: Well, if you subscribe to the theory or to the notion that the data is one of the most important assets of your company and now if I can capture all those changes, quite literally the world is my oyster. What I can do with that information once the database changes occur so that's as you said IoT and then can can that go both directions meaning that an IoT event can trigger something, and I can add something to my database via Camel?
Jesse: Yes, absolutely. It can go both directions so you can consume IoT data with Camel or you can control IoT devices with Camel. You can invoke those controls simple messages on a message queue or interactions from RPG via data queues and program calls right so it's very flexible in what you do but yeah, you can control IoT devices as well as consume data from IoT devices.
Charlie: You know Jesse, any conversation we have, even IoT in and of itself, that can generate an entire day's long discussion because that's so big and yet that's just one component of what you can do with Apache Camel for example. We can do anything; you mentioned Twitter earlier, email, I mean anything.
Jesse: Yeah, yeah, exactly and so it really is. The phrase you said is absolutely correct which is the world is your oyster at this point once you realize the power that you have in this integration framework and how little you—or how much you can do with just a few lines of Camel integration code, right. Being able to monitor a remote FTP site and kick off some task to do some backup or to send an email or to query the database and utilize IBM i services. Maybe you want something to happen when your disks get 70% full, you know maybe you want to get an email when your disks get 70% full or something and things like that can all be done with just a few lines of Apache Camel integration code.
Charlie: So it literally is giving us the capability to have a true paradigm shift here in how we're using and how we're writing applications. We're making them smarter and doing so much more functionality than ever before because we have access to information that we didn't have before certainly something well beyond the four walls of our organization.
Jesse: Right, exactly and that's why things like Camel are becoming really, really important because it's the ability to take this information and connect it to the various places it needs to go, right. If you want to have real time interaction with something like Slack right. Maybe you have a customer facing Slack channel and you want to be able to somehow integrate with that in real time, you can do that with Apache Camel and again the use cases are infinite at this point but it's just being able to get the data from and to the right places and get those messages routed to the right points of integration within your solutions.
Charlie: So this brings up a bit of a concern or a potential concern, anyway, and that is that so today you're talking about Apache Camel and perhaps it's new to me or maybe even not so new but it's relatively recently on my radar and I am a little bit concerned because of maybe some past experiences I might have had that Apache Camel is perhaps the flavor of day today and this is where we're putting a lot of our effort into but there's that little nagging voice I have in my head that hey, we'll use this today but it won't be fully supported or something bigger and better and shiny might appear tomorrow. How do I know this is something this is something that is worthwhile investing some resources in be it financial, time, or anything else?
Jesse: Yeah, that's a great question. Just like any software that you're choosing to implement in your organization whether it's open source or not, you have to do some level of evaluation to know the credibility and the long-term viability of that software, right and that notion in and of itself, like I said, that's not specific to open source, right, whether you're going to a vendor or some proprietary solution or some open-source solution, you need to get a sense for how viable is this, how useful is this, what are the true costs and how likely is it to stick around, but when it comes to open source, you do just evaluate things a little bit differently so the recommended metrics that I talk about when I talk about evaluating open-source projects and which ones are the ones with sticking power or which ones are the safest to use in your organization really come down to in my opinion four things right and those four things are vitality of that open-source project so that's thing 1, right? Are there continual updates and improvements? Are bug fixes handled quickly? Are security fixes handled quickly, things of that nature. How active is the community around that open-source project? How readily available are some of the key maintainers of that open-source project and that's all part of this overall vitality because if you look around for any open-source project, you can get a sense for whether this project is still very active or whether this project is maybe a little more stabilized and not as active as others right, so you look at that. You look at what I call open-source software's dirty little secret, which is corporate backing. If you pull back the covers, are there big corporations, are there big companies keeping this software viable, keeping this software afloat? So if you were to look at something like Apache Camel, Apache Camel is getting new enhancements all the time, new features all the time, very active community around it and if you look at the lead maintainers for Apache Camel, a lot of them are Red Hat employees who are paid to do this as part of their job because Red Hat has this vested interest in Apache Camel but you see that quite often in open-source projects where you have these really wildly successful open-source projects and if you pull back the covers a little bit, you see that there is real investment happening in those projects from Fortune 500 companies especially.
Charlie: So if I'm proposing a particular project for my company, this is something I should definitelyz—I should be armed with this when I'm going to management to discuss this as a potential project to implement into my shop.
Jesse: Yeah, absolutely because if you can go to your management and say listen, we're going to be deploying essentially the same technology that's used by Netflix for instance or Microsoft or PayPal and look how well PayPal scales and how well Netflix scales. Those are the conversations you have to say okay, we're using the same technologies that they are using and it also means that those companies have skin in the game and are likely contributing back to that technology as well to keep that technology around so that technology is not going anywhere once it hits this critical velocity where you have large companies using it, so you know once—Apache Kafka, for instance, is used to power a lot of Netflix's streaming service. I could probably have a separate talk explaining how they do that, but if you can go to your management and say hey, listen, we're streaming data around and your management say well gee, how do you know that it's going to be able to handle the work loads that we have, just say well, this is the exact same technology that Netflix is using to stream its data. Your management will be like oh, okay. This is safe right?
Charlie: Right. So, you mentioned—it's an interesting term, critical velocity. Does that mean that if a project does not in fact have critical velocity, then that's something I should not be entertaining then because there are people who do hobby projects out there. Should I not be bringing those into the fold?
Jesse: Yeah, I think it depends. I think one of the things if you're taking projects into the fold that don't necessarily have that critical velocity yet, you just need to be prepared to handle that properly in the future if activity in the project dies down, right. That might even mean some level of self ownership at some point.
Charlie: Yeah but that by itself does not disqualify it does it?
Jesse: Exactly. It absolutely doesn't and some people even say they would rather take the risk of an open-source project losing community momentum than a proprietary project that loses investment from its governing company, right because if a proprietary project says well you know, what? We're not enhancing this anymore. We're not going to fix bugs anymore. For a proprietary piece of code, that makes its end of the line where if an open-source project is in the same state where even worst-case scenario the community says no, we don't really have resources to keep this alive. We don't have the backing. Nobody has the time. Worst case scenario, you still have access to all of the code. You still have the ability just to push that code forward, to customize it for your needs, to add new features that you really need right. That's the worst-case scenario with open source is that you still have a way to move forward and you don't end up stuck on technology that's just not supported or not able to be used anymore.
Charlie: Right so we talked about who's investing in these projects, the vitality of it—
Jesse: Yup.
Charlie: Foundations.
Jesse: Yes so it's really common as well for software foundations to be involved with governing these projects of providing resources when it's CI building machines or actual developers or advocacy, education modules for the community and so there's a lot of software foundations that are really good at keeping open source credible, viable, and reliable right so examples of that would be things like the Eclipse Software Foundation or the ESF or the Apache Software Foundation. We all know about the Linux Software Foundation and there's smaller foundations as well like the Open JS Foundation is really doing a lot of great things in the JavaScript ecosystem and Node ecosystem these days. We have things like that Document Foundation, which is keeping things like LibreOffice vital, stable and a lot of great things going on there and so if you have a foundation like that, a software foundation that's backing your open-source project, that also is really good indicator right so generally anything with Apache in its name has the Apache Software Project behind it. Anything with Eclipse in its name has the Eclipse Software Foundation behind it.
Charlie: Which are all completely credible foundations obviously.
Jesse: Yeah, absolutely and you know they usually meet the criteria for a charitable foundation in at least one country, but the key thing is that if there is a foundation that's backing it, there's also people in other companies founding the foundation or funding the foundation and so again, you have this sense that there's other people with skin in the game for this software. You are not a loner in adopting this software so it's very strategic and safe for you to adopt when you see that indicator.
Charlie: Right and adopt and continue support certainly at the same time.
Jesse: Right, exactly and that's really the S word of support, that's the four of my four metrics so I'll summarize them in a minute but if you have software that companies are willing to provide support for, that's just another key indicator that this software is production ready. It's ready for primetime and if you opt to do so and you obviously don't have to but if you opt to do so, you could get support in place from somebody. That’s a key attribute as well, just to know that it's reliable and enterprise ready.
Charlie: So if I took your four metrics and I applied them to Apache Camel for example, every box would be checked right I mean obviously?
Jesse: Yeah, absolutely, right. The vitality is there, like I said, new features all the time. I'm in—their community chat is one of the most active open-source community chats that I hang out in so that's there. There are corporations involved so specifically Red Hat in their case. They have people who are paid full-time, I believe, to help maintain Apache Camel and other projects and of course it has the backing of the Apache Software Foundation, so that box is checked. Then there's a page out on Apache Camel's website somewhere where they list you know probably, I think probably 12-15 different ways that you can actually get commercial support in place for the software as well so in terms of vitality, corporate backing, foundation backing, and the availability of support. It checks all four of those boxes.
Charlie: You know Jesse, I think one of the main components of open-source projects in general is the community support and even within the context of IBM i for example, there are community channels that we can join for free in fact and I know you're very active in a couple of them. Give me some—if I'm new to this and I want to just start reading some of the previous posts, where does one go to get better educated on this?
Jesse: So there's a couple places you can. The first that I'll mention is the IBM i community Slack channel which is not specifically focused on open source although it's technically a Slack workspace. There is an IBM i open-source Slack channel within there but it really is used by a lot of general IBM i community folks and there's I think a couple hundred IBM i community folks in there. If you're familiar with Slack as many people are, it's a very familiar environment for you to go meet people, ask questions, share good stuff, and just socialize in general but probably the best place for IBM i open-source folks to hang out is the community chat channel called Ryver, R-Y-V-E-R, and that allows you to go hang out with I think we're at over 600 members out there, probably one of the most active places to go collaborate with other folks with open source, definitely the most active place for IBM i open source. There are special forums for Node.js, for PHP, for Java, for Nginx, for database stuff right and so there's just a lot of activity out there that you should go definitely be a part of. So anybody who's interested at all in doing open source on IBM i should be part of that Ryver channel above all else.
Charlie: And if I'm a total newbie here and if I join Ryver, what kind of posts would I typically see? Would I find code on there? Will I find just questions and answers or all of the—I don't even know. What else have you seen on there?
Jesse: Yeah, a little bit of everything. You have a lot of Q&A happens. People will say how do I do thing X, Y or Z and of course other community members will try to help them out as best they can. Sometimes people come in with issues that they're having, and we talk through those. Sometimes it's just more high level like general trends and directions, how do we see the market going, where do we seen the trends with certain technologies right so it's a little bit of everything you know from very detailed technical discussions all the way to you know just people being social and hanging out with each other and talking to each other in the general channel right it really is a bit of everything over there and you should be a part of that if you're interested in open-source on i.
Charlie: And of course there are all these stories and we've talked about these in the past also. There are some projects that ultimately do reach end of life and there are some things that just die I suppose. You know we talked about Ruby as being maybe an example of this right?
Jesse: Right and open-source projects, it's really hard for an open-source project to truly die so people talk about the death of an open-source project. That is very extremely rare. What generally happens is they might lose buzz. They might start to lose some traction in adoption rates so for instance if you're a programming language like Ruby, you might see some of the industry analysis say okay fewer people are using Ruby this year than last year and so on, right? Ruby itself kind of peaked in I would think like 2006 to 2009 timeframe was when it had its best heyday but what's interesting about Ruby in my opinion is the vitality is there. In December so just a few months ago, they came out with version 3.x of Ruby and they had really great performance enhancements. They added a JIT that's going to like 3X the performance throughput of things and all kinds of great language enhancements as well so with Ruby the technology itself is great right and the language, I don't particularly dislike the language. The language is very elegant, very object oriented and so the technology is there; the vitality is there but as far as I can tell, I don't see any evidence of a big IBM or a Google or a Microsoft or a Netflix behind Ruby helping with skin in the game to make sure that it's a top contender in the language market right. I didn't see that. I don't think that it's part of any software foundation, definitely not any of the larger software foundations and so it checks that vitality box but it kind of fails on some of those other boxes that I talked about earlier. So, it's not dying; it's not dead but it's definitely on a decline.
Charlie: And to be sure, there are shops obviously still using it in production and using it quite well in fact.
Jesse: Yup, absolutely. Yup and we actually have—in the Ruby case, we even have some Ruby builds available with Ruby 3.0 for IBM i clients right but so it's not dead. It's just the general trend is that it kind of fades out of what people talk about. That's generally what happens to open-source projects. It's very rare for them to actually die. They just get replaced with other things; other technologies might grab their momentum and build upon it, but they very rarely actually die.
Charlie: Yeah but honestly I don't think that that model is unique and is singular to open source either. I mean so many of the technologies of other platforms follow that same pattern, that same cycle.
Jesse: Yeah, exactly. You're spot on because none of that is that is unique to open source. It happens all the time with other products.
Charlie: Sure. You mentioned Ryver, which again, this is R-Y-V-E-R and not river. We talked about something called Zulip. Am I saying it correctly? Zulip.
Jesse: Yeah Zulip.
Charlie: Tulip with a Z.
Jesse: Tulip with a Z yeah so Zulip is a good example of one of the many open-source communities that you can join that is not IBM i specific right but it is very unique in that it gives you really great access to the people who are keeping the code alive, people who are maintaining the code so Zulip is the platform for instance that Apache Camel uses so the Apache Camel community has a Zulip chat and there's a mobile app that I have on my phone. There's a web interface as well. People may have never heard of Zulip but if you go join the Zulip chat, you will see very active conversation happening every single day and that's important to understand. As an IBM i open-source developer, you can join all of these other communities and engage in these communities and also get really unique access to the people who are actually writing the core of the code and the active maintainers of the project right so if you were to joint the Apache Camel Zulip chat, you can ask a question and the people who wrote a lot of the Camel components that you're using might be there to immediately answer your questions. It's a really unique value add that you get with open source and that some of these communities provide this really direct conduit to the definitive experts on the technology.
Charlie: And a very strategic part of the whole community as well.
Jesse: Yeah, exactly. Exactly and there's you know there's all kinds of community chats for that, for these various projects. I hang out in you know the open J9 Slack channels. The Open JS Foundation has some good community presence as well. The loopback API framework, the Qiskit community which the quantum computing frameworks for Python, all of those communities just have tons of people in them. They're very active and you can go join and learn a lot of stuff and grown yourself as a professional by joining these open-source communities.
Charlie: So what are your final thoughts, Jesse, if somebody is just now starting to dip their toe into this, what's your best advice? I mean, would it be joining a community first or download one of the projects and start using it or a combination of all of those?
Jesse: Yeah, I would say there's two pieces of advice, right. The first piece of advice is just do it, because the biggest roadblock is often a little bit of fear and uncertainty and you don't know if you're using the right technology or you don't know if you're using the technology in the right correct way, but just do it. Even if you're doing it wrong the first time, just do it. You're going to learn a lot and the other piece of advice is perhaps even more important just know that you're never alone in doing stuff with open-source technology. There's always a community. There's always somewhere to go find somebody and don't be shy. Reach out, say hello to people, meet some people and make some friends but grow yourself as a developer or a professional and just network and learn a lot of cool stuff. You're never alone on your journey.
Charlie: Sounds like good life advice also.
Jesse: Yeah, true.
Charlie: Jesse, what can I say? It's always such a real treat to chat with you. I want to thank you so much for your time today and for being a guest on TechTalk. Thank you very, very much, really a pleasure, and the information—
Jesse: My pleasure.
Charlie: That you bring is just really so timely and relevant. I'm sure a lot of people will find this very helpful and don't be surprised if you get a lot more members coming to Ryver asking questions which is a good thing right?
Jesse: That'd be amazing, yeah. Please come join.
Charlie: Right. All right, so thank you Jesse. This is Charlie Guarino as I said. I will be back next month with another podcast. In the meantime make sure to check out the other content on TechChannel. They have a wealth of information, newsletters, webinars, e-books, things like that and it's worth your time. Don't forget to join the subscription page. Thanks very much for joining us and until next month we'll be in touch. We'll be in touch. Thanks again. Bye everybody.