Live data from Hacker News

Back to the '70s with Serverless

evrl.com

171–180 of 310 posts

Re: Back to the '70s with Serverless

#171

One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven. The thing about fashion is that the way if develops is largely arbitrary. Changes in fashion resemble a drunken walk through possible design space with the drunkard receiving regular shoves from "influencers" who are usually trying to…

This is something that annoys me, exhausts or worse. The amount of time wasted on bikeshedding and chapel wars is draining. I appreciate craft a little more because tooling and practices are more stable. You focus on work and not how to work.

Re: Back to the '70s with Serverless

#172

Earlier quoted context omitted.

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…

This is the type of cultural accuracy I've been looking 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 d…

> The ego and arrogance of people in tech really shines through here.

You mean, "the ego and arrogance required to bend code and machines to their will and not the other way around". Maybe try to pass that and learn a thing or two.

Re: Back to the '70s with Serverless

#173

One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven. The thing about fashion is that the way if develops is largely arbitrary. Changes in fashion resemble a drunken walk through possible design space with the drunkard receiving regular shoves from "influencers" who are usually trying to…

For a latecomer, you've managed to see through a lot of bullshit, and the psychological/sociological nature of it. What you're maybe missing is that's not always been like that. Cloud, SaaS is only a thing since around 2006 when AWS hit the scene big time. Before that, we had a relatively conservative, standards-driven perspective on progress. Maybe it's also the time when the generation having learned computing from…

The abstractionists, philosophers, theoreticists, had their days before too (60s-70s Lisp, 70s-80s Logo for teaching children). So in fact the practicalists would only have ruled in and around the 90s.

If we add all the "everything is a XXX" languages (XXX in [list, string, object, function ...]) and gather all simplificationists together, then they almost always were there, with fluctuant success at being prominent.

Re: Back to the '70s with Serverless

#174
post #17

My company is migrating a huge monolith to microservices. One of the proposed benefits is that it makes end to end testing easier because each service only interacts with a couple other services, so each service will be easier to write integration tests for. But in the monolith, those services communicate over interfaces, and are currently tested as unit tests! So we're replacing unit tests with integration tests and…

If one part of the application needs to be changed frequently and/or is used by other applications, then it makes sense to separate it as a microservice. However, for other parts, I think it might be better to stay as a monolith since when you have a network in your calls, things get messier. Networks are unreliable even if it is your local area network. In my career I saw some unrelated network equipment was sending…

Not sure if rate of change truly matters. In my opinion, microservices make most sense when dealing with multiple team. It's much easier to update core services when everyone depends on it through the network, rather than requiring people to redeploy their stuff. If you're a single team operation, it's not really a problem if all your stuff runs in a single process. It may even benefit you in terms of performance and scalability, to be honest.

Re: Back to the '70s with Serverless

#175

One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven. The thing about fashion is that the way if develops is largely arbitrary. Changes in fashion resemble a drunken walk through possible design space with the drunkard receiving regular shoves from "influencers" who are usually trying to…

This is something that annoys me, exhausts or worse. The amount of time wasted on bikeshedding and chapel wars is draining. I appreciate craft a little more because tooling and practices are more stable. You focus on work and not how to work.

[deleted]

Re: Back to the '70s with Serverless

#176

One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven. The thing about fashion is that the way if develops is largely arbitrary. Changes in fashion resemble a drunken walk through possible design space with the drunkard receiving regular shoves from "influencers" who are usually trying to…

> One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven.

It's not “purely fashion driven”, it's just that (1) as solutions radiate out from their point of origin understanding of the problem, how the solution addresses it, and what caveats the user should be aware of gets (on average) foggier, and definitely more unequally distributed, and (2) there are real network effects in software development where being popular genuinely makes things better, all other things being equal (from a business perspective, a technology for which you can get people that are proficient and comfortable is better than one you can't, other factors being equal.)

Re: Back to the '70s with Serverless

#177
post #140
post #135

Earlier quoted context omitted.

> virtually infinite auto scaling Ah, the bullshit. When we showed GCS engineers our hadoop workload, their eyes went really big and told us that they don't have that kind of capacity in a single AZ.

Then you are working at hyperscale yourselves already, and there are maybe 50 organisations like you out there. Maybe. Right now I don't think that there is a single telco that has the scale to break GCP, or a single manufacturing company (exempt Tesla) or a single energy company. Or bank. I agree that pharma, social media and streaming may do this. But since Netflix is on AWS I am doubtful of the last.

i think you greatly misunderstand the size of some telco's and Infrastructure providers.

also, some manufacturing giants are truly enormous..

samsung for instance makes everything from smartphones to artillery installations..

same goes for hyundai, mitsubishi etc..

Re: Back to the '70s with Serverless

#178
post #67
post #17

My company is migrating a huge monolith to microservices. One of the proposed benefits is that it makes end to end testing easier because each service only interacts with a couple other services, so each service will be easier to write integration tests for. But in the monolith, those services communicate over interfaces, and are currently tested as unit tests! So we're replacing unit tests with integration tests and…

Reminds me of the tweet - we replaced our monolith with Microservices so that every outrage is like a murder mystery

Presumably you intended outage, but outrage also fits and is poetic in its own manner.

Re: Back to the '70s with Serverless

#179

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

Why is the alternative to serverless, colocating servers in a DC? The alternative is renting VMs from those same clouds. It works fine and is cheaper when you work on software that actually has users. It also doesn't result in the cloud provider cramming a crappy under-baked programming model down your throat. Per request pricing and "scaling to zero" is just old fashioned unbundling. You are selling a smaller quanti…

The best alternative IMHO is to just rent machines in DCs, it's cheap and powerful and you don't have to manage the hardware: https://oneprovider.com/dedicated-servers-in-north-america

Re: Back to the '70s with Serverless

#180
post #84

Earlier quoted context omitted.

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

Yeah it’s true but it requires a lot more config. The job I mentioned in my comment involved thousands of lines of anisble to perform operations you wouldn’t even need to consider/could perform in a few clicks when using a serverless platform. 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…

You're supposed to encapsulate those in reusable roles, see an example methodology here: https://yourlabs.org/posts/2020-02-08-bigsudo-extreme-devops...

And since we have containers it's become really much easier actually ... Deploy a Traefik container which will watch dockerd socket and self-configure HTTPS and all when your other script starts container. Really, it's much easier than back in the days: https://github.com/jpic/bashworks/tree/master/vps

Post reply on HN