Follow

In a discussion about "Serverless" on Reddit. ( reddit.com/r/opensource/commen )

I think the ideas of Backend as a Service are potentially powerful, as the abstractions of a single machine often limit the architecture. This is because our traditional POSIX calls are very system specific (rather than service/network centric), but all too often this idea is just used to lock developers into something they can't escape.

@emacsen

I have dabbled a bit in what now some people call “serverless” though by no means an expert.

Things may have changed in more recent times, but when I ran my numbers I didn't see the economic case for using #AWS and friends as opposed to a traditional (and #EU hosted) #VPS provider with on-demand provisioning.

Maybe if you're #Amazon it makes sense to use #AWS, but if you're not on that league, what are the advantages?

@61 It's really important when we talk about these topics that, just as there are marketers who will mis-use terms, that we don't also mis-apply their own terms. "Serverless" in this case is about an architectural paradigm that it, on its own, not a bad thing, but is often coupled with vendor lock-in.

What you're talking about is what many people would called "cloud computing' and there actually are some reasons to consider it (and other reasons not to. I'll elaborate in pt 2.

@61 VPS and other "cloud providers" offer a few discreet benefits- firstly a linear provisioning cost. If you want to start building out a server room you'll need space, equipment, cooling, etc. VPSes are linear in their cost. They also don't require the same cost in up front staffing. And they can be cost effective when you need a lot of computing in short bursts, rather than long processes. Those are real reasons people/companies may choose that route. Reasons people might not in pt3. :)

@61 Good reasons not to use a VPS is that while up front costs are lower, your at any sort of scale, your overall costs are much higher. You are paying the overhead premium.

Also, depending on the work you're doing, such providers may not be optimized for it. In much of the work I've done in the distant past, working with scientists, we were IO, not CPU bound. Most VPS providers are not building systems with that in mind. There are also privacy issues to keep in mind as well when you outsource.

@emacsen

If you are running at any sort of scale, you will (should) not be paying list prices or running an off the shelf configuration, as you will have negotiated an agreement with the provider.

This assumes we are not talking about github sort of scales, which I doubt most AWS users are.

The privacy issues will remain whether you outsource to a VPS or serverless provider, wouldn't they? In fact, I'd find a smaller, #EU based provider more reassuring in that regard.

@61 Yes of course you're right, but we're straying too far from the original discussion, which was the perceived benefits of a cloud computing approach.

In this case, faster/easier/more linear provisioning, unlike doing it yourself which will require all this up front cost and possible staffing.

As for privacy and other considerations- yes they happen any time you outsource, whether using virtual machines, bare metal or "serverless".

@emacsen

Please note that privacy is another area in which there are no absolutes. It is by no means the case that an in-house setup magically and automatically offers better assurances than a well-chosen partner with expertise and dedicated resources.

@emacsen
Provisioning costs are not necessarily linear with VPS providers.

@emacsen

Yes I know that. I didn't find it necessary to be explicit about the possibility of adopting a so-called “serverless” approach on your own VPS infrastructure.

@61 I think that the "serverless" approach on hardware you own is actually the best of all worlds as its been my experience that working with developers that they will sometimes hard code resources into their production level code- hosts, paths, etc. which make it then impossible to move or scale. Adopting these paradigms can make a big difference.

@emacsen

Yeah, I wouldn't make categorical assertions as to “the best way” other than recommending to run a proper business case analysis for your specific projects as no solution fits all.

But I think the point we are both trying to make in a laborious sort of way is:

Serverless ≠ vendor lock-in, but one has to be careful about it.

Developers hard coding resources is a huge security and maintainability issue and doesn't strike me as very professional. 😳

Sign in to participate in the conversation
Mastodon

emacsen.net is one server in the network