How we built a serverless architecture with AWS
hypertrack.com
How we built a serverless architecture with AWS
1–10 of 68 posts
Re: How we built a serverless architecture with AWS
#2How does the cost of DynamoDB (and other components) compares to other options that you considered, especially at scale? Would economics works with the same architecture say at 100X scale?
Re: How we built a serverless architecture with AWS
#3How does the cost of DynamoDB (and other components) compares to other options that you considered, especially at scale? Would economics works with the same architecture say at 100X scale?
Good question. At 100x, probably not. At 10x, yes would be better than managing services on our own. By that time, we would have a better prioritized list of which services to self-manage and which ones to leave to AWS. Are you specifically concerned about DynamoDB for some reason?
Re: How we built a serverless architecture with AWS
#4How does the cost of DynamoDB (and other components) compares to other options that you considered, especially at scale? Would economics works with the same architecture say at 100X scale?
Good question. At 100x, probably not. At 10x, yes would be better than managing services on our own. By that time, we would have a better prioritized list of which services to self-manage and which ones to leave to AWS. Are you specifically concerned about DynamoDB for some reason?
How easy or hard would it be to switch to self-managed components as you grow from 10X to 100X? Quite often, they end up becoming a tech debt that remains in the back burner. Just curious.
Re: How we built a serverless architecture with AWS
#5Earlier quoted context omitted.
Good question. At 100x, probably not. At 10x, yes would be better than managing services on our own. By that time, we would have a better prioritized list of which services to self-manage and which ones to leave to AWS. Are you specifically concerned about DynamoDB for some reason?
How easy or hard would it be to switch to self-managed components as you grow from 10X to 100X? Quite often, they end up becoming a tech debt that remains in the back burner. Just curious.
Ah yes. The engineer would tell you we can move when we want. The manager would tell you it is harder than it looks. Management would tell you it will never happen. :-)
See it as reducing startup risk and deferring the payment to when you become successful and have money/time to throw at problem. Though there are best practices to do it in a clean way so moving is easier.
Do you know some known gotchas here?
Re: How we built a serverless architecture with AWS
#6Saw this post a while ago: https://medium.com/@dadc/aws-appsync-the-unexpected-a430ff71... - did you hit any limitations with AppSync?
Re: How we built a serverless architecture with AWS
#7Saw this post a while ago: https://medium.com/@dadc/aws-appsync-the-unexpected-a430ff71... - did you hit any limitations with AppSync?
We haven't hit any scaling issues yet. GraphQL is nice. It's really about getting data directly from DynamoDB and Aurora to an end point that Android/iOS/React-JS can query and subscribe to. Apache Velocity Template Language that AppSync uses is a pain though. This post captures it well (unfortunately): https://www.reddit.com/r/graphql/comments/b0zomv/aws_appsync...
Re: How we built a serverless architecture with AWS
#8This is not going to scale. Lambdas are hella slow. The cold starts will kill you.
Re: How we built a serverless architecture with AWS
#9This is not going to scale. Lambdas are hella slow. The cold starts will kill you.
You can pay to never hit cold starts..
Re: How we built a serverless architecture with AWS
#10Saw this post a while ago: https://medium.com/@dadc/aws-appsync-the-unexpected-a430ff71... - did you hit any limitations with AppSync?
We haven't hit any scaling issues yet. GraphQL is nice. It's really about getting data directly from DynamoDB and Aurora to an end point that Android/iOS/React-JS can query and subscribe to. Apache Velocity Template Language that AppSync uses is a pain though. This post captures it well (unfortunately): https://www.reddit.com/r/graphql/comments/b0zomv/aws_appsync...
AppSync does have limitations we have to contend with. Custom scalar types cannot be defined hence we are not able to define strictly typed GeoJSON objects. Apache VTL has its own learning curve; once you master it you can implement functionality without leaning on invoking lambda functions and avoid paying for their usage in high volume GraphQl call scenarios and access queried data faster.