When we started TriggerMesh in September in 2018, Sebastien and I thought we’d be primarily managing the lifecycle of serverless functions to start. At the time that was a valid hypothesis. Knative was new on the scene and Google even quoted him in their announcement as he was the author of Kubeless and had extensive experience with Kubernetes. We knew orchestration was table stakes but it’s probably wouldn’t be the real problem cloud native users needed to solve.
Almost two years later we have been watching the cloud native landscape evolve rapidly. We think we see the future. That future involves cloud services that are loosely coupled beyond any single ecosystem and not only interact in the cloud but with legacy systems. That’s the key, in the future we know that the cloud services will be the default way to develop applications but there’s always going to be laggards. We believe that for companies to provide truly robust digital experiences they need to take care of multiple cloud services from multiple providers (AWS, Twilio, SendGrid, Google, and many others) and combine them into cloud native applications that consume cloud services and application events from legacy applications alike.
Everyone interested in serverless has seen the scores of greenfield successes (Netflix, Lego, iRobot) These folks have shown that at serverless at scale can hold many advantages. Though these examples are simply the tip of the iceberg. We foresee a future where enterprises that have massive IT investments can integrate their legacy on-premises architecture with the cutting edge cloud technologies. Not only will they consume both on-prem and cloud but multiple clouds.
In the Flexera 2020 State of the Cloud Report, 93% of large enterprises are saying they are multi-cloud.
I’d venture to guess that close to 100% have legacy data centers that would be advantageous to integrate with cloud services too.Also in the same report, we see that participants want to optimize existing use of cloud, migrate workloads to the cloud, move on-prem to SaaS, Implement CI/CD. All of these use cases are
These are initiatives that TriggerMesh can help with.
Up until now, it’s been relatively easy to connect cloud services in a single ecosystem like Amazon Web Services. AWS, in particular, has done an amazing job connecting services and automating triggers by using Amazon EventBridge within their own cloud. As of late, they have also been working with vendors to become Lambda Ready so vendors can interact with AWS Lambda. We believe that this is the right design pattern but the future involves connecting virtually any service to any event source. That is why we are really excited about EveryBridge and TriggerMesh Bridges.
The EveryBridge serverless event bus consumes real-time data from legacy event sources (VMware Vsphere, IBM MQ, Solace), AWS sources, custom applications (e.g. eCommerce platforms), and source control and other popular cloud apps, and uses them to trigger functions on any FaaS or Kubernetes cloud. Developers and Architects use the TriggerMesh Controller to compose Bridges out of our growing library of sources, brokers, and targets.
Today we are launching TriggerMesh EveryBridge Beta, we feel like this is a very functional and production-ready beta for many users. However, we need your help to kick the tires and tell us what you need to get to 1.0. So we would be grateful for any users who chose to login and use the TriggerMesh Cloud and give us your feedback and impressions.