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

41–50 of 68 posts

Re: How we built a serverless architecture with AWS

#41

Post by holoduke »

rapsey wrote: post #34
root_axis wrote: post #26

Earlier quoted context omitted.

Why do you say that nodejs is completely insecure by design and how does gcp or aws mitigate those security concerns?

Because you will inevitably have hundreds/thousands of dependencies, controlled by at least as many people, anyone of which could inject code to backdoor your server. A supply chain attack will sooner or later be the cause of a major incident.

It's the same for any other language . With java with c++, dot net, PHP and even with Erlang. None of them force you to use governed central repositories. And that's a good thing.

Re: How we built a serverless architecture with AWS

#42

Post by rapsey »

holoduke wrote: post #41
rapsey wrote: post #34

Earlier quoted context omitted.

Because you will inevitably have hundreds/thousands of dependencies, controlled by at least as many people, anyone of which could inject code to backdoor your server. A supply chain attack will sooner or later be the cause of a major incident.

It's the same for any other language . With java with c++, dot net, PHP and even with Erlang. None of them force you to use governed central repositories. And that's a good thing.

The scale is on a different level however. Your average node project will have 10/100x as many dependencies compared to other languages. Too many to conceivably check. Also due to how dynamic the language is, I think it is way easier to hide something.

Re: How we built a serverless architecture with AWS

#43

Post by Jedi72 »

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 future? What has PHP been doing for 15+ years?

Re: How we built a serverless architecture with AWS

#44

Post by antpls »

LaserToy wrote: post #11

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

Another way to phrase the question : How reproducible are architectures on AWS ?

It's the reproducible build problem again, but at the architecture/infrastructure level

Re: How we built a serverless architecture with AWS

#45

Post by zaarn »

LaserToy wrote: post #24
shiftpgdn wrote: post #21

Earlier quoted context omitted.

It's pretty obvious that someone at Amazon is watching and voting on this thread because this is absolutely true. This kind of thing is vendor lock-in to the nth degree.

Funny, right. I worked for at least 2 companies that at some point in time put a lot of money into Oracle. One of them is a leading gaming network, a lot of billions in revenue. Teams struggled with migration off it. It was a multi year/multi millions project and there is no end to it. And newcomers were saying -> oh, that was a silly idea to use all this stuff (why didn't they used Dynamo :) ), hovewer, 15 years ago…

Same reason that people think that Chrome lock-in is okay and IE lock-in was bad; the new product is shiny and has good features. At the moment.

Well, and you gotta justify that 1 million $ investment (R&D + Costs) into your AWS architecture somehow.

Re: How we built a serverless architecture with AWS

#46

Post by bzbz »

xsmasher wrote: post #37
reilly3000 wrote: post #32

How do you deal with Lambda concurrency? I have found its pretty easy to hit 1K concurrents if functions take a long time to run and receive bursty traffic.

Do you mean you don't want it to handle 1k concurrent requests (you want some to be rejected or queued instead?) or do you mean that the concurrent execution causes some other problem? (honest question, not snark)

I think they mean there’s a 1k concurrent request limit that they hit. Though the alternative would be dedicated servers and load balancers, no?

Re: How we built a serverless architecture with AWS

#47

Post by dmix »

Jedi72 wrote: post #43
dmix wrote: post #22

Earlier quoted context omitted.

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 future? What has PHP been doing for 15+ years?

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 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/

Re: How we built a serverless architecture with AWS

#48

Post by jackpeterfletch »

shiftpgdn wrote: post #21
LaserToy wrote: post #11

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

It's pretty obvious that someone at Amazon is watching and voting on this thread because this is absolutely true. This kind of thing is vendor lock-in to the nth degree.

At the most basic level, it wouldn't be a tough migration to any other FAAS. Yes it would be work, but I can't think of any other infra migrations that would be less effort.

But also you don't need to think of lambda code as code that can _only_ necessarily run on AWS Lambda.

We organize related lambdas (that would traditionally constitute an 'application') as a gradle multiproject, one module per lambda, with a common module for shared code, like DAOs. The CI creates and uploads an individual jar per Lambda, but updates them all every release.

We then have an extra module that pulls all of those together onto a web API and can be run as container independently any FAAS. At that point the fact your deploying to Lambda is basically irrelevant to your code-base, it looks and feels like any other 'application' and is probably even a little more organized.

Re: How we built a serverless architecture with AWS

#50

Post by L_226 »

reilly3000 wrote: post #32

How do you deal with Lambda concurrency? I have found its pretty easy to hit 1K concurrents if functions take a long time to run and receive bursty traffic.

You can IIRC ping support and ask for a concurrency limit increase, but probably what I would do first is try to segregate lambda deployments and API endpoints (or whatever trigger) by region so that total load is distributed (you get 1000 concurrents per region). Obviously at this point you would also profile your code to optimise function executions.
Post reply on HN