Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless Docker Beta

zeit.co

Post reply on HN
Print view View original

211–220 of 236 posts

Re: Serverless Docker Beta

#211

Post by dsiegel2275 »

PaulRobinson wrote: post #200
erik_seaberg wrote: post #151

Earlier quoted context omitted.

You can't decouple validation from the datastore if you want to be certain that all the validation happens and none is ever bypassed or outdated. It bugs me how many systems have opt-in correctness.

If you start with the intention of asynchronous, non-transactional eventual consistency as your assumptive design model, you'll realise: 1. Most applications don't need 100% correctness. Few people are writing nuclear reactor control systems, or bank account management software 2. This model frees you to up to compute at the edge more. Is there a chance that you consider something valid that eventually wasn't? Yes. B…

You make some good points, but I disagree that giving up consistency makes everything easier. There are trade-offs. In an eventually consistent system, in my experience, application code becomes much more complex to implement, test and debug.

Re: Serverless Docker Beta

#213

Post by gregknicholson »

fake-name wrote: post #93

"Serverless" So where do your functions execute?

I think “serverless” doesn't actually mean no server (a distributed system, like Dat); it means “don't worry about the server; we'll take care of it for you”.

…or maybe that's “Cloud”.

Is there a clear explanation of what “serverless” means, and how it's different from “Cloud”, suitable for semi-technical non-developers?

Re: Serverless Docker Beta

#214

Post by windows_tips »

rhacker wrote: post #46
symlock wrote: post #40

Earlier quoted context omitted.

I'm not a "serverless hater", but every company I've ever worked with had backend processes that were not tied to HTTP requests. I still keep actual servers around because the HTTP gateway is not the pain point. It's long-running processes, message systems, stream processing, and reporting. That said, I look forward to the company (or side project) where "serverless" can save me from also assuming the "devops" role.

I think all that is still possible in Serverless. I'm not a serverless architect or anything, but that's typically handled by various serverless queues and related event systems.

Sounds expensive.

Re: Serverless Docker Beta

#215

Post by _asummers »

esistgut wrote: post #168
_asummers wrote: post #90

Earlier quoted context omitted.

Been going through that process the past few days on Scaleway, as they don't have a hosted K8. It's... tough... but I'm learning a lot and have a much deeper understanding of K8s clusters from an operational perspective now. I have a much deeper understanding of the magic happening behind the scenes to keep everything talking to each other, and even if I wind up on a hosted solution in the end, it's been invaluable.

There is an early access program for they hosted kubernetes service https://www.scaleway.com/kubernetes/

Yeah I signed up months ago but haven't gotten an invite yet =(

Re: Serverless Docker Beta

#217

Post by mildweed »

daveheq wrote: post #216

How can something be serverless if it habdles http requests? Does it just process requests and never serves responses, or is it just a hip-sounding misnomer?

Long story short, there's a server somewhere, but most of the configuration is abstracted away. Instead of thinking of servers, they want you to think about endpoints (which they manage somewhat efficiently for you).

Re: Serverless Docker Beta

#218

Post by bdcravens »

the_duke wrote: post #140
bdcravens wrote: post #116

Earlier quoted context omitted.

Functions that respond to events, where an event is triggered by some sort of message queue (ie, Lambda + Kinesis streams)

Which usually have very low time restrictions in the order of a few minutes.

Break your operation into a series of discreet tasks. For 99% of use cases, if you have an discreet task that takes 5+ minutes, there's a problem. In most cases, it can be split up.

Re: Serverless Docker Beta

#219

Post by danpalmer »

arunoda wrote: post #181
danpalmer wrote: post #138

> Serverless > A new slot configuration property which defines the resource allocation in terms of CPU and Memory, defaulting to c.125-m512 (.125 of a vCPU and 512MB of memory) Sure sounds like needing to be concerned about the hardware. That feels like a leaky abstraction that the serverless design pattern claims or appears to take care of, but seems like it doesn't in practice. Is "serverless" the right level of ab…

Whether it's serverless of not choice of hardware is very important. For an simple web app, you might not need special CPU and Memory requirements. But for a video encoding/decoding serverless app may needs different CPU/Memory requirements (and GPU). That's what this `slot` configuration property does. The default is good enough for all the general purpose apps. But if you need more, you can control it.

I agree that one-size-fits-all doesn't work with hardware requirements, but I still think this is a leaky abstraction. The promise of Serverless is not having to care about servers, but this is an option to specifically control that. A better abstraction would auto-optimise hardware spec for the software's performance characteristics - that would be much more "serverless".

Re: Serverless Docker Beta

#220

Post by collinmanderson »

jshen wrote: post #160
driverdan wrote: post #68

Earlier quoted context omitted.

Serverless is fantastic for ETL and data analysis, especially for workloads that vary in scale (eg cronjobs). Feed data in, get data out with scaling as needed.

but how do you feed data in? Usually, it's some other service on one of the big 3 cloud providers. I'm using google for my projects these days so it's a mix of Google PubSub and Dataflow. I think this is the issue/risk with serverless. You either get locked into one of the big 3, or you end up doing all of the ops work to run your own stateful systems. As some of the people above you said, managing and scaling the st…

> all of the ops work to run your own stateful systems

Can we please call it "stateless" instead of "serverless"?

Post reply on HN