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

The Serverless Revolution Has Stalled

infoq.com

Post reply on HN
Print view View original

631–640 of 670 posts

Re: The Serverless Revolution Has Stalled

#631

Post by cmckn »

rajamaka wrote: post #291
cmckn wrote: post #187

Earlier quoted context omitted.

Couldn’t agree more, the dev experience was awful. You basically have to develop against public AWS services, my dev machine became a glorified terminal. They do seem to be iterating on the tooling quickly, but I wouldn’t use it again if I had a choice. Edit: CloudFormation was also painful for me, the docs were sparse and there were very few examples that helped me out.

> the docs were sparse Over 5000 pages of documentation https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... > very few examples that helped me out AWS provide an example for most common services, plus there are thousands of other community supplied examples out there. https://github.com/awslabs/aws-cloudformation-templates

SAM templates are a subset of CloudFormation templates; that PDF could be three times as long and still not have the content I needed.

Yes there are examples, but there wasn’t one at the time that mapped to what I was trying to accomplish. Because, again, SAM templates are not one-for-one CloudFormation templates.

I found the community around SAM to be very limited. One of the many reasons I’ve moved to the Kubernetes ecosystem.

Re: The Serverless Revolution Has Stalled

#632

Post by darkteflon »

whalesalad wrote: post #552
darkteflon wrote: post #204

Earlier quoted context omitted.

Could you elaborate on why you dislike Django? Would be great to hear from someone with extensive Python experience.

That is such a tough question to answer carte blanche. All-in-all, Django is not bad software. I have a bad taste in my mouth though because as I learned and developed new approaches to solving problems in my career I feel like Django got in the way of that. For instance, there are some really killer ways you can model certain problems in a database by using things like single table inheritance or polymorphism. These…

That's great, cheers for that. It's helpful to know that your concerns are mainly to do with taking an opinionated vs non-opinionated approach - that's a framework for thinking about the choice between Django and (e.g.) Flask that many people (including myself) can hang their hat on.

Re: The Serverless Revolution Has Stalled

#633

Post by toomanybeersies »

joana035 wrote: post #571
diggan wrote: post #511

Earlier quoted context omitted.

Reminds of something that was on the HN frontpage some month ago, where readers are not sure if it's a parody or not, because of the architecture you're required to deploy yourself to use this new "Perspective" product. Direct link to the architecture, that in the end serves the use case of generating a diagram of your AWS resources: https://d1.awsstatic.com/Solutions/Solutions%20Category%20Te... https://aws.amazon.c…

Reading this made me remember that back in the day the AWS selling point was "here you can create virtual machines with few clicks and have it instantly instead of waiting 30 min for you colocated server to be ready" but now it seems to be "here is a bunch of random expensive tools, please, produce as much stuff as possible and share the word that having servers is bad™". This field used to be inspiring, but now I se…

> not to mention the new generation being spoon fed that that is way to go

The new generation is always joining one cargo cult or another, that's why competent technical leadership is important. Remember when noSQL was the best thing since sliced bread?

Serverless can be a good option if you have large and unpredictable transient loads.

Like any architectural choice, you need to consider the tradeoffs and suitability for your use case. A TODO app probably doesn't need to be built with a serverless SOA.

Re: The Serverless Revolution Has Stalled

#634

Post by srram »

FlingBeyond wrote: post #623
nicbou wrote: post #478

I don't buy into serverless. I went to a webdev convention, and it ended up being a serverless hype train. Industry experts with a financial incentive to promote serverless went on stage and told me they can't debug their code, or run it on their machine. They showed me comically large system diagrams for very simple use cases, then spent an hour explaining how to do not-quite-ACID transactions. Oh yeah and you can o…

I believe one of the main reasons Serverless will never be more than a low-tier niche is the combination of the following: In the end, you are just renting well maintained server farms (well, a specific percentage of operational time of some of the servers in them). There is absolutely no appeal for large technology-based companies do this once they can (the following is the lowest scale example) afford to maintain t…

the flip side to your statement:smaller companies (like where I am) are not interested in maintaining our own servers and do all the un-differentiated heavy lifting related to maintaining servers. I want my small team to work on things that make us stand out. Running our own servers does not.

Vendor lock-in is not a big consideration for us. I increasingly think about cloud vendors like Operating systems. I really dont care which Linux distro we are on. Pick a vendor and run 'natively' on it to go as fast as possible.

I'm happy paying AWS for maintaining the servers and getting out of that messy business. There are other concerns about serverless around observability and managability, but vendor lockin and cost is not part of my equation

Re: The Serverless Revolution Has Stalled

#635

Post by tonfreed »

