6 ms·
Oh boy, I bet that's costing a new car each month.
by leetbulb 7y ago
Oh boy, I bet that's costing a new car each month.
- brad0 7y agoIt all depends on how much data they're processing. It looks to be mostly a pay-per-use model. I'd say their big cost is Kinesis and potentially API Gateway. Lambda is great for this kind of workload (mostly).
- kdeorah 7y agoTop 3 are EC2, DynamoDB and Lambda.
- brad0 7y agoI don't see EC2 in your architecture diagram. Where are you using EC2? How are you structuring your dynamo tables? Is there one table that is used much more than another?
- kdeorah 7y agoNot using EC2 directly, though AWS breaks that down cost with a line item for EC2. Many tables in DynamoDB. Two out of those are most used (equally).
- nisten 7y agoI used to hate aws for how expensive their bandwidth and storage was, until I started actually using it last year. I think their new serverless stack is about to leave a lot of devops out of a job. You can setup a a CI/CD pipeline in about half an hour with amplify, at the previous company I remember it taking a good 3 weeks to get CircleCi up and running properly. And then moving a microservice over to it is basically 1 command, a few options, mostly just copy over the config from your old express backend with a few changes, and you're done. It's insane. One other dev I've showed the lighthouse scores of the react stack I deployed on it even said "this should be illegal". And they're right, it's pretty much automated devops, the whole ap now loads in 300ms. If you have server side rendering in your app the static content will automatically be cached on their CDNs. And if you want to save a bit of money you can just use google firebase for your authentication and db. GraphQl is surpsingly a breeze too as a middle layer if you want to leave your java or .net backend apis untouched. At the end of the day, nodejs is completely insecure by design, your infrastructure will never be as secure as running it on gcp or aws. That's why you go serverless and stop messing with security and front end scalability. If they solve the cold-start issue of databases on aurora they will completely dominate the market even more than they already have.
- dmix 7y agoSSR is going to do wonders for page load times on the internet as it finally gets popular via React/Vue. I hope it's the future for all of these heavy-weight user-facing JS apps.
- Jedi72 7y agoSSR is the future? What has PHP been doing for 15+ years?
- dmix 7y agoI'm talking about Next.js/Nuxt.js style JS front-ends replacing exactly that plus JS heavy frontends like Angular and SPA react apps which was the last decade's modus operandi. The way SSR hooks React/Vue into these JS apps "hydrating" them after loading prerendered component based views...to make them interactive without losing any performance compared to static HTML, is unique and extremely powerful, which most people don't understand until they do it. It really is the future of frontend development. SSR combined with async loaded chunked bundles of components is far more than prerendering some server side Web apps templating library with full HTTP requests in between. All the power of a full fledged SPA but with none of the performance or SEO downsides with automatic offline + service worker caching. It's great for the webs future. https://ssr.vuejs.org/ https://ssr.vuejs.org/
- Jedi72 7y agoYo dawg I heard you like job security, so we put a program in your program, now you you can render while you render More seriously, I do understand the difference, but disagree with the whole approach in 95% of cases
- dmix 7y agoEven the Haskell people are adopting SSR’d JS-heavy frontends (Miso, Purescript, etc) for their web apps. That’s when you know it’s mainstream. Good luck with PHP!
- akishinevsky 7y agoIt's very easy to incur high costs here. We implemented cost analysis dashboards that allow us to monitor costs per each event, device, with visibility into each AWS service we use, with charts showing historical data. Fiscal planning is now part of our architecture design and implementation.