Serverless Event Gateway | Hacker News Reader

Serverless Event Gateway

serverless.com

72 pointsrmason20 comments

Somewhat OT: I want to create an auth system (username, password, login, logout) using a serverless architecture with Cosmos DB as data storage. Each user will have it's own document and logging in will set a flag in that user document, or maybe in a session document. Login with Facebook would also be nice. Anybody know of such a pattern or best practices?

There is a great authentication boilerplate that is set up for AWS. It might not be so hard to extend it for other platforms. Here is a blog post I did showing how to use the boiler plate with FaunaDB for authentication and authorization.

https://serverless.com/blog/faunadb-serverless-authenticatio...

Thanks, this is the kind of stuff I was looking for.

BTW, I looked a bit at FaunaDB pricing. If I understood corectly, 1 mil requests costs $10.

In Cosmos DB, also if I understood corectly, 1 month of 400 req/second, so 400 x 86400 x 30 ~= 1 billion requests costs $25.

I don't know much about FaunaDB, and very likely you can't compare things the way I did, for once, Cosmos DB has separate storage costs which seems included in FaunaDB, spikes in usage require extra provisioning in Cosmos, but it's still a 3 orders of magnitude pricing difference. I'm not saying you're not worth it.

The big question is whether you have traffic that is steady state or spiky. Steady state traffic is more economical to service with FaunaDB Enterprise on your "own" hardware. But then it is not fully managed.

That said, our goal is never to have a customer turn away because of price, so reach out at chris@fauna.com and I can take a look at your numbers more closely.

Doesn't sound particularly challenging from a serverless point of view, if you have some sort of central Cosmos DB instance. Wrap it all in a Lambda function.

If Cosmos DB is not a requirement, AWS Cognito is a cheap and headache-free option that covers all other requirements, including the FB login.

Thanks, at first look seems useful and the pricing is great. Cosmos DB is a requirement, but not for the actual storage of the session or user data (I realize I wasn't very clear in the original description) so I might make the two work together.

Have you looked at Azure AD? Seems like it would do what you want if I'm understanding correctly

Auth0?

I looked into that previously. It's beautiful, exactly what I would need, but also very very expensive.

Ah annoying I never paid the bill.

Where would the event gateway be deployed? It looks like it could be any provider and anywhere right? Essentially, giving me the ability to take my entirely serverless architecture and giving me servers to manage. Alternatively, it may be a Kubernetes type deployment. OR, what my guess is, the first step towards getting people to use the serverless platform, which will handle hosting this for us.

Yes, they're planning a hosted version in addition to the open source version.

The real huge importance of event gateway is that we can finally debug and run integration tests locally.

Not a mention of this in the article..

Im wondering what are the use cases here. Why someone would keep different functions in different providers while she requires the communication between them.

The example given at the emit conference was: You have a lot of code running in AWS, but all of a sudden, you would like to start using some nice features around google ML, and for this you need integration with google cloud.

Over a longer period, the idea is that there is an oligopoly of PaaS providers and if their features don't match 1:1 perfectly, your business may need a hybrid approach.

> The example given at the emit conference was: You have a lot of code running in AWS, but all of a sudden, you would like to start using some nice features around google ML, and for this you need integration with google cloud.

I'm at the conference, and this isn't a great example. You don't need to set up a Google Cloud Function to use the Google ML APIs (or pretty much any Google APIs), you can just use them over the REST API.

Multi-cloud use case has a very niche use. I have a very few clients that use multi-cloud strategy but when they do it's very structured. Certain workloads use certain providers and those services have auxiliary services that reside very near for performance and cost efficiencies. But yes I agree. Not the best example.

- I'm a the conference as well

I think an advantage could be if you wanted to push the message from a lambda function into a google cloud pub sub topic which a google cloud function would consume possibly?

I'm not entirely sure myself, a few guesses.

  * Cost based configurations
  * Putting high compute in one cloud and storage in another? 
  * Perhaps to handle entire cloud outages? 
  * There may be features that don't exist across all the providers that people may want to take a dip into.
  * Integration w/ existing frameworks, AKA code deployed to multiple clouds that need to be supported.

Reply on news.ycombinator.com