Quickly deploy your same Google Cloud Functions to AWS using Serverless framework.
Every major serverless cloud provider has a different approach on how to create serverless functions for different uses.
Regarding HTTP Functions Google Cloud and AWS have different ways to create a function.
In GCF your function just have two parameters (HttpRequest and HttpResponse) the way expressjs, koa, connect and other web frameworks use it. As we could see on previous post (https://medium.com/google-cloud/creating-a-mongodb-crud-backend-on-google-cloud-functions-88bb5c1cef77) Is super easy to create HTTP Functions using this approach.
AWS approach is simple too, just different. Notice that AWS Lambda supports a lot of event sources so their Lambda functions are more generic.
If you start writing your HTTP serverless functions for AWS it could be harder to migrate them to other providers later. (Not impossible, just harder), but, going from GCF to AWS is actually pretty simple thanks to a couple libraries like serverless-http (https://www.npmjs.com/package/serverless-http) and expressjs (https://expressjs.com/) itself.
Lets assume we already have a GCF on index.js named handler (like shown before), lets create another file with the AWS handler:
Putting it in a different file helps avoid touching the original GCF function.
The serverless.yml file needed to deploy using the serverless (https://serverless.com/) framework could be like this:
Once this two files are in place, we can just:
$ serverless deploy -v
Now we have the same function running on AWS Lambda.
Paths, paths, paths…
So far our HTTP functions have been working on a URL provisioned by the cloud platform.
This URLs contains paths into the infrastructure, but, what if we want to serve several routes on the same function?
Anything after the provided URL path is passed down in req.url and req.method
You can do string comparisons to route your functions internally or you can use a library like microrouter https://www.npmjs.com/package/microrouter and compose them very similarly to the way expressjs does.
Breaking free from vendor lock-in
I personally, don’t believe in the vendor lock-in argument some people used to minify the future impact of the serverless approach. How different is this to provision servers on EC2 or DigitalOcean, or build a whole infrastructure exclusively with AWS services (DynamoDB, Kinesis, SQS, etc.) At the end what you really need is to be able to move your services from one provider to the other, without affecting your users of course.
Find a common ground develop from there, make sure you can switch providers with little or no effort and you will be fine.