Serverless is a growing trend in cloud computing, and it’s leading to a quiet revolution in how we mix and match data across the internet.
The name itself is a misnomer because physical servers still exist (way down the stack, in massive data centers located in places like Nevada and Oregon). But in the serverless realm, developers don’t have to worry about that. The servers have essentially been abstracted away, via products like AWS Lambda, Google Cloud Functions, Azure Functions, and Knative (an open source option).
As Amazon Web Services puts it, “serverless allows you to build and run applications and services without thinking about servers.” Its own serverless offering, AWS Lambda, has a pay-as-you-go model for compute time — you pay only for the compute time you use, not for data usage or server space.
The currency of serverless computing is the “event”. Whenever there is an event trigger, your code runs, you pay your pennies, and a function executes.
This is a simple process if all your events are on the same cloud platform, but that’s becoming less common thanks to another emerging trend: multicloud. Increasingly, developers need to create apps that interact with events and run functions across multiple cloud environments.
Enter TriggerMesh. It describes itself as a “cloud native integration platform,” meaning it provides a bridge between different clouds, SaaS services, and legacy systems. Sebastien Goasguen and Mark Hinkle started the company in 2018, with the aim of building “serverless tooling and infrastructure that we thought would dovetail with where the industry was going.”
Goasguen and Hinkle foresaw that applications would need to be increasingly portable, as the number of cloud platforms grew and the business opportunities to integrate with services on other platforms expanded accordingly.
TriggerMesh was built on top of the open source Knative, which itself was built on top of Kubernetes. Knative is focused on deploying and managing modern serverless workloads, whereas TriggerMesh focuses on the application layer. Or as Goasguen put it, when TriggerMesh launched in November 2018, “helping people deploy functions and link them via events to build the new Cloud native applications.”
The Lego analogy is sometimes used by Kubernetes experts to try and explain our current era. In a recent InApps Context podcast, Goasguen said this:
“Kelsey Hightower [a Kubernetes evangelist from Google] used to mention that with Kubernetes you were playing Legos. […] the blocks that we’re playing with — the big Legos — are libraries that we’re using, they’re actually the cloud services. It’s your machine learning, it’s your analytics platform, it’s your transaction platform, your conversational tool — right? So you have those building blocks, and you need to compose them.”
Goasguen noted that it’s straight forward to “compose” your app from all those building blocks if you “stay within one cloud.” If you use AWS, for instance, you can use Amazon’s serverless products (EventBridge and Lambda) to build your app.
But that’s increasingly not the world developers are living in. Often they need to use a block that either lives in another cloud (one of Google’s cloud-based machine learning services, for example), or on-premise (Goasguen cited the example of an Oracle database running in-house).
“So when you need to bridge those blocks,” explained Goasguen, “[…] that’s where you start needing to rely on events, and you need to define that event flow.” He believes that “the future of cloud native architecture […] is going to be event-driven.”
In a way, TriggerMesh is like a modern-day version of a classic web 2.0 mashup service. Indeed, in an article on InApps in late January, co-founder and CEO Mark Hinkle compared TriggerMesh to Yahoo Pipes, a data mashup service from Yahoo that ran from 2007 to 2015.
Yahoo Pipes was much simpler to conceptualize than TriggerMesh because it directly touched the data sources. With Pipes, you tapped into information from web sources via APIs and RSS feeds. Using a drag-and-drop user interface, you could then define rules for that data (for example, filter it by a keyword). This process was made even easier by the ability to re-use “pipes” from other users. As I wrote on ReadWriteWeb in February 2007, when Yahoo Pipes launched:
“You can either create a new pipe from scratch, using the nifty visual tool or browse through existing pipes and select one that strikes your fancy. You can also ‘clone’ a pipe, and make your own adjustments. Then click on ‘Run this Pipe’ to see the results.”
Back then, the building blocks of Yahoo Pipes were APIs and RSS feeds — data sources that were (at the time at least) rich sources of information. Pipes made it easy to link together those “blocks” of data, and then you could manipulate it using operators like “filter” and “sort”.
As Hinkle noted in January of this year, Yahoo Pipes was “a good example of filtering all the data to get down to what you want, so that you can trigger your function.”
It’s important to note that Yahoo Pipes was launched in a simpler time, long before Kubernetes and containers made apps an abstract construct. It was also a more optimistic time, for the internet and for the web in particular. In 2007, it was thought that tens of millions of APIs and RSS feeds would become available for people (and apps) to use as they saw fit. The data would — it was believed at that time — be easy to get to, and easy to use (and re-use).
Well, it didn’t quite pan out that way. Soon the web reverted back to walled garden platforms like Facebook and Twitter, where data flows were tightly controlled. To this day you cannot export a full copy of your friends’ data from Facebook. As for RSS, Facebook completely routed around it — creating its own proprietary, algorithm-driven “news feed” of data for users.
So the vision for an Open Web of mashups never became a reality. After sputtering along for a few years into the Facebook era, Yahoo Pipes was finally shut down in 2015.
Fast forward to the current era, where there are petabytes of useful data on the internet — far, far more than was available a decade ago. Much of it lives on the cloud; or more precisely, across multiple clouds.
To get at that data and all its associated services, you need cloud native tools that enable you to connect to it — and use it — no matter where everything lives. That’s part of what TriggerMesh is trying to accomplish, along with managing and linking together functions.
The user interface of TriggerMesh and other modern tools isn’t a simple drag-and-drop, as it was with Yahoo Pipes. But at least developers don’t have to grapple with the infrastructure anymore, if they don’t want to, thanks to serverless technologies.
In summary: While the world of online mashups made easy via open APIs and RSS feeds is long gone, a whole new world of cloud mashups has opened up.
TriggerMesh and Amazon Web Services are sponsors of InApps.
Feature image via Pixabay.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Hightower.
