Tune into the first episode of our "Cap on Camunda" series, where Capital BPM CEO and Principal sits down with Zach Wylie to discuss a variety of topics surrounding Camunda - the best open-source process orchestrator in the game. Listen to Max talk about his loyalty to Camunda, the importance of microservice orchestration, how to overcome Camunda's biggest weakness, and so much more.
Tune into the first episode of our "Cap on Camunda" series, where Capital BPM CEO and Principal sits down with Zach Wylie to discuss a variety of topics surrounding Camunda - the best open-source process orchestrator in the game. Listen to Max talk about his loyalty to Camunda, the importance of microservice orchestration, how to overcome Camunda's biggest weakness, and so much more.
Max when it comes to micro service orchestration and the different platforms we could were considering, such as Camunda. What exactly should we be looking for? And what are the differences in each? And what are the strengths. So micro service orchestration is something that we all have to do in the enterprise space. So, whether you're using something like Camunda, or Kafka or temporal, or or a million other things, you have to have a way for one system to call another to call another and to deal with exceptions and timeouts and escalations and retries and throughput and logging and security and multi tenancy, you have to solve that problem. Are you going to solve that problem with a homebrew solution? Or are you going to use you know, an off the shelf product for that. And this, I think, is sort of a fundamental perspective that we need to be thinking about, there are places where I think a homebrew solution makes sense. So if you are doing something super idiosyncratic to like your industry, and you know, you're using some your own proprietary protocol, or you have, you know, other other needs like that, then I can imagine that, you know, an off the shelf engine wouldn't necessarily work for you. But for the most part, the majority of us don't live in that space, the majority of us are trying to do fairly conventional things, we want to make a restful call here, make a G RPC call there, we want to talk to the database, get some information, log all of it encrypted and update this other data source. So for that purpose, you can either write custom code, if this happens, then do this on this, there's a timeout and escalate and send this email and so on and so forth. Or you can use a micro service or orchestration engine. Now, all of the microservices orchestration engines that are out there, you can sort of take something like a Kafka, and then build logic around it and establish your own message protocols. And, and, you know, use that as a mechanism, really to transport messages back and forth. But you still have to build logic and MDM and even like a pseudo grammar around that, right. So when we put messages on the Kafka queue, we do this, and we do that, and so on, so forth. Or you can go hardcore, you can like, you know, write if statements that are nested, hey, if this happens on this, this times, I'll retry three times, unless it's this endpoint, and so on and so forth, inside of your code. Or you can use some kind of a workflow engine, right. And I think the idea of the workflow engines, or languages that are sort of specific and targeted for solving this particular problem, make a lot of sense, in the same way, that using something like SQL makes a lot of sense when you're dealing with data access, because it's not a generic problem that's very specific to a particular type of adventure that we're on. And it makes sense that you would want to be looking at, you'd be wanting, wanting to look at a specialized tool for that. Just like the carburetor in your car is a specific tool that has very specific functionality. You don't want to have to go out and you know, rebuild a carburetor every time you want to drive to the grocery store. So that's where these engines come in. Now, the range from open source to, you know, quasi open to like proprietary. But at the end of the day, I think you're better off using a tool than sort of, you know, banging two sticks together in order to make fire. Capital BPM is a certified Gold partner with Camunda. When going between the different platforms, what made you nail down Camunda as the best option? Yeah, that's a great question. So my loyalty to Camunda is based explicitly only on its excellence. If it were another company that was excellent in this field. That's the one I'd be working with. But you know, I've worked with IBM, I worked with Pega I've worked with Appian. I've done a lot of different stuff in this space. And from a pure performance perspective. I don't know of any engines out there any service orchestration engines out there that are better than Camunda. What I like about it is that it's open source. So if you want to, you know, take on the feeding on the At the same time, there are SAAS offerings or it offered by command, especially with Camunda 8, where they sort of say, hey, we'll take on the infrastructure and the security and all that, you know, maintenance stuff, and you just kind of write your workflows and your processes. At the end of the day, I think the majority of the people who work in this space So, to me coded text is harder, when it gets complex, where diagrams and images are sort of how our brains are wired, right? We're, we're hunter gatherers, we think in terms of visuals, and and, you know, the ability to distinguish differences and colors and so on. So I, I feel that the ability to deal with encroaching complexity, is better dealt with with a diagram is to other code based on some acts, I'm considering Camunda, how would I go about validating its ability to help me and the issues that I'm facing? Yeah, so that's a great question. And you know, what you really got to do is you got to have a high standard. So you should be thinking days and weeks, not like weeks and months, right. So you should say, Hey, I have a test case, I want to make a call to these three RESTful services. And, you know, I expect to be so and so. And I want to deal with timeouts and escalations and routing roles and so on. And I want to get this done in like two weeks. That is an empirical test that is not subjective. And, you know, you can actually do that you could do it in like Java, or dotnet. On one side, you could do with a tool that come on and the other side, and then you see what you see, the the trick is going to be making sure that you have somebody to help you, right. So whether it's a partner like us, or you know, some expert that you know, out in the wild, bring in someone who knows how to drive this car. So you get the experience of what it's like if you had this car. Because you'll get there, you'll figure out the technology, but you're not going to know it on day one. That's not the important thing. The important thing is, and this vehicle cover the terrain that you needed to cover, and the time that you need and the safety and the security that you need. And that is an empirical question. And engineers love empirical questions, because we don't have to argue we can just see what happens. I love that approach. I love it philosophically. I love it practically. I would recommend, you know, come up with a use case, hey, I want to do these things. And then start the timer. How long does it gonna take me to do these things? You have someone who knows how to do it, and see if that works for you. be empirical. When evaluating Camunda, where does Capital BPM typically step in? So typically what we do is we help we help customers come up with a valid challenge, like, hey, we need to be able to do, I don't know, X amount of restful calls with escalations of timers and gateways and, you know, routing to specific roles within a certain amount of time, both from development amount of time and an execution amount of time, we help them articulate the problem. And then we help them come up with an objective test that determines whether it's possible to do this or not, right. And again, this can be a matter of weeks. And in those weeks, you should be able to at least a proof of concept that shows you whether it's possible to do this or it's not possible to do this Camunda is not a silver bullet, there are no silver bullets, which is a sad state of affairs, because there are monsters out there. But even as we need to be able to slay these monsters, there are practical things that we can do. And some of these practical things are just a matter of trying it out seeing if it works, and, you know, taking notes on that, but And that's we kept going up, we know this technology very well, you know, your business domain very well. We can put those together and figure out if this is a useful tool for you or not. Now, obviously, a lot of technologies will have their own weaknesses, and they won't always be perfect. So when it comes to Camunda, what is that weakness that you see? And how do you how do you tend to overcome it? Yeah, good question. I'd say the first weakness is going to be the fact that it is a different paradigm than what your normal techies are used to. Right? So you're drawing diagrams that do stuff, as opposed to writing the code that do stuff. And that does stop. And that is, you know, a fundamental paradigm shift for your traditional programmers, right? So if they can understand if they can sort of adapt to the fact that Camunda is the orchestration engine, so it says, you know, just like an orchestra conductor will say a little more violin a little bit more cello a little bit more this and that, if they understand that, that's what commanded us. But the specific thing that you're doing talking to the database, making a restful call, updating the Kafka queue, whatever that is, those things can still be written in traditional code, right? They become atomic things. And you can focus the excellence of your, the excellence of your development team on those atomic tasks, and then lead commander compose them and to a whole that I think is the strength and the weakness of it. And that is also the place where, from a mindset perspective where you need the most flexibility. So I would say that, that can be that can be a challenge.