Live data from Hacker News

Serverless Docker Beta

zeit.co

231–236 of 236 posts

Re: Serverless Docker Beta

#231

"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?

Sure:

Serverless - "Re reimplemented/packaged a code runtime, and jerked off about marketing a bunch"

My Butt - "Run your shit on someone else's computer"

TBF, if the 'serverless' shit was sold as "run functions without needing to fiddle with an os", that's a decent selling point.

It's not server-less, tho.

Re: Serverless Docker Beta

#232

Earlier quoted context omitted.

WebM (or rather, VP8) uses less bandwidth and has better quality.

I believe technically it requires lower bitrates to maintain the same quality (as mp4 etc), as opposed to just having de facto better quality. The lower bitrate is what results in less bandwidth usage.

Well yeah, you can get lower bitrate with the same perceived quality, or better quality with the same bitrate, or a mixture of both. It all depends on what options you set when encoding.

Re: Serverless Docker Beta

#233
post #225
post #160

Earlier quoted context omitted.

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…

Can't you use a queue service that's essentially just managed kafka/activemq/other-standard-system? I mean sure if you wanted to move off the cloud vendor you'd have to run your queues yourself, but if you're programming to the API of well-known open-source queue system then you're never going to be very locked into a particular vendor.

The short answer is yes, you can do that, but it starts to get nuanced rather quickly. The context of this is a desire to go “serverless” and that solutions like this only give you serverless for the relatively easy parts of your stack. If your goal is to go “serverless” I take that to mean a few things listed below.

    1) you don’t have to manage infrastructure
    2) you don’t have to think about infrastructure (what size cluster do i need to buy?)
    3) you pay for what you use at a granular level. (GB stored, queries made, function invocations, etc)
    4) scale to zero (when not in use, you don’t pay for much of anything)

Most things don’t hit all of these points, but typical managed services hit very few of these points. Sure, I can use a managed MySQL, but it only satisfies 1 of the 4 points.

Re: Serverless Docker Beta

#234
post #194

Earlier quoted context omitted.

Because the function is the stateless easy part. To make any non trivial system, in a serverless way, you have to use their proprietary stateful systems. IN my case, google pubsub, google data flow, google datastore, Spanner, etc. that’s where the lock in happens.

Right, because serverless is actually just a cover for "de-commoditizing" the cloud services that companies like AWS built to commoditize datacenters. You hit the nail on the head. It's not completely useless to help less technical people solve the problems that folks like you and I consider "the easy part" and so people will find a use for it. But the primary utility of serverless is an attempt at solving Amazon's p…

I’d say something more nuanced. Serverless is increasing commoditization of one layer of the stack at the cost of de-commoditizing a high layer of the stack. This is what makes it a hard decision to grapple with. You’re getting very real benefits from it, and potentially paying a very real cost sometime down the road when being locked into the propietary system bites you.

Re: Serverless Docker Beta

#235
post #190

Earlier quoted context omitted.

How would that exploit get exploited if you have mutual TLS authentication protecting your database connection? Or are you saying it's likely that particular piece of the database infrastructure is likely to have an exploit?

Just using SSL connections doesn't cover it, for two reasons: 1. You can't force MySQL to only accept connections over SSL. You can only enable SSL, and set specific accounts to only allow SSL logins. This means that any sort of "unauthenticated attack" on MySQL will work -- if you can exploit MySQL without a valid login, enabling SSL for users won't help you. 2. Amazon RDS supports using SSL connections, and will is…

Yeah, if the database doesn’t support mutual tls, it is clear that wouldn’t be sufficient protection. Having a proxy in between client and server that handles this (e.g. envoy) would be a good option.

Re: Serverless Docker Beta

#236
post #160

Earlier quoted context omitted.

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"?

Well, there are stageful serverless products like Google Datastore.
Post reply on HN