Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we built a serverless architecture with AWS

hypertrack.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: How we built a serverless architecture with AWS

#61

Post by akishinevsky »

closeparen wrote: post #56
remify wrote: post #51

Earlier quoted context omitted.

Except now you don't need an infrastructure team. That's the whole point of serverless architecture: to be able to scale without having huge team scale as well.

You haven’t needed an infrastructure team since PHP shared hosting, and certainly not since Heroku or Elastic Beanstalk, except that people kept wanting greater complexity at lower cost. There is nothing new about “serverless” there.

There is a difference between what was then and what is today. The key difference is that the "serverless" term is massively overloaded here and once you dissect it you will see that it's a mix of multiple serverlessly managed services that we are able to take advantage of: Kinesis, DynamoDB streams, Kinesis Firehose, SNS, Lambda, Cloudwatch, and GraphQL/AppSync. Serverless computing came a long way.

Re: How we built a serverless architecture with AWS

#62

Post by kdeorah »

closeparen wrote: post #56
remify wrote: post #51

Earlier quoted context omitted.

Except now you don't need an infrastructure team. That's the whole point of serverless architecture: to be able to scale without having huge team scale as well.

You haven’t needed an infrastructure team since PHP shared hosting, and certainly not since Heroku or Elastic Beanstalk, except that people kept wanting greater complexity at lower cost. There is nothing new about “serverless” there.

Agree that serverless is a buzzword here, just as data science and machine learning have now become. It is about taming greater complexity at lower cost, and at increasingly more granular levels.

Re: How we built a serverless architecture with AWS

#63

Post by akishinevsky »

LaserToy wrote: post #11

Well, you folks now made your business super coupled with AWS. I just have 1 word: Oracle

Usage of AWS services is a conscious decision, absolutely. However, the product architecture that uses these AWS services is subject to careful review for design and functional components integrity. Any of these components must be replaceable as issues/bottlenecks are identified. For example, if AppSync is proven to have issues as the company scales further, AppSync can be replaced with self-hosted GraphQL clusters. Additionally, other components in the architecture can be similarly replaced.

Re: How we built a serverless architecture with AWS

#64

Post by akishinevsky »

leetbulb wrote: post #12

Oh boy, I bet that's costing a new car each month.

It'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.

Re: How we built a serverless architecture with AWS

#65

Post by dmix »

Jedi72 wrote: post #58
dmix wrote: post #47

Earlier quoted context omitted.

I'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 peo…

Yo 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

Even 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!

Re: How we built a serverless architecture with AWS

#66

Post by plufz »

bborud wrote: post #52

I like the idea of serverless architectures, but I still wouldn't use it for anything that is important. - Using a serverless architecture almost always implied getting married to your provider. You can run your code in only one place. You have given up all bargain power. When the relationship ends you have to build your system over again. - It isn't really serverless; they're just not your servers. - They are only e…

> Using a serverless architecture almost always implied getting married to your provider

I don’t disagree but I’ve made a web app with aws serverless. Frontend on s3, Backend Python flask on serverless and MySQL server (haven’t tried RDS serverless yet). Works fine, had a compiled library that did not work but all standard stuff. No marriage. :)

Re: How we built a serverless architecture with AWS

#67

Post by bborud »

plufz wrote: post #66
bborud wrote: post #52

I like the idea of serverless architectures, but I still wouldn't use it for anything that is important. - Using a serverless architecture almost always implied getting married to your provider. You can run your code in only one place. You have given up all bargain power. When the relationship ends you have to build your system over again. - It isn't really serverless; they're just not your servers. - They are only e…

> Using a serverless architecture almost always implied getting married to your provider I don’t disagree but I’ve made a web app with aws serverless. Frontend on s3, Backend Python flask on serverless and MySQL server (haven’t tried RDS serverless yet). Works fine, had a compiled library that did not work but all standard stuff. No marriage. :)

Then strictly speaking it isn’t serverless.

Re: How we built a serverless architecture with AWS

#68

Post by manigandham »

dmix wrote: post #22
nisten wrote: post #20

Earlier quoted context omitted.

I 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 basical…

SSR 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.

SSR is the default for the web since it started.
Post reply on HN