Getting started with GCP: A hassle

Serverless Framework
1

Hello everyone.

I took a deep dive into Serverless yesterday and basically spent my day on the examples. It took me a while to understand that the GCP support was fairly new and incomplete. It wasn’t obvious to me that the configuration file serverless.yml would be so different depending on the providers. I therefore spent quite a lot of time trying to mix examples I found with AWS which aren’t compatible at all with GCP, like for instance the handler: handler which is rather handler: index.handler using AWS.

There are no plugins for Google on the repository either: https://github.com/serverless/plugins or if there are, it’s hard to figure out which ones.

So, after many hours wasted, here are the following things I advise to improve:

  • Tag the Serverless plugins to make it easier to know for what platform they are compatible with.
  • Make it obvious that GCP are fairly new and not still in Beta, and lack documentation/example. For instance, there is no equivalent of the serverless.yml format for GCP like there is for AWS and that would be very useful.
  • People will eventually run into plugins or code example about AWS, so giving some head on about the major differences in the serverless.yml is a must have. I’m thinking about the main for GCP when not using a index.js file, this isn’t an issue with AWS to change the filename, but it requires a special configuration change in GCP which leads to misunderstanding and frustration. Also, the format to be used to declare function handlers should be clearly explained.
  • An equivalent of Serverless Offline (https://github.com/dherault/serverless-offline) for GCP should be released ASAP (or update the repo to add GCP support), because when you’re starting playing around and are waiting 40s-1mn between every change in your app, it’s a mood-killer. I personally looked directly into how to run it locally, found serverless-offline and after much doc reading, understood that I couldn’t use it. Then looked for a GCP version and found none and got very disappointed because Serverless is not actually usable without being able to play around. There is a lot of new stuff and waiting a minute to see our changes feels just wrong. I do understand that not everything can be mocked though, but there are a lot of mistakes at the beginning and having such a long deployment time make the learning curve increase way too much IMHO.
  • Google Functions only handle node 6.11, and that’s also where Serverless can be quite useful by providing a easy-to-use plugin like ES6-8 transpilation or typescript like there are for AWS.

Currently, I’ve reached a point where I believe Serverless is an awesome solution, but still to young to be used with GCP (and, let’s be honest, GCP is also really young and lack a lot of features, which doesn’t help Serverless to shine either). So I’m currently waiting for my AWS account to be enabled and I’ll likely host my code on AWS instead of GCP but only because Serverless isn’t ready for it yet. (and hope it becomes mature enough before the end of Amazon free trial)

Also, Serverless takes pride by being Provider agnostic, but that’s just a marketing lie. It’s true in the sense that it’s not strongly coupled to any provider and can be used with any, but it’s a lie because you can’t just switch to one provider to another without going through huge and deep changes in both your configuration and source code, depending on what you do.

I hope this helps focusing on the right things to improve GCP support.

1 Like
2

Thanks for your detailed feedback @Vadorequest-SL.

First of all, the Serverless Framework is an opensource softweare, and the community plays a big role in maintaining it. Secondly, the provider integrations are implemented as plugins which are owned and managed by the corresponding provider companies. GCF and Azure plugin implementations are not as full featured as the AWS one. It is also due to the fact AWS is the most popular cloud provider and that implementation is more developed.

Having said that, I agree we have room for improvement. And, you can help us improve the docs or help with issues if possible. It is opensource after all :wink:

I therefore spent quite a lot of time trying to mix examples I found with AWS which aren’t compatible at all with GCP, like for instance the handler: handler which is rather handler: index.handler using AWS.

Not sure if you saw this page, but the nuances of the handler and the index.js file is documented. If you have any suggestions to improve that, I can help you with that.

There are no plugins for Google on the repository either: GitHub - serverless/plugins: Serverless Plugins – Extend the Serverless Framework with these community driven plugins – or if there are, it’s hard to figure out which ones.

AWS is the most popular provider and hence most of the community writes plugins for AWS. Not much we can do there. We will update the plugins page as and when we find any plugins for other providers. If you are interested in helping out with a plugin, please let me know and I can help.

Tag the Serverless plugins to make it easier to know for what platform they are compatible with.

Will work on adding tags in the plugins repo to clarify the cloud provider.

there is no equivalent of the serverless.yml format for GCP

Will work on a page that describes serverless.yml for other providers. There is page for Spotinst since the provider worked with us on the docs. If you are interested to help with the definition, please let me know.

An equivalent of Serverless Offline (GitHub - dherault/serverless-offline: Emulate AWS λ and API Gateway locally when developing your Serverless project) for GCP should be released ASAP

It is a community project and you can request the author for a GCP version. You can use sls invoke local command to test your code locally, but it is not a replacement for the offline plugin.

Currently, I’ve reached a point where I believe Serverless is an awesome solution, but still to young to be used with GCP (and, let’s be honest, GCP is also really young and lack a lot of features, which doesn’t help Serverless to shine either).

We agree with your statement. That is mostly the reason why the focus has been on AWS. As GCF is still in Beta, not many people are building on it, so there is no community support.

Also, Serverless takes pride by being Provider agnostic, but that’s just a marketing lie. It’s true in the sense that it’s not strongly coupled to any provider and can be used with any, but it’s a lie because you can’t just switch to one provider to another without going through huge and deep changes in both your configuration and source code, depending on what you do.

The reason why the framework is provider agnostic is because it providers a standard workflow across providers for developing and deploying your serverless applications e.g. sls create -> sls invoke local -> sls invoke -> sls deploy. The serverless.yml preserves commonality in sections, but some granular rules are different as they are controlled by the cloud providers. Just switching the provider attribute in the serverless.yml file to make it work for different providers, was never a goal for the framework, and is not feasible at the moment.

But, we are working on several things that will help:

a) Universal Function Signatures: Will allow you to write your functions in one generic way, and will be translated into provider’s version on deploy.
b) CloudEvents: Standardize the event schema between providers, so that event communication and passage across providers is easily achievable.
c) Event Gateway: A communication hub for events across providers. It is API gateway + pub/sub in one place.
d) Composability via Components: Implement a component based architecture for creating composable applications.

