Back to the '70s with Serverless • Hacker News Board

Re: Back to the '70s with Serverless

#201

Post by aflag » Sun, Dec 20, 2020, 12:54 PM UTC

reader_1000 wrote: post #181

aflag wrote: post #174

Earlier quoted context omitted.

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…

Rate of change may matter when your monolith application takes too long to deploy (i.e a big war application with lots of initializations at start), although rolling updates may help here. It will also be easier to rollback if things go wrong. On the other hand, I agree with your point of multiple teams. I tried to mean same thing with "used by other applications"

How long are you talking? I can't think of a process I've ever worked on that took more than a few seconds to start. As you say, if you have any sort of rolling deployment mechanism the start time of your application is somewhat irrelevant. Unless your application takes a massive time to start, it seems like the wrong thing to optimise for. Surely you only deploy things a few times a day, if that, and hopefully most deployments don't require rollbacks.

Also, with the current network speeds and memory availability, it's hard to imagine the war size to be a bottleneck in web development.

Depending on other services via a well defined network interface is good for decoupling teams. So it depends on the number of employees you have coding for the same platform, rather than on clients or anything like that.

Re: Back to the '70s with Serverless

#202

Post by tsss » Sun, Dec 20, 2020, 1:08 PM UTC

mattmanser wrote: post #8

cs702 wrote: 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…

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…

> by not having "devops"

Apparently, you don't even know what that word means. You can not "have" DevOps. It's a methodology and not a thing. Besides, DevOps means exactly the opposite of what you are implying: it is the practice of not having a dedicated operations team and letting devs handle as much of the operations for their own applications as they can.

> few minutes per month

I can tell you my team spends a good 30% of its time on operations. Some of that (for example adminstrating K8S clusters) could be offloaded to cloud providers for money.

Re: Back to the '70s with Serverless

#203

Post by Aeolun » Sun, Dec 20, 2020, 1:17 PM UTC

tinco wrote: post #197

bob1029 wrote: post #185

Earlier quoted context omitted.

I dont understand why business leaders cannot see this for what it is and take back some control. Investors need to start asking more probing questions about how organizations develop and deploy applications. Perhaps if the money becomes contingent, people will start to give a shit about the engineering quality. At no point should "fun" be a line item when determining what technology to select in a high stake environ…

Because all the shiny new things make promises. From larger talent pools in node.js, to cheaper scaling with kubernetes. They all talk to business leaders in terms they understand. Also, this is a fundamental property of innovation, innovation usually is made possible by the new and shiny things. I run the software side of a hardware startup, and I wouldn't have been able to run such a complex software system with su…

> From larger talent pools in node.js, to cheaper scaling with kubernetes.

Larger pools of people, and cheaper infrastructure.

Not necessarily talent and cheaper scaling in my opinion.

Re: Back to the '70s with Serverless

#204

Post by hyperman1 » Sun, Dec 20, 2020, 1:18 PM UTC

afarrell wrote: post #195

hyperman1 wrote: post #189

Earlier quoted context omitted.

Too true. On my job we have frameworks from the Architects, and stuff that drips in from outside. The Architects typically buy some Framework from a Trustworthy Enterprise, as approved by the Gods of Gartner. Quality varies wildly, but if you move half a mm from the beaten path you're on your own. I gain a thumbleweed badge on stackoverflow every time I deal with their stuff. Compare it to outside world stuff. Qualit…

If you found yourself using a boring, proven, working technology ...how vividly would you remember that experience?

You would have a feeling of trust.

As an example: I click on a browser icon and I get a working browser with a predictable behaviour.

One day, chromium edge took over, messed up a ton of settings,and kept on blathering about my experience. 5 minutes of filling out a work sheet changed to 30 minutes of whack a browser.

My amicable brotherly feelings of good that day did not extend to the average Microsoft employee.

Re: Back to the '70s with Serverless

#205

Post by Aeolun » Sun, Dec 20, 2020, 1:19 PM UTC

afarrell wrote: post #195

hyperman1 wrote: post #189

Earlier quoted context omitted.

