Only Google and Amazon exist in this write-up? This is not a guide, more an intro.
Who are some other providers, aside from self-hosted?
Microsoft has Azure Functions, if you're in to that kind of thing.
Guide to Serverless Architecture
41–50 of 105 posts
Re: Guide to Serverless Architecture
#42CGI scripts with a new name. Lambda and the like are interesting but any system is a composable set of components. You can say the same about Object oriented programming or func programming. separation of concerns but on the network. Server functions arent a panecea cause you still have to manage all the other pieces. An elegant thing would be your entire app is in that single lambda but without state there goes your…
More like CGI scripts with a loadbalancer that promises to run your application on a host with enough memory within at most 600ms. That solves an actual problem with CGI scripts, but I really would love to see more tiers with lower latency brackets, sub 10 milisecond should be doable for certain lambdas and costs.
sub 10 ms would only work if they had an instance running and warm, ready to take requests - if they still have to look up your function, provision a machine, interpret it etc it's easy to go past that. 600ms is still respectable if it's from a "cold start".
But if you've got time critical applications maybe serverless is not for you.
Re: Guide to Serverless Architecture
#43Earlier quoted context omitted.
> CGI scripts with a new name "Electric lightbulbs: candles with a new name"
Weak argument from analogy given the (lacking) degree of relevant similarity. See: On Analogy, A System of Logic by John Stuart Mill for a thorough analysis of analogical reasoning: https://ebooks.adelaide.edu.au/m/mill/john_stuart/system_of_...
considering how tenuous the original comment claiming cloud functions are just basic evolution of cgi scripting I think providing similarly poor analogies is quite apt.
Re: Guide to Serverless Architecture
#44Earlier quoted context omitted.
> CGI scripts with a new name "Electric lightbulbs: candles with a new name"
Weak argument from analogy given the (lacking) degree of relevant similarity. See: On Analogy, A System of Logic by John Stuart Mill for a thorough analysis of analogical reasoning: https://ebooks.adelaide.edu.au/m/mill/john_stuart/system_of_...
Seems to me like they are both dismissive statements about a technology that provides the same thing in a new improved way. But more importantly, linking to a book of logic is an especially poor form of argument.
Re: Guide to Serverless Architecture
#45> Drawback of Serverless: Vendor lock-in, statelessness, local testing, cold/warm start perf, security, deployment, execution, monitoring, remote testing, debugging. Excuse me? Let's use lambda for what it was meant to do, not replace your entire stack.
I'd expect a lot of those are things that should be supplied by AWS, especially things like providing a service that runs the code exactly as it would on AWS itself (which should fix the testing / debugging); monitoring and security should mostly be builtin.
Re: Guide to Serverless Architecture
#46Drawbacks I experience: - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. - Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up. - Security/monitoring: having fewer functions make this less of a worry, but it's still…
> - Vendor lock-in
Try something like https://github.com/apex/up - write the code as regular servers, and it'll convert your entire server into a function.
> - Cold/warm start Should be a temporary annoyance - I'm sure all the providers are already hard at work on fixing this.
> - Security/monitoring Easier to do than regular servers - most FaaS systems have monitoring built in, and collect whatever you write to STDOUT.
> - Debugging: Yeah, can't do much about that.
> - Local testing Besides Up mentioned above, should see more and more shims like https://github.com/RealImage/concave/blob/master/server.js coming up.
> - Deployment Still a mess, but give it time. Heroku like experiences for FaaS should be a matter of time.
Re: Guide to Serverless Architecture
#47Drawbacks I experience: - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. - Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up. - Security/monitoring: having fewer functions make this less of a worry, but it's still…
The vendor lock in and local testing is easily solved by https://github.com/1backend/1backend
No execution limits, since you can deploy and fine tune it to your environment. Can be stateless or stateful depending on configuration.
Re: Guide to Serverless Architecture
#48Earlier quoted context omitted.
More like CGI scripts with a loadbalancer that promises to run your application on a host with enough memory within at most 600ms. That solves an actual problem with CGI scripts, but I really would love to see more tiers with lower latency brackets, sub 10 milisecond should be doable for certain lambdas and costs.
The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog. Interestingly lambda seems to make async IO t…
> The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity.
There is another way of looking at it: Pay for a percentage of the traffic, irrespective of how fast your application runs or what your budget is. If you reach your monthly budget because of one hacker news trending article, yeah, then no more traffic for you. It can be insane.
If I have autoscaling with an upper bound, I can stay within a fixed budget per month. If I reach my budget, yeah no more new servers, but whatever running keeps running. My business doesn't disappear, I get business continuity. Paying based on % of traffic sounds insane. How will I plan for business continuity if my monthly budget is reached with this kind of model? (without any "minimum xx requests" kind of crap free tier, business continuity means fixed upper bound AND continuing service, not OR)
Re: Guide to Serverless Architecture
#49Drawbacks I experience: - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. - Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up. - Security/monitoring: having fewer functions make this less of a worry, but it's still…
> - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. The post isn't loading so I don't know exactly what it's in reference to (AWS lambda, the framework, the more generic idea?). But, the serverless framework[0] supports all major cloud providers (AWS, Google, & Azure) as well as self-hostable options like OpenWhisk and Kubeless. [0] https://…
Yes, but when I started putting this together it was very immature, as in: it crashed a lot. I didn't really want to lock myself in to an immature product either, and I also didn't really like having to run specific commands to get to a certain setup, rather than describing the layout of my desired infrastructure.