Discuss deployment strategy about open-api HOT 13 CLOSED

I don't think FaaS is going to be any cheaper actually. Lets stick to DO instances for now. I would prefer having a container setup though to be independent of the DevOps a little and be able to have a CI - CD pipeline.

from open-api.

I forgot, for the very early product prototype demos, I am thinking Heroku should be fine? Nope?

from open-api.

I don't think FaaS is going to be any cheaper actually.

That's a really interesting statement, what is that based on?

I would prefer having a container setup though to be independent of the DevOps a little and be able to have a CI - CD pipeline.

Absolutely.

I forgot, for the very early product prototype demos, I am thinking Heroku should be fine? Nope?

No preference between Heroku or DO, but I suggest we deploy to which ever one we will use in production so don't have refactor our deployment pipeline too much.

from open-api.

I don't think FaaS is going to be any cheaper actually.

We have an average concurrents ~400 at any point of time or in other words about 2000+ daily actives.

So, I believe that running off a cheaper $10-20 DO instance theoretically will be cheaper if we can cache anything and everything that's not dynamic data in an ideal world.

from open-api.

Currently we use a couple or more of costliest instances on the production server and perhaps a mid one on beta.

from open-api.

P.S for the DB we might just be going for a managed cluster instead of out current DO setup.

from open-api.

Based on that information it's hard to say what is most cost efficient.

I'll leave some datapoints here: https://aws.amazon.com/lambda/pricing first 1M requests are free, then you start paying 0.20$ per 1 million requests. That does however does not account for extra costs you'll incur for Cloudfront (CDN), S3 buckets for static assets, Redis instances and your databases. Those Redis and database instances need to run continuously and will add significant costs.
I only have experience with RDS (Postgres in our case) and DynamDB, very performant and zero to no operational costs.

In regards to Heroku, I have limited experience, I found the DX really really great, but things got expensive very quickly when the project got more mature.

2 questions for you:

• production is DO, so let's do DO then, agreed?
• how does your deployment pipeline for prod look like, are there any parts that would be good for us to re-use?

from open-api.

After meeting with @QuincyLarson and @raisedadead the agreement is that we will deploy to AWS. In the light of that decision I suggest considering:

• Using Lambdas, which complicates deployment but is very cost effective and scales rapidly.
• Using AppSync, this requires a spike to see if there is a fit. It is currently in preview but if it can prevent us from having to maintain both code and deployment logic, and will lessen the amount of AWS infrastructure / artefacts to manage it is worth considering.

The main argument against Lambdas without AppSync is that support for subscriptions (https://github.com/facebook/graphql/blob/master/rfcs/Subscriptions.md) is a bit of a pain; Lambdas are short running and to have subscriptions work you'll have to jump through some hoops to support them. I've seen write ups using AWS IOT ( https://serverless.com/blog/serverless-notifications-on-aws/ ) or Cognito and SQS ( https://serverless.com/blog/how-reuters-replaced-websockets-with-amazon-cognito-and-sqs/ ).

There is a promising example combining running Apollo serverless, in combination with AppSync at https://github.com/serverless/serverless-graphql MongoDB support is not available yet, but should be doable.

I suggest we spike serverless / Appsync to see if we can bend it to our will. If not we can go for plain Apollo, running in container or as a Lambda.

/cc @QuincyLarson / @Bouncey / @jrogatis

from open-api.

FYI I'll spend some time doing a small spike running Apollo server from a Lambda (using https://www.npmjs.com/package/apollo-server-lambda) with MongoDB.

from open-api.

And any alternates to Mongo? I don't want to be using Dynamo because that will lock us to AWS.

from open-api.

Maybe my last comment was unfortunately phrased; I plan to spike Apollo, using (not against) MongoDB, and serve it using Lambda. Should we decide give Lambda a miss, much of that code will be re-usable.

Your raise an interesting point about vendor lock in.

We could write most code to be completely platform neutral, allowing us to switch between cloud providers as we please. However that does come at a cost. A real cost in the form of a monthly bill -it's hard to beat Lambda pricing, and an operational cost.
The same fear existed at my previous employer, we decided to embrace the platform and have not looked back since.

If this is something the team would like to flesh out I'd b happy discuss some options during a meeting.

from open-api.

@ojongerius @raisedadead I'm reviewing this issue in real time with @Bouncey so I speak for both of us here.

On the topic of whether Lambda would be cheaper - it would almost certainly be cheaper based on my understanding of how it would work. First, to give what @raisedadead said about having a lot of users, freeCodeCamp has more than 50,000 unique users a day - many of whom are unauthenticated, and some of which are blocking Google Analytics (so we infer this from network traffic).

@Bouncey pointed out, that a vast majority of calls to our current production app (https://www.freecodecamp.org) are calls to fetch HTML. With the new React-based app, there would be far fewer of these calls per user.

from open-api.

Closing this one off, during a conference call we all agreed that we will spike Lambda, and possibly AppSync.

from open-api.