 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Multicloud is a term that gets thrown around a lot in the cloud native ecosystem. Put simply, it means using more than one cloud platform as part of your IT environment. That’s typically just the start of your multipronged cloud services approach, too — there are thousands of cloud-based products that add additional functionality to the core platforms. TriggerMesh is one of them and it has targeted multicloud as a key market driver going forward. Its goal is to connect together data and services across all the different cloud platforms (and legacy IT systems too).
But how prevalent is multicloud, really? According to some analysts, multicloud is more hype than reality. So I asked TriggerMesh co-founder and Chief Product Officer Sebastien Goasguen for his take.
“It is one of those things again where [the] definition varies,” he replied. “For us, multicloud is the fact that an enterprise has different SaaS providers and infrastructure providers — for example, Salesforce, OracleDB and AWS. But for others, multicloud is about data-center workload portability. If the latter, then I agree that multicloud is not popular — most users pick one cloud and use that. But we see enterprises accelerating their move to the cloud and using more SaaS providers.”
If viewed from a SaaS [Software-as-a-Service] perspective, Goasguen thinks of multicloud as “an integration problem.” In other words, there needs to be a way to leverage the internet’s key attribute — networking — to link together disparate SaaS data. If you’re using a universal platform, like the World Wide Web, then it’s easy to link data — you just use HTTP over TCP/IP. But each cloud platform has its own way to define data and how it can be used; and sometimes it’s incompatible with other platforms.
For Goasguen and his co-founder Mark Hinkle, the solution was to adopt the serverless paradigm in cloud computing — and in particular, the Functions as a Service (FaaS) model that defined the first wave of serverless (which we are still in).
Serverless is an event-driven architecture. For instance, the leading FaaS platform, AWS Lambda, will only run code (functions) in response to events. The way in which TriggerMesh then connects services across different platforms is to “orchestrate events to stitch those services together.”
In The New Stack podcast earlier this year, Goasguen even went as far as to say that “the future of cloud native architecture […] is going to be event-driven.”
That’s a big call, considering that microservices is the prevailing architecture for cloud native applications.
“Our thinking is based on the need for scalability and the use of independent services,” Goasguen said, adding that he doesn’t pit microservices against event-driven. Instead, it’s a case of choosing the architecture that best suits your needs.
“Building a microservice based on containers is not going to help me stitch cloud services together,” he continued. “But if I can listen to events coming from Salesforce [for example], react to them and emit other events, then I can build an autonomous system whose bits scale independently and that leverages the security of best in breed services.”
Goasguen mentioned Salesforce because it’s a customer of its latest solution, an Amazon EventBridge integration that allows users to “connect virtually any non-AWS event source with AWS EventBridge.” How it works, he explained, is that TriggerMesh uses EventBridge “as a way to get to SQS [Amazon Simple Queue Service] easily, and use our partner source to proxy any events — [like] when you add customers in Salesforce.”
Other current use cases for TriggerMesh include payload delivery to multiple destinations, log aggregation and filtering, backups in data-lakes for analytics, and infrastructure workflows automation.
How easy is it for developers to achieve that kind of functionality? After all, today’s cloud native environment can be a dizzying experience for developers — which partly explains the rise of low-code. So I asked Goasguen how a developer uses TriggerMesh; is the user interface a visual tool and/or is there a lot of coding required?
“We offer both: low-level API manifests and no-code visual editor,” he replied. “We are API driven [and] all our features are accessible through an OpenAPI spec, therefore you can use TriggerMesh through the CLI [command-line interface]. Since we use Kubernetes, the Kubernetes client works well. The UI that we built on top makes use of those APIs and provides some shortcuts to build and edit some of the objects necessary to deploy integration.”
TriggerMesh uses Kubernetes’ Knative, the open source serverless framework for Kubernetes. If TriggerMesh customers want to use the “raw API,” says Goasguen, then “they need to understand how to manage k8s objects and how to write them.” But equally, customers can just use the TriggerMesh visual editor to avoid having to deal with the infamous complexity that Kubernetes brings.
TriggerMesh was among the first wave of startups to build on top of the AWS Lambda serverless platform. But as we saw with Docker, the instigating company for paradigm shifts (containers in Docker’s case) won’t necessarily become the dominant platform long-term. Kubernetes arose as an open source solution to orchestrate containers, and quickly usurped Docker’s prime position in the ecosystem. One wonders if this pattern will repeat in serverless. Will an open source platform for serverless arise and take the industry to the next level? Given that AWS Lambda has relatively limited functionality, it’s not an unreasonable question.
Goasguen didn’t answer that question, but he did point out that there is more to the serverless ecosystem already than just AWS Lambda.
“Lambda is a serverless offering that provides function hosting and is the poster child of serverless. But any cloud offering that hides the complexity of the infrastructure provisioning and scaling is serverless. [AWS] Aurora is serverless, Cloud Run from Google is serverless, TriggerMesh is serverless.”
He’s also wary of stateful serverless as a next-generation feature, as I discussed in last week’s column about Cloudstate. “Let’s keep it simple and keep the state out of it for now,” is Goasguen’s view.
Ultimately, Goasguen just wants to focus on “building plumbing” for the serverless world. He likes the Yahoo Pipes analogy for TriggerMesh. “It was a great app builder that composed the first cloud services together,” he said of the now-defunct Web 2.0 service from Yahoo. In short, he wants TriggerMesh to be the plumber for the multicloud era — it’s all about the pipes.
Episode: 115 Serverless Application Flows in the Cloud
TriggerMesh and Amazon Web Services are sponsors of The New Stack.
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
