Live data from Hacker News

Back to the '70s with Serverless

evrl.com

151–160 of 310 posts

Re: Back to the '70s with Serverless

#151

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…

I agree with pretty much your entire point.

In addition it sets up a situation of constant tension because many developers refuse to follow the fashion when they can (justifiably) say that the way they currently do things is perfectly fine.

The people on the edge of the fashion then regard them as absolute dinosaurs because they refuse to follow the trends.

Then there are people like me - I watch what is going on but I don't follow the fashions, I maintain a list of "that looks cool, check back in 18-24mths and see what they did" and then make a decision on whether it's worth spending more time actually looking at something.

https://i2.wp.com/www.business-to-you.com/wp-content/uploads... on that graph I'm a pragmatist.

Been bitten by the shiny a bit too much at this point in my career.

Re: Back to the '70s with Serverless

#152
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 a RST packet to load balancer with application servers IP address and resulting in service unavaiable errors. It took us weeks to find that out since it was happening very rarely and there were many layers between load balancer and application servers.

Network means slowness, connection errors, unknown results, etc all of which should be handled carefully.

Re: Back to the '70s with Serverless

#153
I find the observation that 'programmers' are too cheap interesting. I think this might indeed be one of the core problems. Because devs are often a bit timid and clumsy regarding the negotiation process they are taken for granted and all those hyper-complex systems are forced upon them. If devs would charge 500% more, maybe companies would opt to change their tune and give control back to the devs.

Another aspect is 'responsibility'. Most companies don't want to bear any form of 'responsibility' and therefore they late Azure/Amazon/Google take care of it. However, what they forget is that in turn, they become dependent, which is even worse.

Re: Back to the '70s with Serverless

#154
post #11

Earlier quoted context omitted.

I think what’s important to remember is that these kinds of “truth” are not the full story. Yes, a technology probably won’t live up to its marketing. Yes, what works is probably good enough. Yes, changing has switching costs and sacrifices institutional knowledge. Yes, we’ve seen these technologies before and switched away from them from various reasons. That’s all fine and sometimes frustrating as an engineer. But…

I think it's sad that the vast majority of people in our field (at least in my experience) is so damn excited about building new stuff all the time. There's no appreciation for maintaining, optimizing, and improving existing systems. There's only talk of "adding value" but very little of "keeping value." So people keep moving on to the next project, leaving the old ones running live but to rot, and at best every once…

It doesn't help if your career path in a company is tied towards 'visibility,' where certain roles will never see a promotion no matter how critical they are.

I've chosen to take on more than one heavy maintenance job, no client facing visibility in terms of fancy new features. Feedback in performance reviews would always be "it's hard for people to see what you're doing." In the end you have to find your own way to game the system to get appropriately recognised, but of course that kind of office politics isn't really what you want to spend time either.

I'm doing more 'new feature' style work now but I'm happy to not be tumbling through the waves of hype. We get a little bit of new hotness, because of course you need to embrace some aspect of that to avoid stagnating and getting too stuck in your ways, but not so much of it that the engineering team is incentivised to churn through half-assed features.

Re: Back to the '70s with Serverless

#155
post #122

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…

Does anyone know of a resource showing me some parameters for estimating how far different managed servers reach? How many concurrent users, bandwidth, etc.? Have a hard time getting a mapping for expected concurrent users -> hardware requirements. How quickly can you adjust the HW resources in a non-cloud setup if your startup product is more successful than expected?

Impossible question, it depends what your app does and what your users do. Even within the same company, 1000 concurrent users of Google Maps will use completely different resources than 1000 concurrent users of gmail. It'll even change over time for the same app and same users, as their behaviour or the world around them changes.

Re: Back to the '70s with Serverless

#156

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. Devs nowadays seem to be just NPCs, they jump on every bandwagon, it's very depressing. But this is the same with rest of society, groupthink is becoming a real problem. Unwanted opinions, thoughts are scrubbed everywhere.

Re: Back to the '70s with Serverless

#157
post #5

> 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've mentioned as much to several C-suite executives and professional venture investors I know who tend to wax philosophical about "exponential growth in cloud services and big data" and whatnot. Invariably, their response has been to tell me that I just don't get it, or that I make no sense. They give me puzzled looks and maybe even get a bit exasperated with me.

One word: Worldcom

I still remember coming up to 2000 sitting in a meeting room of an equipment provider I recently joined looking at projections of market growth, competitors and our own sales and profitability. Shortly afterwards that part of the business was sold, I remained with the other non internet part and we sailed through the .com crash unscathed.

A lot of what AWS offers makes no sense. A lot what some AWS customer's teams are building is overly complex and a horror show to maintain. But there is also value: Maintained images, backups, on demand resources and specialized resources. We hit one of the inflection points in Moore's Law and that drives us into horizontal scaling and specialized hardware.

Like with Worldcom and the fantastic internet growth story back then there is a kernel of truth and value. Find people that understand it and be glad others are playing around and subsidizing the investments in the core.

Re: Back to the '70s with Serverless

#158

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 ground up (assembler, C, hardware hacking) was starting to fade from the job market, or rather the then-new devs became eager to carve out their niche with arbitrary abstractions (but not entirely - I remember OOP bullshit from early 1990s and WS-* SOA crap from 2000s).

Re: Back to the '70s with Serverless

#160
post #141
post #43

Earlier quoted context omitted.

>"Invariably, their response has been to tell me that I just don't get it" I cured this one when my native server running on not so expensive multicore CPU with enough RAM left their cloudy setup in a dust performing more than a 100 times faster and still having huge potential reserve in vertical scalability. They were just astonished at what a single piece of modern hardware in combination with the native code could…

Congratulations, from now on you are on call 24/7 in case anything happens to that machine. It is now your own pet. When RAM fails in unpredictable random ways, you'll spend hours reading the syslogs. When your SSDs fail, you'll spend hours ordering new ones, setting raid up and migrating the backups you've had to provision, automate, supervise and secure yourself. When the server gets even remotely suspected of havi…

I always have up to date standby for a fraction of money they spend on cloud. In the last 10 years or so I do not remember RAM failing in an unpredictable ways. When/if my SSD fails It'll take me a whole 10 minutes ordering another one from amazon. Oh and I always have spares lying around. My backups are automated.

Anyways nice job advertising cloud and trying to scare people into using it. You happy with it - good for you. No need to convince me as I have my own reasons and do not have to buy into yours.

Post reply on HN