Virtually any time you choose a solution in IT, vendor lock-in is a consideration. Arguably vendor freedom and interoperability across cloud services are key success factors. As is the case with cloud native applications they are often becoming an aggregation of many serverless functions. As these applications increasingly combine serverless functions it is likely they will exist in multiple clouds and on-premise.
The DevOps culture espouses things like automation, measuring, and sharing. Automation is critical. Ideally, you should be able to check out a function from source control, build and implement that function on the cloud of your choice or on-premise. You should build pipelines that are not only able to deploy to the cloud provider you use today as well as tomorrow. You must have the option to easily target other serverless infrastructure in the future if your needs should change.
The TriggerMesh Serverless Management Platform integrates full-lifecycle management of your functions-as-a-service giving you the ability to target the cloud or on-premise, giving you a degree of freedom to deploy serverless functions where and when you want.
One of the most significant sources of lock-in is cloud-specific services. For example, some cloud provider’s data storage solutions have been labeled a “roach motel” because it’s easy to get data into the cloud but hard to get it out in bulk due to asymmetrical data transfer charges. Other offerings offer inexpensive hosting but offer higher cost value-added services that can make cheap serverless hosting very expensive.
Serverless functions rely on triggers from events that may or may not be readily available in your cloud. For example, a function in Amazon Web Service Lambda may add a customer to a mailing list, but the customer data may need to propagate to Salesforce’s Heroku. Or a function on Google Cloud Platform may rely on unstructured data Microsoft Azure Cloud blob. Within one cloud infrastructure, like Amazon Web Services Lambda, you may integrate with Amazon Kinesis or Amazon SQS to trigger AWS Lambda functions, but these services may not span cloud silos.
TriggerMesh provides a way for those event sources to trigger functions in another cloud. This cross-cloud event bus meshes multiple clouds and enables cloud native applications to take the best features of all clouds.
As we looked at trends in serverless cloud computing, we know that multicloud is a consideration for many enterprises. In a recent study by Mesosphere, they note that the use of multiple clouds is growing. We can infer that while there is a trend toward multicloud usage for reasons of feature/functionality, price, and redundancy. Many users are running snags with cross-cloud adoption including different runtimes and lack of tooling to efficiently deploy to the serverless infrastructure that makes the most sense for their use case.
Source: Mesosphere, September 2018
ServerlessDays CoFounder, Paul Johnston wrote in a blog post last year one of the biggest pitfalls with cross-cloud serverless:
…to build a cross-cloud solution, you would need to build abstractions above the cloud to essentially standardise the event creation and ingestion as well as the services that you need. Unfortunately, building abstractions can be hugely time consuming and counter productive. When you’re talking about functions, one of the keys is limiting the addition of libraries. Adding abstraction libraries means the function isn’t as small as it could be and could easily remove some of the value of functions. Those abstractions also will often provide either inefficient code, or bring in technical debt with code that other people create. This technical debt means that we won’t have learned the lessons we’ve previously added in with frameworks becoming stale and bloated over time.
We believe the key to multicloud serverless management is to codify event sources and make them available to functions across multiple clouds. TriggerMesh provides the ability to add to a library of event sources that can be consumed by any function, on any cloud, or on-premise acting as a cross-cloud event bus for messages and triggers.
The way to avoid serverless cloud lock-in is to create a complete lifecycle management plan that allows you to deploy to multiple clouds and on-premise. Key elements of this lifecycle include integrating with source control systems, taking advantage of build technologies that span various cloud architectures. Over the next couple of months, we’ll be expanding our products and likely launching more products and services to help users take advantage of multicloud/hybrid cloud environments.
If you’d like to participate in our product roadmap, we encourage you to join our Early Adopters Program