CGI is in vogue again - I am so happy!
Back to the '70s with Serverless
61–70 of 310 posts
Re: Back to the '70s with Serverless
#62For all its flaws in design or philosophy, cloud computing has a sweet spot. As an indie, lone dev, I can run my site, email and a basic web app for about 10 USD a month and, if my app kicks off, I can scale it to a million users without breaking a sweat. To me, that is the true power of the modern cloud computing paradigm. An influx of great apps and services enabled by cheap scalable and sweet competitive cloud ser…
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 as well. Deploy n instances, load balancers, scaling vertically then horizontally, db sharding. You still have the same fundamentals.
One pro of today is having a single artifact to deploy (tons of cowboys deployments and FTP uploads in the past).
One big cons you have nowadays is learning all the latest crap $currentCompany is using and having to peel the layers of abstractions to see why things work so badly.
Re: Back to the '70s with Serverless
#63> 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…
From my anecdotal evidence, people are attracted to serverless because they spend way to much on aws and they hope that by turning things off they'll spend less.
Not many people have the problems solved by a serverless architecture (or they need more freedom), which is why it's not as common as just running your own long running instances.
Re: Back to the '70s with Serverless
#64This is stupid. If you don’t recognize the benefits of serverless of the capabilities of this you shouldn’t be writing about it. Go back to retirement if you remember the 70s. Maybe you would have laughed people out the door in 2000 but that doesn’t mean you by any means are right. Serverless doesn’t add complexity but provides a service that manages everything for you without having to manage scaling manually. This…
If you don't remember the 70s and mainframes, you're not in a position to evaluate comparisons yourself.
Re: Back to the '70s with Serverless
#65> 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…
[deleted]
Re: Back to the '70s with Serverless
#66Earlier 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 don't think burning in sum hundreds of billions of Dollars (or even more) because "it's OK being irrational, because emotions" makes sense.
The business case is that you won't be able to retain good engineers if you refuse to rewrite your AS400 COBOL app.
Re: Back to the '70s with Serverless
#67My 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
#68> 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…
The fun thing is that many C-people are fed the VC kool-aid about scalability. They want everything to br scalable because they want to cash in. Except that not many companies reach the level where you need to scale your tech stack "exponentially". And you usually don't want to scale the dumb prototype that ended up in prod anyway. The trap here is that those systems will allow you just that in a totally unauditable way... Good luck replacing parts of those systems as well when everything is interconnected...
Re: Back to the '70s with Serverless
#69Earlier quoted context omitted.
I don't think burning in sum hundreds of billions of Dollars (or even more) because "it's OK being irrational, because emotions" makes sense.
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.
Re: Back to the '70s with Serverless
#70This is clearly a surface opinion without a great deal of experience in leveraging the numerous benefits of cloud and serverless.
Complexity can be managed if you start out thinking about. The biggest problem with the cloud is ad-hoc. If you go in just building shit without a strategy and guardrails, it's going to cost a lot of money and end up in pretty bad shape.