Thank you for your feedback. I really appreciate it and I would be glad to help you out. I will invite you to our Slack channel.

Thanks,
Rupak Ganguly
Serverless Inc.

1 Like
3

Hello @rupakg and thank you very much for your fast feedback.

Not sure if you saw this page, but the nuances of the handler and the index.js file is documented. If you have any suggestions to improve that, I can help you with that.

I did see it, but it’s not made obvious enough the differences between google and AWS. Because when I ran into other examples (in plugins, etc.) I forgot about that index file thing and saw handler: index.first and alike, which eventually confused me until I re-read that page later on.

AWS is the most popular provider and hence most of the community writes plugins for AWS. Not much we can do there. We will update the plugins page as and when we find any plugins for other providers. If you are interested in helping out with a plugin, please let me know and I can help.

Indeed, community-leaded. I’m not “interested” by writing a plugin right now, got stuff to deliver and can’t focus on that.

Will work on adding tags in the plugins repo to clarify the cloud provider.
Will work on a page that describes serverless.yml for other providers.

Great! Thanks

We agree with your statement. That is mostly the reason why the focus has been on AWS. As GCF is still in Beta, not many people are building on it, so there is no community support.

I think you should just clarify that GCP is still in beta and doesn’t provide as much features as AWS does, so that developer don’t fall from their expectations. It’s fine to have a beta version, just make it clear :wink:

Just switching the provider attribute in the serverless.yml file to make it work for different providers, was never a goal for the framework, and is not feasible at the moment.

That’s what one could understand from provider agnostic, I understand it’s not a trivial thing to do, and is probably impossible to reach a 100% cross-compatibility between providers configuration file.

a) Universal Function Signatures: Will allow you to write your functions in one generic way, and will be translated into provider’s version on deploy.
b) CloudEvents: Standardize the event schema between providers, so that event communication and passage across providers is easily achievable.
c) Event Gateway: A communication hub for events across providers. It is API gateway + pub/sub in one place.

:+1:

d) Composability via Components: Implement a component based architecture for creating composable applications.

I have to say I don’t really understand what that does/mean. :slight_smile:

One more things I noticed and didn’t quite understand (and not related to GCP/AWS) is the signature of the functions. Most of the time we see the usual request, response, but sometimes we see something like request, context, callback and I didn’t understand where that came from, is it related to the event gateway? (I guess I just went through a lot of stuff at once and got confused)

Thank you again for your detailed answer.

4

Hi, can you please share any github code to get started with serverless with google cloud functions, as I also wish to do this.

5

@PhilAndrew I totally missed your post, sorry.

I personally switched to AWS since then, mostly due to the lack of SLS-GCP support/features. I therefore haven’t used SLS with GCP for any real project.

I kinda hoped the GCP support will increase within the next few months and switch back to GCP later (mostly due to the pricing), but now that I’m using AWS and so many of their tools I doubt I’ll have the courage/time to switch over to GCP, once everything is in place.

6

You will callback in Node.js code since it supports callbacks or async requests. Most of the statically typed compiled languages like C#, Java, Go will have the request, response signature. Hope that clarifies it.

7

I actually think the difference was because of the provider, most examples were with AWS, some with GCP and both may not have the same signature. Not 100% sure about it but that’s what I eventually figured out, if I recall correctly!

8

Before I begin - I’m using serverless on fairly complex app in production using AWS and I have a great experience so far.

BUT

Making serverless work for Google is next to impossible for any non hello world setup. I’ve wasted a fair amount of time on trying to do so and Im not planning on trying it again.

Serverless works for any infrastructure as long as you only use AWS.

9

Hey @AdamZaczek,

I am planning on integrating Serverless Framework for our GCP CF production environments. What issues did you run into when using SF for GCP? The documentation seems to be fairly complete and straight-forward… is it performance / errors?

Regards,
Adrian