[homerjam]

Can anyone offer an explanation of how this impacts docker based deploys? Since the serverless docker announcement in August I've been hoping to move off of DO to now but it sounds like that won't be possible with a 5mb cap...?

[Rauchg]

In our upgrade guide we detail how you can break down a "server" that you would otherwise deploy as a monolithic container:

https://zeit.co/docs/v2/platform/upgrade-to-2-0#don-t-rush-t...

The limits are there specifically to help in that transition, to avoid the problem described in the chart. They're a crucial learning extracted from the beta we ran.

[cphoover]

So this doesn't work anymore:

https://zeit.co/blog/now-dockerfile ??

Like I understand the benefits of lambdas/serverless. But they aren't sufficient for all use cases. The ability to have an endpoint for a docker container with one command is extremely useful. There already a lot of serverless options on the market too... maybe I'm confused...

[mattste]

I'm in the same boat. I've spent a lot of time getting my company's deployments set-up on Now's Docker offering (which was awesome). I'm not looking for my app to be serverless. And I'm also not looking for a "Majestic Monorepo".

[Rauchg]

Please keep in mind v1 will be around. We'll compel you to move by thoroughly reaching feature and use-case parity :)

[gigatexal]

Can't you use now v 1.0 setting the json file now.json to have this among other things:

{"version":1}

[mattste]

NOTE: v1 is fully maintained and supported. We will only announce a deprecation date once we have ensured all our customers workloads are migrated and the tooling is in place for a smooth transition.[0]

Based on that, it seems to me like I will have to migrate to Now 2.0 eventually.

[0] https://zeit.co/docs/v2/platform/upgrade-to-2-0

[cpursley]

This is looking pretty compelling for serverless docker: https://docs.hyper.sh/hyper/Feature/container/func.html

[manigandham]

All of the major clouds now have (or will release soon) the ability to run a Docker container and get an endpoint, with auto-scaling.

[homerjam]

I place high value on simplicity and portability so despite not being fully optimal a monolithic docker app is a good choice for me.

The reason I'm still on DO is because I need dependencies that are both large and trivial to install in docker vs. creating a custom EC2 image. To make it clear I was hoping to deploy a docker container with ffmpeg to support long running video conversions whilst benefiting from easy deploys and on demand pricing. It seems like the potential for this alluded to in the serverless docker announcement has been removed?

I can see how this V2 makes serverless simpler but the strict limits will mean that transitioning a monolithic app requires a lot of work up front. Increasing the limits would reduce that friction greatly. Whilst not best practice deploying an existing express app and have it 'just work' is a compelling reason to go serverless.

[mattste]

One of the major pain-points I've hit with this concept of a "Monorepo" is tooling support since many things are built on the premise of separate repos for each code base. Pain points: Git+Github issues, CircleCI, etc. How do you handle those problems?

[richthegeek]

Could you use git modules? Keep your distinct repos and have a monorepo that updates are PRed into?