[deleted]
Serverless Architectures
81–90 of 215 posts
Re: Serverless Architectures
#82What 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.
He's not missing the point. He might have a preference that technical terms have semantically useful meanings.
Re: Serverless Architectures
#83I recently evaluated these, and I'm dying to use something like this. I would really love to be able to do this with sandboxed apps written in arbitrary languages like Go, Haskell, Rust, or even C++. Ideally, I wouldn't be managing docker containers or VMs to get certain jobs done.
Unfortunately, it's limited to JavaScript, Python, and Java for now. Google Cloud Functions is similarly limited to JavaScript.
I know that these languages were chosen because they can be easily sandboxed, but it would be nice to support something more generic without having to create docker containers for everything.
Re: Serverless Architectures
#84What 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…
I imagine serverless is a powerful buzzword because it implies cost savings on servers.
Re: Serverless Architectures
#85What 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…
The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way.
With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to:
* Manage/deploy servers
* Monitor/maintain/upgrade servers
* Figuring out tools to deploy your app to your server
* Scaling an app globally.
* Coping with outages in a data-centre/availability
* Worry about load-balancing & scaling infrastructure
I think this is more than just a marketing gimmick. It is part of a big change in application architectures.
At one end as a small developer of of web/mobile app this can considerably reduce the amount of code/maintenance you need.
At the opposite end of the spectrum the likes of Google (Borg) and Facebook (Tupperware) have developed their own in-house solutions where by servers are largely abstracted out as an entity that developers need to worry about.
Managed docker services (e.g. Google Container Platform, Docker Cloud) are another approach of achieving a largely 'serverless' goal.
(edits for formatting)
Re: Serverless Architectures
#86Aren't 'serverless' PAASs just a reinvention of PHP hosting?
It's so true that it hurts to think about it!
Re: Serverless Architectures
#87I recently evaluated these, and I'm dying to use something like this. I would really love to be able to do this with sandboxed apps written in arbitrary languages like Go, Haskell, Rust, or even C++. Ideally, I wouldn't be managing docker containers or VMs to get certain jobs done. Unfortunately, it's limited to JavaScript, Python, and Java for now. Google Cloud Functions is similarly limited to JavaScript. I know th…
Have you checked out https://github.com/iron-io/lambda. Their is a tool for docker container creation, and also AWS Lambda compatibility.
Re: Serverless Architectures
#88One 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…
[deleted]
Re: Serverless Architectures
#89Earlier quoted context omitted.
Well if I can't use it now due the constrains mentioned above it is dead to me. Would you bet your project on Google functions[0]? [0] https://cloud.google.com/functions/docs/
That isn't what DoA means. "DoA" doesn't care for whether an individual can use it, it cares for the collective. I'm sure Stallman couldn't use the iphone when it came out because of constraints, that doesn't mean the iphone ever was DoA.
I can't speak for the collective. As far as I'm concerned the current offers of BaaS are dead on arrival. Time will tell. I could see some value in the iPhone but I don't see much value in the current BaaS offers. Not enough to switch from the current alternatives. They are not transformative like the iPhone was. To complete your analogy we had smart phones before just like we have various BaaS services now.
Re: Serverless Architectures
#90One big challenge is the expense that is otherwise avoided via usage of connection pooling. Without the hack to keep the backing containers alive, tearing down and restarting them is expensive and wipes out all hot path optimizations made by JIT compilers besides having to reestablish connections and pay the handshake prices. Apart from the simplest of use-cases at this time, imho this is not an efficient model if sustained performance and low latency are of interest.