One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple users, working on multiple code branches, and all needing environments that somewhat closely mirror production. This leaves servless as a decent way to hook an event callback to some AWS event (new file uploaded to S3, etc) but IMHO not anything that approximates any kind of business logic - or anything that will need to be iterated on by more than one developer. I feel it is a massive reach to market this to anyone at this point, and if this catches on, would really make me hate programming compared to what local development in VMs feels like - where I have much greater tools. It's inefficient both for the developer and at runtime.
Serverless Architectures
71–80 of 215 posts
Re: Serverless Architectures
#72Earlier quoted context omitted.
Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.
Locked in maybe, but not vendor locked in if the language is open source.
Yeah, I guess less so now, but before C# was open sourced the only viable option was Windows servers and people usually used SQL Server with it. So in that case many people chose to lock themselves into that vendor and stack. So in my mind Lambda as a back end is no worse than that in terms of vendor lock-in. I suppose that Amazon will be able to provide support for many years given how much of the internet currently runs off of them.
Re: Serverless Architectures
#73So apparently "serverless" means you don't have to requisition a cloud instance to run the service. I remember this movie the first time around, when it was called "virtual hosting". What a revolution -- transitioning from needing a Unix box running Apache to run your PHP e-commerce site to having your host take care of that for you -- and everybody else. Just because you're doing something old "in the cloud" now doe…
Does it matter whether something is new or not? The fact is there are services such as AWS lambda that people are using and talking about, so we need terminology for that.
Re: Serverless Architectures
#74[deleted]
Re: Serverless Architectures
#75Earlier quoted context omitted.
In this context "server" doesn't mean "entity listening on some network endpoint, providing some service to network-connected clients" (which is I think the definition you're assuming). Instead "server" here means "Unix Machine". Thus "serverless" means software and humans writing and deploying said software that do not need to know anything about /etc/ and installing packages and disk partitioning and swapping and w…
So my car is engineless if I never look under the hood?
Your car isn't engineless because when its engine dies, you will know about it and have to do something. S3 is serverless because if one of the servers storing my files die, I have no way of even knowing it happened.
Re: Serverless Architectures
#76What a ridiculous and strange definition this is. Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers... Why not just call it "Multiserver" instead. If they mean "containerless servers" or "microservices", then why don't they say so? If they mean "distributed servers" why not call it that. If they mean that the client relies on multiple services (each hoste…
Now that it has a name, it can develop a hierarchy of experts, annual conferences, and a consultancy bonanza for a few years.
Re: Serverless Architectures
#77What a ridiculous and strange definition this is. Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers... Why not just call it "Multiserver" instead. If they mean "containerless servers" or "microservices", then why don't they say so? If they mean "distributed servers" why not call it that. If they mean that the client relies on multiple services (each hoste…
You're missing the point in that _you_ don't have servers. Just as cloud is "someone else's computer" -- serverless is someone else's server.
Re: Serverless Architectures
#78Earlier quoted context omitted.
If history is a guide, I suspect it will just increase the size and complexity of apps. Its amazing what small teams with serverless architectures can accomplish nowadays.
> If history is a guide. Could you elaborate on this ? I agree the size and complexity could increase, but so could the number features in the apps. Since all such apps would be reusing the same code base, wouldn't this increase abstraction and reduce implementation hours ?
I think it's something like a big monolithic app is less complex than a n-tier client server app which is less complex than a microservices distributed app which could be less complex than a purely FaaS implemented app, yet to be determined.
Re: Serverless Architectures
#79The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
I completely disagree that it's DOA. In fact, I think it's clear that is the future of development. Like any piece of the software stack, there are providers focusing on services that are proprietary, open source, and a mixture of the two. I am personally most excited about the hosted open source providers, because it gives dev teams immediate access to the technology, but the option to bring it in house when and how…
I didn't say the technology is DOA. Just the current offers which seem locked in to specific vendor implementations. The current BaaS offers are too intrusive and just not good enough to worth the switch from a PaaS to a BaaS.
Re: Serverless Architectures
#80Earlier quoted context omitted.
Locked in maybe, but not vendor locked in if the language is open source.
Yeah, I guess less so now, but before C# was open sourced the only viable option was Windows servers and people usually used SQL Server with it. So in that case many people chose to lock themselves into that vendor and stack. So in my mind Lambda as a back end is no worse than that in terms of vendor lock-in. I suppose that Amazon will be able to provide support for many years given how much of the internet currently…
[deleted]