Too true. On my job we have frameworks from the Architects, and stuff that drips in from outside. The Architects typically buy some Framework from a Trustworthy Enterprise, as approved by the Gods of Gartner. Quality varies wildly, but if you move half a mm from the beaten path you're on your own. I gain a thumbleweed badge on stackoverflow every time I deal with their stuff. Compare it to outside world stuff. Qualit…

If you found yourself using a boring, proven, working technology ...how vividly would you remember that experience?

My experience using PHP at my previous company stands out because it was so relatively glorious.

Re: Back to the '70s with Serverless

#206

Post by xnx » Sun, Dec 20, 2020, 1:20 PM UTC

mattmanser wrote: post #8

cs702 wrote: 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…

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…

I sometimes think of how far we still are from utility-quality computing services. Every company needs electricity with near-perfect uptime, but almost no company has a full-time electrician in-house.

Re: Back to the '70s with Serverless

#207

Post by knight2002 » Sun, Dec 20, 2020, 1:20 PM UTC

DON'T MISS OUT. Hurry and earn Money/Ethereum by clicking on Ads on Telegram!!!

https://t.me/ETH_Ads_jp_bot?start=1498941506

It's definitely worth the effort so why not just give it a try ....Promotion ends soon so DONT GET LEFT OUT...Click on the link, join and start earning.

https://t.me/ETH_Ads_jp_bot?start=1498941506

Re: Back to the '70s with Serverless

#208

Post by Aeolun » Sun, Dec 20, 2020, 1:22 PM UTC

qz2 wrote: post #194

1337shadow wrote: post #167

Earlier quoted context omitted.

True story: last "AWS Solutions Architect" I met told me "AWS is a sect and I am part of it", I'm still not convinced it was meant as a joke!

There are a lot of religious followers of the one true AWS way of thinking. I dared bitch too loudly about SES delivery policy once and said to look elsewhere and earned the ire of the architectural elite. This is insane because I'm certified too but a non believer, a concept which does not compute for a lot of people.

You don’t believe in AWS? Or not in SES, because I feel like they still win in general ‘want to recommend’.

Re: Back to the '70s with Serverless

#209

Post by [deleted] » Sun, Dec 20, 2020, 1:23 PM UTC

tsss wrote: post #202

mattmanser wrote: post #8

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…

> by not having "devops" Apparently, you don't even know what that word means. You can not "have" DevOps. It's a methodology and not a thing. Besides, DevOps means exactly the opposite of what you are implying: it is the practice of not having a dedicated operations team and letting devs handle as much of the operations for their own applications as they can. > few minutes per month I can tell you my team spends a go…

[deleted]

Re: Back to the '70s with Serverless

#210

Post by ai_ja_nai » Sun, Dec 20, 2020, 1:35 PM UTC

(Crossposting from Disqus).

I think I am gonna take this with a grain of salt, meaning as the rant that it is :)

It's valuable to hear some dissident voice from time to time because 100% agreement on trending paradigms always creates the risk for the new generations to jump to the cargo cult ship and accept the common wistom as a dogma, instead of appreciating with own reasonment the current state of suggested practices.

As always, virtue lies in the middle and computing is no exception: I was professionally born in the age of in house racks where every SME would own a handful of servers and sysadmins would plan whether colocating applications or buying new iron that had to be accomodated somewhere in the DC. There have been very good reasons to switch from monoliths/SOAs to microservices and from bare-metal to containers/FaaS, reasons that I personally would not trade back for the bad old days of manual deployments: microservices offered live patching of systems with no downtime and imposed design by contract to ensure verifiability of single cogs inside the big clockworks, instead of having to run the full stack in own laptop to ensure end-to-end functioning.

I think the point of the article is really how bad is to swtich to new paradigms for use cases that are well served with single application, single server monoliths (internal inventory management systems, for example) just to change ship and "do what the others are doing".

Yes, the cloud is conceptually the new mainframe, but usability has also improved a lot: the user experience created agility and the agility created the opportunism that creates the commoditization of infrastructure. Is Heroku a sustainable use case for production? No, but it is super for development. Heroku is feedback loop for product development as smalltalk was for pure development.

So it is probably true that following blindly market trends just for the sake of it is a very bad idea, but the author seems also to be suggesting "Java monoliths or die!" which I don't agree upon.