101–110 of 310 posts
Yes, serverless shares some conceptual similarities with older development models.
However, the tooling, infrastructure, languages, and general support for server less as a productive model make these conversations seem naive and mostly just "old man yells at cloud".
I am an old developer, and comparing platforms like vercel and netlify functions to 70's mainframe dev is just dishonest.
Earlier quoted context omitted.
> There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. I dunno, the first company I worked at was very small, under 30 people, sales included, and I was hired on as an SA. If they were using serverless, they would not have needed to hire me. Deployments and system upgrades were very toilsome. The dev…
You don't even need serverless for those things. Any of the automated deployment/orchestration systems in the last ten years solve those problem (ansible, terraform, etc).
Don’t get me wrong—serverless platforms are not a ci-cd silver bullet. Many organizations build pipelines on top of serverless deployment apis, but it certainly does take care of a lot of things for you—not to mention other features mentioned elsewhere in my comments
Complexity is a difficult topic, not the least because the many ambiguous meanings it has taken on. When people bring this up, they talk about it like it's a fixed thing that could go to 0 if only someone actually tried hard enough. Yes, complexity is a problem, but that complexity is always increasing is inevitable as long as technology advances. The first episode of the 70s series "Connections" comes to mind. We need to be able to identify and eliminate waste while dealing with this fact.
Earlier quoted context omitted.
Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…
Yes, "the cloud" is bunk from any technical point of view. It exists to shift CapEx to OpEx for accounting. Any technical considerations are a distant third place on the list.
Earlier quoted context omitted.
> There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. I dunno, the first company I worked at was very small, under 30 people, sales included, and I was hired on as an SA. If they were using serverless, they would not have needed to hire me. Deployments and system upgrades were very toilsome. The dev…
> Deployments and system upgrades were very toilsome. The dev lead would spend a few hours deploying new code and we’d only do it around midnight in case there was a problem (our customers were almost entirely US based). I spent a lot of my time automating OS upgrades on the web servers behind our proxy. All of this work would be unnecessary for that small company if they were using serverless. Not using serverless d…
> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…
I find your quote here and the follow up seriously unconvincing. You know what a miserable workflow is? Preparing all my build scripts according to the half baked build tool that our in-house Deployment team cooked up to use fabric to spray my deployment onto a bunch of nodes in our data center, all the tests and script linting pass, so then I go push it through our CI/CD pipeline (which can’t do the above tests for…
Are all the commenters in this thread just cynical engineers who really can't see past their own narrow world view? I get snake oil is snake oil, but there is such a strong brand of "anything new must be snake oil" that runs through the HN community it boggles my mind.
The world is actually full of complex systems. And only once these systems are in place does the software engineer get to do his work! People on this site act as if they have all the understanding and knowledgeable necessary to decry something like cloud vendors because clearly these same people know better than everyone else and these are actually simple problems if only we had their perspective and knowledge.
The ego and arrogance of people in tech really shines through here.
> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…
> You’d have to pay engineers to build the same systems provided by serverless if you want smooth deployments and high availability. Also, imagine if you wanted to start operations outside of the continental United States. You’d need to find a data center provider, buy machines, pay someone to install them (and hope they do it correctly), and then, when ever you have a technical problem, you need to email the datacen…
I think you are miss understanding my comment. I was comparing serverless to colo because that’s essentially what the author was doing. I agree that there are plenty of other cloud compute solutions that work for many workloads.
> There's like 20 other things you need for a functioning product, many of which literally cannot be replaced by Serverless-anything
I totally agree. Serverless is usually just a piece of infrastructure that is combined with other resources like databases, batch clusters, blob storage, vms, etc. I don’t think you’d be able to create a very interesting app using stateless functions alone, though I could be proven wrong ;)
Technically, XML has entities (text substitution variables) and entity references, along with a evolved infastructure to share declarations and declaration sets via parameter entities. Of course, that doesn't help with tools such as maven which outright forbid use of entities and use their own ad-hoc mechanism for reuse. Technically, this makes a pom.xml non-XML-compliant, but in any case, whining about XML pointless when the creators should rather blame themselves for using XML in the first place, and then using it inappropriately.
As to FaaS, I don't see the problem with CGIs; they've stood the test of time with ultra-robustness and uptimes in the range of years and decades, including service updates with zero downtime by virtue of Unix processes being detached from their binaries (unlike Windows processes). Also, since you can run CGIs as one-shot invocations on the command-line, developer feedback as postulated in TFA is excellent. Of course, CGIs itself use environment variables rather than function or command-line arguments, so their lifecycle is bound to Unix processes. What helps is to use wrappers rather than coding to CGI specs directly; we had this in 2007 already with SCA (service component architecture). Maybe it's time to refresh SCA with new bindings for AMZN and other proprietary FaaS to bring back the portability we valued highly in pre-Cloud times?
> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…
And cloud debugging has its issues too: I remember endless fudging with print statements, deploying once more and waiting for the changes to propagate in a AWS lambda handler, because the bloody thing simply wouldn't run locally.
> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…