Hacker News Reader

Comment by scarface74 | Hacker News Reader

And what about the load balancers, the databases instances, the queuing system, the global CDN, the caching servers, etc? I could script my own strategy for autoscaling that integrates with metrics from the running instances, but why would I when I click on a few buttons and have autoscaling based on CloudWatch metrics, the size of the SQS queue, CPU usage etc?

But as far as "vendor lock-in", it's like developers wrapping database access up into a repository pattern just in case we want to change databases. In the real world, hardly anyone takes on massive infrastructure changes to save a few dollars.

On the other hand, there are frameworks like Serverless and Terraform to build infrastructure in a cloud vendor neutral method.

View on HN

Again each piece you have named can be done in an "older" tech which was the original point of this thread. Every few years the tech industry reinvents the same tech and a new generation of developers think mana has fallen from heaven, when in truth it is the same as the last round with new buzzwords attached.

Yes it can be done but how efficiently? I couldn't call up the netops guys to buy and provision all of the resources I needed to test scalability within the time it takes me to setup a cloud formation script.

In 2008 we had racks of servers we were leasing and that were sitting idle most of the time just so we could stress test our Windows Mobile apps.

I've been developing professionally for 20 years and 10 years before that as a hobbyist. I know what a pain it is to get hardware for what you need when your company has to manage all of its own infrastructure.

Just setting up EC2 instances and installing software on them doesn't reduce the pain by much. Sure you're cutting down on your capex but you still end up babysitting servers or doing the "undifferentiated heavy lifting", I would much rather stand up a bunch of RDS instances.

As far as serverless, why manage servers at all when you can just either create a Lambda function for the lightweight stuff or deploy Docker images with Fargate? That's just one less thing to manage and you can concentrate on development

I am not disagreeing with you that it is easier than deploying your own infrastructure. .. But, again back to my original point, lamda functions are not anything new. They are simply an http app that is "typically" responding to a single route. The API gateway is simply a configured proxy routing the "public" routes to your various "functions".

All the parts are easily replaced or scaled however you see fit. Your function can be in any language that can respond to http on any platform you want. You can put whatever proxy you want in front to define your routes. You can get as simple or complicated as you want.

Serverless is not serverless, you are just abstracted away from it.

[EDIT] I would add that personally I would spin you a cluster of Flynn on Digital Ocean :)

With serverless, you automatically get scale for each endpoint individually, not just the entire app. If for some reason you get an unexpected amount of GET request to POST requests, just the GET lambda will scale. If I tried to do the same with EC2 instances behind an ELB, I wouldn’t get the same level of granularity.

And lambdas aren’t just about responding to http requests, they are also used to respond to messages, CloudWatch events, files being written to S3, etc. I would hate to have to stand up servers for that. Even if you don’t want to get “locked in” to Lambda, why not serverless Docker?

Reply on news.ycombinator.com