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

181–190 of 236 posts

Re: Serverless Docker Beta

#181

Post by arunoda »

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.

Re: Serverless Docker Beta

#182

Post by arunoda »

e12e wrote: post #69
Rauchg wrote: post #14

Earlier quoted context omitted.

As we mentioned in the blog post, there is zero difference between a `Dockerfile` you execute locally and one that you give to us. [One of the differences is performance. You'll find that we can build and execute much more quickly :)] There are many examples here: https://github.com/zeit/now-examples

So, I'm not running the same docker image, just something somewhat similar built from the same Dockerfile?

> something somewhat similar built from the same Dockerfile?

Yes. We build the container based on the Dockerfile.

Re: Serverless Docker Beta

#183

Post by ec109685 »

joecot wrote: post #30
akx wrote: post #22

Earlier quoted context omitted.

If you connect to your database over TLS (maybe with an extra client certificate or something), I don't see much of a problem.

As far as protocol is concerned, if you're using TLS, a client certificate, and a strong password, sure, opening your database servers to world accessible should be fine. The problem is that it's possible, and very likely, there are exploits in the wild for your database server -- that are known but you failed to update for a day, or are 0 day exploits -- which are exploitable without having an authenticated account.…

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?

Re: Serverless Docker Beta

#184

Post by mr_toad »

newscracker wrote: post #24

> “A very common category of failure of software applications is associated with failures that occur after programs get into states that the developers didn't anticipate, usually arising after many cycles. In other words, programs can fail unexpectedly from accumulating state over a long lifespan of operation. Perhaps the most common example of this is a memory leak: the unanticipated growth of irreclaimable memory t…

> seems to leave aside caching, state management and other related requirements on the wayside for someone else to handle or recover from.

Configuration state is the bane of server management. Ideally you want to maintain state in a system specifically designed for it - i.e. a database, or version control software.

Re: Serverless Docker Beta

#186

Post by gcb0 »

aequitas wrote: post #16
ransom1538 wrote: post #2

Yep. Pretty soon. You write code. You create a docker file. You find a place to run the docker file with your code [cheapest!]. Run it through your tests. Monitor it. The end. No vpcs,salts, puppets, sshs,chefs, horses,anisbles, cats,ec2s,devops,noops, sysadmins, kubernetes or chaos monkeys required.

Until you discover that the thing you are building requires more than a single application running in a single container and you end up building an entire "Operating System" around your containers and the circle starts all over again. Complexity is hardly ever in the solution, but mostly in the problem. Single solutions to complex problems often ignore/forget important parts of the problem and they come back to bite…

today new devs, picking up a 10-30yr old system: this is garbage, we have to recompile under the new 4.0 kernel just to be able to run it on new servers and nobody know how to read a makefile! lets rebuild with containers!

tomorrow new devs, picking up a 5yr old project: this is downloading a centOS build from 7yrs ago! which only run on docker from 5yrs ago! and nobody know how to build a new base image with the libraries the old one have! lets rebuild it in

the problem is not serverless or not, its clueless people and corporations with code/process rot. and the only lesson from the cycle, is to never trust people who proclaim one solution is the holy grail for all problems.

Re: Serverless Docker Beta

#187

Post by justicezyx »

andrewtorkbaker wrote: post #31

And so ZEIT, my favorite serverless provider, keeps getting better. Highlights: - "sub-second cold boot (full round trip) for most workloads" - HTTP/2.0 and websocket support - Tune CPU and memory usage, which means even smoother scaling And all that for any service you can fit in a Docker container - which is also how you get near-perfect dev/prod parity, an often overlooked issue with other serverless deployment te…

Where the fang devs mock come from?

They are on the forefront of serverless.

Re: Serverless Docker Beta

#188

Post by whb07 »

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…

How does one get locked in when it’s a simple function in X language? Seriously, serverless is just an endpoint they provide. You write the code and they handle everything else.

Re: Serverless Docker Beta

#189

Post by tapsboy »

TheDong wrote: post #163
tfolbrecht wrote: post #143

Awesome! While I was at AWS Summit in NY, I asked a round circle of AWS ECS/EKS users (Container orchestration products) about thoughts on a Docker container service that could execute like a FaaS product and there seemed to be none anyone knew of. I have a portion of a legacy application that's used infrequently and too costly to decompose but works fine Dockerized. Looking forward to using your product!

I'm amazed no one knew of one. Off the top of my head, services which let you run docker containers without dealing with any servers yourself: 1. AWS Fargate 2. Joyent Triton (which was as simple as DOCKER_HOST= docker run back in 2015) 3. hyper.sh (available since 2016 I think?) 4. OpenFaaS cloud (though you have to go through a couple more steps, you can bring a custom docker image as your 'function'). 5. A metric…

Also ACI (Azure Container Instances)

Re: Serverless Docker Beta

#190

Post by joecot »

ec109685 wrote: post #183
joecot wrote: post #30

Earlier quoted context omitted.

As far as protocol is concerned, if you're using TLS, a client certificate, and a strong password, sure, opening your database servers to world accessible should be fine. The problem is that it's possible, and very likely, there are exploits in the wild for your database server -- that are known but you failed to update for a day, or are 0 day exploits -- which are exploitable without having an authenticated account.…

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 issue your MySQL server an SSL cert from their certificate authority, so your client can validate the server. It does not, however, support client SSL certificates, for the server to validate the client. Which means the only thing SSL connection is doing for you is encrypting the connection -- it's not in any way validating the client, and anyone can download the RDS region's CA certificate and then connect/exploit your MySQL connection normally.

Post reply on HN