>buy serverless cloud
>look inside
>servers
>make website on no-code editor
>look inside
>code
>buy serverless cloud
>never look inside
Ah yes, the age old “if a tree falls in a forest and no one is around to hear it, does it make a sound?”
or in this case, if a server fails in the cloud and no one is around to see it, does my app still run?
It requires conscious observation similar to the photons acting like a wave until observed which then they are a particle.
It’s not serverless, it’s just someone else’s server
Yeah, yeah, but I don’t have to patch it.
Don’t have to patch the host at least… I think we have a 6 week sla for certain compliances to ensure we are patching our containers, code, and deps regularly.
That sounds like a problem for IT, not a dev. ;)
Exactly, it is as much serverless as the offering that allowed to host php sites back in the day.
Serverless is more associated with micro services where each micro service can scale independently from each other.
It is, but the idea how it works is roughly the same.
That you don’t need to care about… as a dev you want to write your code, deploy and not have to care about the underlying server maintenance… you are paying for that to be someone else’s problem.
I’m as critical as the next guy of how overused and abused serverless/microservice architectures can be, but there’s disliking something and being completely disingenuous. Some of the comments every time the subject is even remotely mentioned fall into the latter. This time is not the exception lol
I mean that’s generally the case with most tech. Just like the never ending PHP hate. Plenty of reasons to dislike or not use it but no reason to think it’s the scum of the earth.
On a tangent, I imagine PHP is still one of the most used backends. Wordpress uses PHP and I wouldn’t be surprised if 50% or more of the websites I visited are Wordpress sites. So I guess many others experience the same?
Very widely used still and well maintained. It’s been a good options since 7 came around. Most of the hate IMO comes from people who were working with PHP4/5 code or people who just saw PHP4/5 code and think that’s what the language is today.
Don’t wanna hate but maybe this will stir the pot: any time I go to a website and go “this is definitely Wordpress” I’m usually right (I check with the Webappalyzer extension).
It really depends on how much customization has gone into the site. TechCrunch, Wired, and TIME all use WordPress for example, but their theme is customized to the point where you can’t really tell that it’s WordPress. There are some ways to tell though, for example some of the larger sites are hosted by Automattic (these say “powered by WordPress VIP” in the footer), and
/wp-admin
usually still works to go to the login page.Yeah, that’s a fair point. I’ve been surprised to see a website is Wordpress from time to time.
As far as
/wp-admin
goes, I know all about that! Any web server I’ve run is constantly overrun with bots trying to hack it. A lot of times I configure nginx to simply drop connections to any URL ending in.php
or GZIP bomb.deleted by creator
I’ve looked into it a few times and it just seemed complicated to do within a Docker container but I could be wrong. I might have ChatGPT guide me on that endeavor.
Yeah, this stat is always a bit dubious sounding to me (how much of it is blogspam?), but WP is still much more prevalent than most devs seem to realize.
Plus, Facebook literally forked PHP and still uses it, and is one of the most popular sites on the internet
Modern-day Hack (the language PHP uses) looks pretty different to PHP, and the runtime is a complete rewrite rather than a fork. HHVM uses C++ while PHP uses C.
That’s true, it would be more accurate to say that much of the web uses PHP or Hack, a PHP derivative. I think I was moreso thinking along the lines of the previous comments about the hatred for PHP being more of a meme at this point than a reality
Yeah… Indeed, our field is pretty prone to weird tribalism and jumping on bandwagons. Still, I dislike that just as much lol
For sure. People find a niche they like and then think that is the solution to any problem. Until, of course, some new shiny tech catches their eye and they try that out (or their favorite clickbait Medium writer comes out with an article about “Why you shouldn’t be using ____ anymore in 2023”). Then the love of their life gets thrown to the curb.
I think it’s a maturity thing. You eventually see so many trends come and go, peaks and troughs of hype cycles and some developers (probably including yourself at least once!) overusing certain new tech.
You eventually discover what works with current tech and then you can become healthily critical of anything new. You see it more for where it can fit and where it can’t.
If you have something small and stateless then serverless is easy and, more importantly, scalable. It was a little easier to see its role once the hype fog had lifted and I had a problem to solve with it.
see so many trends come and go
It’s interesting how things are cyclical. Serverless functions remind me of cgi-bin scripts.
Yep, it’s usually an existing idea with progression in a few areas. You could definitely achieve serverless with a cluster of servers hosting the same scripts in cgi-bin and I think that context helps to put it into perspective.
I feel like I should start a “serverless” startup that’s just Apache running in a Kubernetes cluster with a bunch of cgi-bin scripts in a Ceph cluster. Boom, serverless with high availability.
If you only focus on the concept of a serverless function and forego 99% of the other stuff, yeah 😛
The trends coming and going is personally what makes me more tribal. Specifically I’m thinking of the JavaScript/Node ecosystem from the perspective of a Ruby on Rails developer.
Thankfully these days we have Hotwire and it’s possible to completely rip out all the Node trash we had to stuff into our containers.
Eli5 server less, even on paper…
Instead of spinning up a classical server like Apache or IIS for what you need, you just write a single function that you can bind to an endpoint and just host that - the rest is abstracted away from you.
Serverless sounds like a terrible name for this lmao.
Why not remote functions or something like that.
Marketing™️ I guess? :P
But probably because YOU don’t have to fuck around with servers, for you it’s just an upload of a function.
I think that’s the main reason, it’s a good name explaining what you can expect: an environment where you don’t have to worry about servers and don’t need an administrator
Why not just call it shared hosting though? It’s essentially the same concept as getting a GoDaddy (or Bluegost or whatever) hosting account and uploading a PHP file lol
Shared hosting sounds like you don’t have your data stored privately and doesn’t sound like less work for the company.
Don’t look at the name from a technicians perspective, but from the perspective of a manager of a small startup who wants to reduce the overhead for hosting it’s service as much as possible. Also serverless is not wrong per sé, it’s exactly what you as the customer get.
You could spin it the same way for every other instance. Why do you call GoDaddy “shared hosting”, in the end it’s just a pod on a kubernetes cluster. So why don’t you call it “private kubernetes pod”?
Someone else has a server and their infrastructure is set up so you can upload a zip of some executable and they’ll figure out how to make it run. You don’t worry about any details except your code and whatever API is require to be compatible, and they worry about hosting it, making sure it has memory, CPU time, disk space, DB, etc.
So it’s essentially the same as shared web hosting, just masquerading as a new concept. 15 years ago I’d deploy PHP sites by uploading them via FTP to some free web hosting company.
Yep. But you pay only for the CPU time you use and very often the only IO you can do is HTTP due to the runtime.
For the sys admins etc… saying it’s still a server, you are missing the point… it’s conceptually serverless in that you are paying a premium so you don’t have to care about the server maintenance etc… That’s someone else’s problem.
I haven’t ran into a good use-case to try out server-less yet. Either cold starts would be a problem (for example, I have an endpoint that needs to load a 5GB model into RAM, and it takes about 45 seconds). Or, it’s just much more expensive than a VPS if the service is projected to constantly serve many requests all day. Containerized services on a VPS doesn’t require much server maintenance (unless you have a dozen or so micro-services, then yeah, Kubernetes maintenance adds a lot of overhead).
serverless devs are the same as devs who don’t know what graceful degradation is.
you don’t have to be a server admin but at least know the basics
But think of the profit margins, and all the buzzwords our marketing team can use
I didn’t known that it was seen as a bad thing by some devs. At my company (consulting) are we saying that we failed if we spin up a full server. we do infra as code very often and that wouldn’t be as easy or possible as with serverless. It is easier to monitor what cost money (need more performance) that way too. I have seen some wish to get into the server, you don’t have to, that is the thing, all your configurations are done with in a portal like azure, the only times (extremely few) i have went into a serverless is when i have to check the apps configuration for a very old app that may have been deployed manually (get surprised every time) and i don’t know the values that need to be set and there has been times logging is done to disk instead of using application insight. But thankfully these are exceptions not the norm. It is usually applications that was a fire and forget project and have always worked until they want some new functionality.