> 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 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…
Back to the '70s with Serverless
241–250 of 310 posts
Re: Back to the '70s with Serverless
#242ah yes, the 1970s where you could sit on your laptop at home, go to a cloud providers website, copy paste your code and launch an app in minutes. This guy is trying too hard to sound smart.
I'm probably the same age as this guy, the article definitely made me roll my eyes a few times for this exact reason.
Serverless functions are usually free. This is a huge boon for learning: I'm a college student with limited resources, and even spinning up a $5/mo VPS takes some thought and budgeting.
I learned web dev with free web hosts & free VPS services back when I was 13-15. Further democratization will only help newer generations explore & tinker with confidence (scale-wise and tech wise).
Re: Back to the '70s with Serverless
#243During the recent history of computing, the technology improvement opened new possibilities at each step:
- Punching cards: allowed more people share mainframe,
- Video terminals: allowed faster turnaround of mainframe jobs,
- Mini-computers: gave more people access to computing,
- PCs: got even more people into computing,
- Commodity hardware in datacenters: more people could develop services and more people from general public could get access to applications and data,
- Cloud: more people could afford to build applications,
- Microservices: bigger teams could collaborate on increasingly sophisticated services,
- Serverless: reduced the burden of capacity planning and service distribution and further lowered the barrier of entry into backend application development.
Each statement above comes from personal experience and I am looking forward to what new possibilities the future brings.
Re: Back to the '70s with Serverless
#244Earlier quoted context omitted.
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.
1980s and 1990s gave us "decision made by senior management reading shiny magazine during flight", we just look back with sentiment now combined with survivor bias.
Re: Back to the '70s with Serverless
#245> I’ve now worked with “The Cloud” for long enough to see that there’s still a long way to go before it becomes materially better than, say, the oldschool method of renting a couple of servers
Lol, it takes a lot of hubris to assume you're the only person, or one of few persons, who understands how the rest of us have been conned. I'm not getting into a debate about the hundreds of ways our infrastructure on Google cloud is "materially better" than "renting a couple of servers." It ought to be sufficient for persons of humility and sense to know that we're also smart people with experience, and we continue to re-examine these decisions and run our stuff in the cloud because, yeah, it's materially better.
And for those lamenting that software engineering is "fashion driven", welcome to humans. To some extent we're all stumbling forward in the fog, and the sound of other footsteps nearby is comforting.
Re: Back to the '70s with Serverless
#246I noticed one of the Lambda functions briefly spiked to 6 concurrent instances. Within a couple clicks I confirmed a bot was scanning the API, possibly looking for vulnerabilities. The built-in API throttling hopefully dissuaded the bot from further scans.
Before serverless, my capacity planning for servers would have required accounting for this spike in “noise”. I would pay for a peak burst scale of 6 servers, but practically only use 1-2 for routine processing.
My serverless infra are just “cattle”. AWS Lambda does some magic behind the scenes and determines when to kill an instance, recycle, or create a new one. I just feed it an occasional monolithic JAR that handles all API calls and queue handlers.
From the OP _[With serverless].. You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system._
This is where the Author seems to conflate the benefits of serverless with a particular architecture or code deployment model. The two are completely separate.
Serverless is not just a technology, but from a lifestyle perspective it is a game changer. A solo software developer can rapidly experiment and test ideas until one starts to scale. Most of the experiments can be run in a “free tier”. And the costs of scaling are comparable to provisioning your own EC2 instances or containers.
Re: Back to the '70s with Serverless
#247You can run and test FAAS, even the proprietary Lambda, locally. In fact, if you aren’t doing so, I dare say you’re “doing it wrong.”
Lambda is just one more tool in the tool chest of pluggable components that scale infinitely. “Given input X, do Y,” is boiled down to a predictable, repeatable service that requires almost zero infrastructure knowledge.
Re: Back to the '70s with Serverless
#248Upon seeing this article while drinking my Sunday coffee I was reminded to do my weekly AWS serverless checkin. I noticed one of the Lambda functions briefly spiked to 6 concurrent instances. Within a couple clicks I confirmed a bot was scanning the API, possibly looking for vulnerabilities. The built-in API throttling hopefully dissuaded the bot from further scans. Before serverless, my capacity planning for servers…
In all fairness, this same thing can be done with virtual machines. VMs have been "cattle" for a long while now. "Serverless" just removes the start and stop buttons from your UI. There are still servers and there is still configuration, it's just being done on the conflations of others.
What I find interesting is how many people feel the need to justify using whatever it is they are using when others are exercising their right to question whether or not all the tech we've built is "worth it".
In many cases, having all this power of the cloud has just removed value from companies as they allow their employees to spin up whatever and leave it running because they don't know any better processes than what has been sold to them by crafty sales and marketing people.
How many millions have been "blown" on cloud just to say something is started or running? My observations say "a lot".
Re: Back to the '70s with Serverless
#249Earlier quoted context omitted.
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…
> How long are you talking? There were some Spring applications that took more than 5 minutes to start in my old job. However, things are most probably improved now with lazy initializations of beans and maybe developers of that applications could have done better at that time. I don't know it is still the case now. > Also, with the current network speeds and memory availability, it's hard to imagine the war size to…
Anyway, can you share which kind of environment even a 5 minute deployment would be a problem? Most places I worked at it took a lot more than 5 minutes to actually implement the change that's going to production, so deployment times were pretty much irrelevant overall.
Re: Back to the '70s with Serverless
#250> You deploy, get an error message, and login to CloudWatch to see what actually happened - it’s all batch-driven, just like the bad old days, so progress is slow. You can run and test FAAS, even the proprietary Lambda, locally. In fact, if you aren’t doing so, I dare say you’re “doing it wrong.” Lambda is just one more tool in the tool chest of pluggable components that scale infinitely. “Given input X, do Y,” is bo…