Enterprise technology needs to help organizations take action in real-time. Doing this effectively means modernizing application architecture from batch processing to event-driven. Serverless computing is an event-driven architecture that abstracts infrastructure so developers can focus on writing the application code.

We think serverless is only the beginning.

The real power comes from what serverless enables. Serverless architectures allow even the largest enterprises with years or decades of legacy code to break out of the constraints of their own data centers and a single cloud. Open source, standards, and specifications free enterprise developers to mash-up services from on premises and any cloud to rapidly compose event-driven applications that respond to the need for high velocity so you can bring new features and products to market fast.

In our view, for enterprises to succeed in a hybrid world that moves at breakneck speed, they need platforms that harness the power of the following five trends:

• Serviceful (not just serverless)
• Mashable‍
• Open‍
• Kubernetes-based‍
• Event-driven

We call this combination the SMOKE stack and we think it will power the next generation of cloud native applications. This blog, excerpted from our new SMOKE Stack Whitepaper, looks at where we see each of these five trends going in the near future.

Serviceful, abstracting the cloud

The cost savings, scalability, and reduction in operational complexity from serverless are real. Digital publisher Bustle experienced approximately 84% cost savings by moving to a serverless architecture, Thomson Reuters processes 4,000 requests per second with serverless, Major League Baseball Advanced Media ingests, analyzes, and stores over 17 petabytes of data a second (https://aws.amazon.com/solutions/case-studies). And these are just a few of the more notable highlights. For us, the question is not “why serverless”, but rather, why aren’t enterprises using it more?

We see serverless as much more than a FaaS offering. To us, serverless is the only infrastructure model that will support the event-driven future we expect. We do not accept the notion that to take advantage of serverless, all your applications must be in the cloud, or in a certain cloud. Our goal is to extend the reach of serverless to every application running anywhere – on-premises, cloud, and SaaS – so developers can forget about infrastructure and focus on building the application flows their businesses need.

Mashups, integrating across cloud services

We call TriggerMesh a cloud native integration platform. The same way Boomi lets knowledge workers use data across all their disparate applications, TriggerMesh empowers developers to leverage services from any on-premises application or any cloud service to build event-driven applications.

TriggerMesh Bridges

The workhorse of the TriggerMesh solution is our serverless event bus that consumes real-time events from everywhere and uses them to trigger functions on any FaaS or Kubernetes cloud, or in clouds like Twilio.

Bridges is the name we use for these application flows built on top of Kubernetes. They represent an extensible framework for building application flows from any app to any other app. Built as an API extension to Kubernetes, a Bridge is a single manifest that contains an arbitrary number of components, each of which must be a valid Kubernetes object.

Event Sources for bridges can be legacy systems (VMware Vsphere, IBM MQ, Solace, OracleDB); AWS services; custom applications (e.g. eCommerce platforms); and source control and other popular cloud apps, such as Twilio and Confluent. Developers use the TriggerMesh Controller to compose Bridges out of our growing library of Sources, Brokers, and Targets, or they can define their own.

Open, removing barriers for integration

In the past, companies could build a business around a strong open source core product without a large platform company introducing the same product as a service. Today, however, this seems to be the norm.  

Competitors have always been legally allowed to offer another company’s OSS product as a service. We’re witnessing the rise of highly-integrated providers taking advantage of their unique position to offer “as-a-service” versions of OSS products, and offer a superior user experience as a consequence of their integrations. We’ve seen it happen with Amazon’s forked version of ElasticSearch, which Salil Deshpande neatly described in TechCrunch as both “self-interested and rational.”

To respond to this breed of competitor, companies like CockroachDB adopted an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license. Other companies like Confluent and Elastic have done the same.

Kubernetes, for cloud portability and scaling

TriggerMesh provides developers with automation to simplify building application flows on Kubernetes. By providing a bridge from legacy applications to Kubernetes, we streamline many low value activities so developers can easily do cloud native in a hybrid and multicloud way.  

For instance, Red Hat OpenShift customers can use the TriggerMesh Operator to configure their OpenShift workloads to respond to events from practically any SaaS, cloud, or on-premises application. Using our Open Source Knative Lambda Runtime (KLR), you can deploy Lambda functions on Google Kubernetes Engine. In an excellent Medium article (reposted with permission on the TriggerMesh blog), Suganya, a Cloud Architect at Searce Engineering, provides a detailed technical write-up of how she and her team used KLR to help a client migrate from AWS to Google Cloud.

With TriggerMesh, you can copy and paste the exact same yaml manifest from Google Cloud Run directly into TriggerMesh and you get the same running service. This is the power of portability and standardization that Knative makes possible. But it doesn’t necessarily make it easy.

TriggerMesh goes further and simplifies creating hybrid applications flows. With TriggerMesh you can select from our growing library of event Sources, Brokers, and Targets to compose application flows – what we call Bridges – regardless of where the Source and Target are deployed. And if we haven’t yet added the source or target you need, you can create it once and then add it to your private repo for reuse by your colleagues.

Event-Driven Architecture, for automation

Some of the more common EDA use cases include stream processing, data integration, and customer journey mapping. If we look at data integration, you may have a primary product database on-premises, maybe in an OracleDB. But you’ve migrated ERP to the cloud, and you run Salesforce. An event-driven application flow to integrate these systems would benefit the entire organization so that, whenever there is a new price in the product database, this triggers an event that is consumed by the ERP systems for forecasting and by sales for RFPs and quotes.

As described earlier in this paper, we use the term Bridge to describe event-driven application flows composed in TriggerMesh. Just like physical bridges that connect otherwise isolated areas into a fluid whole, TriggerMesh Bridges link otherwise siloed services into composable, flexible, scalable, and cost-effective EDAs.

TriggerMesh Cloud presents users with a growing catalog of Bridge templates ready out of the box. For example, we have a Bridge that reacts to the creation of Zendesk tickets and performs sentiment analysis on them using AWS Comprehend. The result of this sentiment analysis is then used to tag the tickets and route them back to Zendesk for triage and follow-up.

We have a Bridge to connect events from an on-premises OracleDB with Zendesk and the Oracle Cloud functions. This is very applicable for modernizing ecommerce applications by integrating with SaaS and cloud services.

Another Bridge connects Slack with a Confluent cluster. And yet another sends Microsoft Azure activity logs to Splunk, allowing an organization to use Splunk’s powerful analytics and visualization to monitor activities in their Azure subscriptions and respond quickly to any abnormal activity. You can see how to create, use, and configure these Bridges in our YouTube Tutorial playlist.

With TriggerMesh, developers can build event-driven, cloud native applications that link public cloud services with on-premises and private cloud workloads.

We believe this is the most pragmatic way for companies to continue leveraging high-investment, on-premises systems while also accelerating the move to cloud for digital transformation.

The SMOKE stack, we believe, represents the best answer to the question on the mind of every architect – how can we be ready for anything?

For the complete SMOKE Stack story, download the whitepaper.