Earlier quoted context omitted.
True. I made an assumption that the app is built that way. Of course, if te app architecture inherently unscalable, no amount of computing power or private servers is going to help.
> True. I made an assumption that the app is built that way. Of course, if te app architecture inherently unscalable, no amount of computing power or private servers is going to help. Isn't it usually a mistake to design your app to be scalable to 10,000 users when all you may ever have is 10?
Back to the '70s with Serverless
131–140 of 310 posts
Re: Back to the '70s with Serverless
#132That a fast feedback loop is important was the only contention he made that I found important.
Re: Back to the '70s with Serverless
#133Re: Back to the '70s with Serverless
#134> 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…
> I can’t give the cloud providers my money fast enough
People run VMs and k8s on the cloud as well and run into every one of the problems you just described (aside from literal hardware failures).
Your rant seems to mainly be about having a good CICD pipeline and that’s not really related to cloud or serverless.
Re: Back to the '70s with Serverless
#135> 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…
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.
Re: Back to the '70s with Serverless
#136My 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
Re: Back to the '70s with Serverless
#137Earlier quoted context omitted.
The business case is that you won't be able to retain good engineers if you refuse to rewrite your AS400 COBOL app.
I’ve wondered whether these good engineers are really a net benefit. They crank out something spiffy, move your big systems to it, and then disappear to work on the next hotness, leaving an already burdened tech team to support yet one more spiffy stack that is not quite as reliable or easy to use as we would like.
Managing this stuff is a job, and it requires discipline and organisation. It's one of the few functions of an IT department that is left once you go to cloud (as dealing with Oracle's bullshit is then gone). The younglin's doing development in the business functions have to play by the rules - and the business functions need to agree that there are rules or they will :
a) spend much monies on the issue you describe
b) get cracked open like fresh eggs by any passing hacker who is keen on sports cars
Re: Back to the '70s with Serverless
#138Earlier 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…
> 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…
My reality at a 20 person shop with a few devs is much closer to the OP - a few hours setup (we save the cloud config and can remake servers in a few minutes), servers run for months without intervention, uptime is on par with cloud services, deploys take seconds. Managing servers or deploys just are not major problems for us.
Serverless is not a solution to deploy problems - mostly because they’re just not significant problems for us, if anything the dev deploy story is worse than renting VMs. It’s an interesting take on serving requests and I do believe some variant of it might be the future (a variant more like cloudflare workers IMO), but at present there are serious drawbacks and it is not clearly better, particularly when provided by a predatory company like Amazon.
Re: Back to the '70s with Serverless
#139Earlier quoted context omitted.
Yes, albeit it was a bit more expensive. I was running multiple sites by myself. There was less encapsulation (unless you were working with someone on bsd), for sure, but I'd say the advantages are more visible in terms of security (hacking was much easier back then) than ease to deploy. Doing your own ops has never been that hard (YMMV) and I don't think it improved much nowadays. Scaling to n machines didn't change…
> Doing your own ops has never been that hard I kind of disagree. It's doable, but still requires maintenance. For instance, even running a simple blog off of a VPS requires you to worry about setting up an SSL certificate and keeping it renewed, staying on top of security updates, and putting together some kind of scaling solution assuming you ever want to write a post which gets to the front page of hacker news. I…
Re: Back to the '70s with Serverless
#140> 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…
> 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.
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.