Personally I love serverless, but this article definitely mirrors my own experience.

In two jobs now I've been told to do things "serverless first" and both times I've ended up with an ECS solution. My reason always boils down to the other tooling, particularly in regards to HTTP endpoints. AWS API gateway is an absolutely infuriating product.

My current thoughts are if you're working in the AWS ecosystem, with AWS tools, Lambda works fantastically. Using Lambdas to set off alarms and run playbooks has never let me down, and I've done a lot of data processing hanging lambdas off streams and it just works. Really well in fact.

Where it falls over is interacting with the outside world in a sane fashion. HTTP endpoints are a nightmare to set up and deploy in a semi-automated fashion, I've had things that matched what was in the docs that just don't work because of some random gotcha, the undocumented silliness around a "HTTP API Gateway" vs a "REST API Gateway" is another mind bogglingly frustrating thing. Not to mention all the latency issues I've had, which are far too many to blame on a cold boot of the lambda.

Serverless has its niche and it works really well, and real cheaply to boot. But it's not a generalised tool like the loudest evangelists like to pretend it is.

Re: The Serverless Revolution Has Stalled

#636

Post by jfoster »

rzwitserloot wrote: post #477
jfoster wrote: post #420

Earlier quoted context omitted.

At the moment. Is there anything stopping an organisation from defining some standard types of serverless environments? Is there anything stopping someone from turning that standard into implementations to help cloud providers offer it, or even be a fallback option that could be deployed on any generic cloud infrastructure? I think those are the way forward from here.

> Is there anything stopping an organisation from defining some standard types of serverless environments? Yes. Basic economics. There is nothing _technical_ stopping 'an organisation' from making a federated twitter or facebook. But there are (evidently) insurmountable non-technical reasons: It hasn't happened / there have been attempts which have all effectively failed (in the sense that they have made no significa…

I think it can happen simply through one serverless offering becoming very popular and other services (or open source projects) trying to reimplement the API of that offering. To some extent, this happened with Google App Engine. (AppScale)

I think cloud customers are savvy to the lock-in. That we're having this conversation in evidence of that. Perhaps AWS can achieve adoption of Lambda without needing to cater to customers who are cautious about getting locked in, but any challenger might find that it's much easier to gain customers if they also provide some form of an escape hatch.

As Jeff Bezos would say about retail, "your margin is my opportunity."

Re: The Serverless Revolution Has Stalled

#637

Post by mjayhn »

mjayhn wrote: post #229
nullsense wrote: post #200

Earlier quoted context omitted.

CDK made IaC accessible to me. I hated raw CloudFormation and never bothered with it because of that reason. I had a crack at Terraform, but never got passed the learning curve before my enthusiasm died. Currently using some CDK in a production app and finally I found a way of doing IaC I actually enjoy.

You might really like pulumi. I'm kind of on the opposite end, ops>swe so tons of IAC and i'm using pulumi now as I'm more swe focused https://www.pulumi.com/ (ive no relation to them)

I'm late but can't edit, if anyones curious I just found a great article on it; https://itnext.io/getting-started-with-pulumi-sdk-22dc0b7ab8...

Re: The Serverless Revolution Has Stalled

#638

Post by iends »

Aeolun wrote: post #99
cle wrote: post #84

Earlier quoted context omitted.

Among other reasons, enterprises love serverless b/c it relieves them of many server maintenance costs and risks. This includes things like: - OS patches and emergent fixes - Compliance certification - SSH access control and auditing - Secret distribution - Log rotation and storage - TLS termination - Configuring and testing auto-scaling policies - Deployment configuration (rolling deploys, blue/green deployments, co…

They can do the same thing with fargate, and that’s tons easier to manage.

Fargate is still pretty expensive.

Re: The Serverless Revolution Has Stalled

#639

Post by ec109685 »

saimiam wrote: post #494
ec109685 wrote: post #361

Earlier quoted context omitted.

If your function spends 80% of its time on logic and 20% on database time, with a server app, you can get by with 200 DB connections to handle that throughout, but will need 1000 connections in a serverless setup.

I don't think connection pooling works this way. Happy to be corrected. A process is given a connection from a pool when it requests the connection and holds it until it relinquishes the connection regardless of whether the process was in the logic or data access portions of their lifecycle. It is up to you as the developer to ask for the connection and to return it on an as-needed basis...Which is exactly what you s…

Lambda does hold onto it in order improve response time. It connects to the database in a handler outside the context of a request, so you do hold onto N connections persistently (at least until the lambda scales down).

With a connection pool, you don’t need to hold onto a connection longer than necessary, but you are right that you could implement it in such a way that you hold it for life of the request.

Post reply on HN