 Greetings from Los Angeles, Lisa Martin here with Dave Nicholson. We are on day three of the Keeves Wall-to-Wall coverage of KubeCon Cloud NativeCon North America 21. We're pleased to welcome Mark Hinkel to the program, the co-founder and CEO of TriggerMesh. Mark, welcome. Thank you. It's nice to be here. Love the name. Very interesting. TriggerMesh, talk to us about what TriggerMesh does and what, when you were founded, and what some of the gaps were that you saw in the market. Yeah. So TriggerMesh, actually the genesis of the name is in cloud event-driven architecture, you trigger workloads. So that's the TriggerMesh and then Mesh, we mesh services together. So that's why we're called TriggerMesh. So we're a cloud-native open-source integration platform. The idea is that the number of cloud services are proliferating. You still have stuff in your data center that you can't decommission and just wholesale lift and shift to the cloud. So we wanted to provide a platform to create workflows from the data center to the cloud, from cloud to cloud, and use all the cloud-native design principles, but not leave your past behind. So that's what we do. We are cloud operators and developers, and we wanted the experience to be very similar to the way the DevOps folks are doing infrastructures code and deploying that. We want to make it easy to do integration as code. So we follow the same design patterns, use the same domain language as some of those tools like Hashicorp's Terraform, and that's what we do and how we go about doing it. When were you guys founded? September 2018. I'm sorry, you're young. You're three years young. Three years. It feels like 21 in start-up years. I bet. It's a lot of this happened, but yeah, my co-founder and I were former early cloud folks. We were at cloud.com, worked through the OpenStack years and CloudStack, and we just saw the pattern of abstraction coming about. So first you abstract the hardware, then you abstract the operating system, now with the Kubernetes container evolution, you're abstracting it up to the application layer, and we wanted to be able to provide tooling that lets you take full advantage of that. So being founded in 2018, what's your perception of the shift that happened during the pandemic in terms of the drive towards cloud adoption and the demands for services like you provide? Yeah, I think it's a mixed blessing, so people became more remote. They needed to enable digital transformation. Biggest thing I think for us is, you don't go to the bank anymore, and the banking industry is doing exponentially more remote online transactions than in person, and it's very important. So we decided that financial services is where we were gonna start with first, because they have a lot of legacy architecture. They have a lot of need to move to the cloud to have better digital experiences, and we wanted to enable them to keep their main frames online while they were still doing cutting edge, mobile applications, that kind of thing. And of course the legacy institutions like the BMAs, the Wells Fargo's, they're competing with the Fintechs, who are much more nimble, much more agile, and able to sort of disrupt the financial services industry. Was that part of also your decision to start in financial services? It was a little bit of luck, because we started with our network, and it turned out, we saw, we started talking to our friends early on, because we're a startup, and said, this is what we're gonna do. And where it really resonated was, PNC Bank was one of our first customers. Another financial and regulatory company was another one, a couple banks in Europe, and we, as we started talking about what we were doing, that we just gravitated there because they had the biggest need. Even though everybody has the need, their businesses are critically tied to digital transformation. So starting with financial services. It's counterintuitive, isn't it? It is counterintuitive, but it lends credibility to any other industry vertical that you're going to approach, doesn't it? It does. It's a great, they are gonna be our hardest customers, and they have more at stake than a lot. Like transactions are millions and millions of dollars per hour for these folks. So they don't wanna play around. They have no tolerance for failure. So it's a good start, but it's sort of like taking up jogging and running a marathon in your first week. It's very, very grilling in that sense, but it really has made us a lot better and gave us a lot of insight into the kinds of things we need to do from not just functionality, but security, and that kind of thing. Where are you finding these customers with respect to adoption of Kubernetes? Are they leading? Are they knowing we've gotta get there eventually from an infrastructure perspective? So the interesting thing is Kubernetes is a platform for us to deliver on. So we don't require you to be a Kubernetes expert. We offer it as a SaaS. But what happens is that the Kubernetes folks are the ones that we end up really engaging with earlier on. And I think that we find that they're in this phase of they're containerizing their apps. That's the first step. And then they're putting it on Kubernetes. And then their next step is a security and integration path. I think they call it, and this is my buzzword of the show, day two operations, right? So they get to day two and then they have a security and integration concern before they go live. So they wanna be able to make sure that they don't increase their attack face. And then they also wanna make sure that this newly deployed containerized infrastructure is as well integrated as the previous you know, virtualized or even you know, on the server infrastructure that they had before. So TriggerMesh doesn't solely work in the containerized world. You're sort of, you're bridging the divide. Yes. What percentage of the workloads that you're seeing are the result of modernization and migration as opposed to standing up net new application environments in Kubernetes? Do you have a sense for that? I think we live in a lot in the brown field. So, you know, folks that have an existing project that they're trying to bridge to it versus the green field kind of, you know, the huge wins that you saw in the early cloud days of the Netflix and the Twitter's doing scale. Now we're talking to the enterprises who have, you know, they have existing concerns. So I would say that it's mostly people that are, you know, very few net new projects unless it's a modernization and they're getting ready to decommission an old one, which is- So brown field financial services, you just said, you know, let's just go after that. You know, yeah. I mean, we had this dartboard and we put up buzzwords, but no, it was actually just, and you know, we're still finding our way as far as early on, we're open source folks and we did not open source from day one, which is very weird when everybody's new year identity is, you know, I worked, I was the VP of marketing for the Linux Foundation and Node.js and all these open source projects. And my co-founder and I are Apache committers and our project wasn't open yet because we had to get to the point where it could be open and people could be productive in the use and contribution and we had the staff up engineers. And now I think this week, we open sourced our entire platform and I think that's gonna open up, you know, that's where we started because it was not necessarily the lowest hanging fruit, but the profitable, most profitable lowest hanging fruit was financial services. Now we are letting our code out into the wild and I think it'll be interesting to see what comes back. So you just announced that this week, Trigermesh integration platform as an open source project here at KubeCon. What's been some of the feedback? It's all been positive. I haven't heard anything negative. We did it, so we're very, very, there is a very, the culture around open source is very tough. It's very critical if you don't do it right. So I think we did a good job. We used a OSI approved open source license, the Apache software V2 license. We hired someone who was well respected in the DevRel world from a chef who understands the DevOps sort of culture and methodologies. We staffed up our engineers who are going to be helping the free and open source users. So they're successful and we're betting that that will yield business results down the road. And what are the two I see on your website, two primary use cases that you guys support? Can you dig into details on that? So the first one is sort of a workflow automation and a really simple example of that is you have a something that happens in one cloud. So for example, you take a picture on your phone and you upload it and it goes to Amazon. And there is a service that wants to identify what's in that picture. And once you put it on the line in the internship parlance, you could kick off a workflow from TensorFlow which is artificial intelligence to identify the picture. And there isn't a good way for clouds to communicate from one to the other without writing custom blue. Which is really what we're helping to get rid of is there's a lot of blue written to put together cloud native applications. So that's a workflow, triggering a serverless function as a workflow. The other thing is actually breaking up data gravity. So I have a warehouse of data in my data center and I want to start replicating some portion of that as it changes to a database as a service. We can, based on an event flow, which is passive, we're not making, having a conversation like you would with an API where there's an event stream that's like drinking from the fire hose and trigger meshes the nozzle. And we can direct that data to a DBAS, we can direct that data to Snowflake, we can direct that data to a cloud-based data lake on Microsoft Azure, or we can split it up so some events could go to Splunk and all of the events can go to your data lake or some of those things can be used to trigger workloads on other systems. And that event-driven architecture is really the design pattern of the individual clouds. We're just making it multi-cloud and on-prem. Do you have a favorite customer example that you think really articulates the value of that use case? Yeah, I think PNC is probably our, well, for the data flow one, I would say we have a regular Oracle and one of their customers. It was their biggest SMB customer of last year. The Oracle cloud is very, very important, but it's not as, doesn't have the same level of tooling as a lot of the other ones. And to close that deal, their regulatory customer wanted to use Datadog. So they have hundreds and hundreds of metrics. And what TriggerMesh did was ingest the hundreds and hundreds of metrics and filter them and connect them to Datadog so that they could use Datadog to measure, to monitor workloads on Oracle cloud. So that would be an example of the data flow. On the workflow, PNC Bank is probably our best example. And PNC Bank, they want to do, I talked about infrastructure code, integration is code. They want to do policy is code. So they're very highly regulated. And what they used to do is they had policies that they applied against all their systems once a month to determine how much they were in compliance. Well, theoretically, if you do that once a month, it could be 30 days before you were out of compliance. What we did was we provided them a way to take all of the changes within their systems and forward them to a serverless cluster. And they codified all of these policies into serverless functions. And TriggerMesh is triggering their policies as code. So upon change, they're getting almost real-time updates on whether or not they're in compliance or not. And that's a huge thing. And they have, within their first division, we worked with tens of policies. Throughout PNC, they have thousands of policies. And so that's really gonna revolutionize what they're able to do as far as compliance. And that's a huge use case across the whole banking industry. That's also a huge business outcome. Yes. So Mark, where can folks go to learn more about TriggerMesh? Maybe even read more specifically about the announcement that you made this week. So TriggerMesh.com is the best way to get an overview. The open source project is github.com slash TriggerMesh slash TriggerMesh. Awesome, Mark, thank you for joining Dave and me talking to us about TriggerMesh, what you guys are doing, the use cases that you're enabling customers. We appreciate your time and we wish you the best of luck as you continue to forge into financial services and other industries. Thanks, it was great to be here. All right, for Dave Nicholson, I'm Lisa Martin coming to you live from Los Angeles at KubeCon and CloudNativeCon North America 21. Stick around, Dave and I will be right back with our next guest.