menu

ZEIT

Our mission is to make cloud computing as easy and accessible as mobile computing. You can find our Next.js community here.

Channels
Team

clarify future support of docker on now platform

November 8, 2018 at 6:21pm
The ZEIT community has a new home. This thread is preserved for historical purposes. The content of this conversation may be innaccurrate or out of date. Go to new community home →

clarify future support of docker on now platform

November 8, 2018 at 6:21pm
It seems zeit is moving away from allowing customers to utilize Docker as a common 'primitive'; would you kindly clarify this?
Show previous messages

November 9, 2018 at 8:37pm
you literally only pay for what you truly use
like-fill
1
  • reply
  • like
vs having dead space allocated in a server
like-fill
1
  • reply
  • like
the same will be 100% possible for Now 2.0, and that's why we're not locking you in and make you change your code
  • reply
  • like
And you'll actually have a greater variety of deployment targets
Edited
  • reply
  • like
For example, let's say you go to a company that really strongly prefers using Google Cloud. You'll be able to tell us that you want your deployments to be in affinity to a particular Google Cloud region or account.
  • reply
  • like
Or, let's say you want to go legacy mode and run it in servers that run 24 x 7 that you have to actively monitor and observe and get paged for.
  • reply
  • like
I understand, and I would love to take advantage of Lambda. But I'm in this ugly situation where I can't easily convert my services to lambda. So the pricing has gone over the roof in my case. Can I at least downgrade to Premium until I find a way to convert my services?
  • reply
  • like
We'll give you the wrappers to containerize the app as well (similar to now dev)
  • reply
  • like
But that's when you start to realize that the whole enterprise of running things on premise will make little sense.
  • reply
  • like
So deploying a Python Flask app with multiple endpoints will be possible without Now-specific changes?
  • reply
  • like
Between the option of being paged at 3am to restart a server
  • reply
  • like
Or things running quickly on-demand and paying no maintenance costs
  • reply
  • like
The equation becomes quite simple.
like-fill
1
  • reply
  • like
that's what we are working on right now
  • reply
  • like
In fact, we are doing that because we want to welcome more devs to our platform
  • reply
  • like
But anyone today could be writing a flask wrapper
  • reply
  • like
How would I go about deploying a "traditional" express server with non filesystem-based endpoints?
  • reply
  • like
I legit just recently switched my NodeJS app to use Docker because that's the advice I was given by the team here when I didn't want to use yarn to install my packages. Now I have to switch to something else?
like-fill
2
  • reply
  • like
I feel your pain, I just did that this last week
  • reply
  • like
How would I go about deploying a "traditional" express server with non filesystem-based endpoints?
like-fill
1
  • reply
  • like
, It's not recommended because you lose most of the benefits, but you can run your node or express server as a lambda using the now-node-server builder
  • reply
  • like
I tried that, it just shows a directory listing with "src", and I open it, it errors with Internal Server Error
  • reply
  • like
What Zeit should realize is that I'm well willing to accept the tradeoff of having an app that is up 24x7 consuming resources (e.g., Docker-style NodeJS app) and paying a few more dollars/cents if that means I don't have to write code like this. In other words, the need for serverless isn't a problem I currently have. I understand that it's more efficient, but those benefits only make a material difference for really large applications.
If I have a low-traffic app, the serverless model vs docker isn't going to make a ton of difference. I'm already only paying $15 a month. Price isn't a top concern.
like-fill
9
  • reply
  • like
Getting an out-of-the-box wrappers for Flask apps would be awesome, but I can also see how it can be done manually, now, that you mention it. I totally agree with your arguments in favor of serverless deployment. I'm thinking of the many companies that cannot (for some data privacy reason or other political reason) deploy on Now or even big cloud providers and for those we need to be able to offer on-premise deployment. But we wouldn't want to write an app twice - one for deployment on Now and one for on-premise deployment. A wrapper sounds like a good compromise, at least for some/many scenarios.
Edited
  • reply
  • like
What Zeit should realize is that I'm well willing to accept the tradeoff of having an app that is up 24x7 consuming resources (e.g., Docker-style NodeJS app) and paying a few more dollars/cents if that means I don't have to write code like this. In other words, the need for serverless isn't a problem I currently have. I understand that it's more efficient, but those benefits only make a material difference for really large applications.
If I have a low-traffic app, the serverless model vs docker isn't going to make a ton of difference. I'm already only paying $15 a month. Price isn't a top concern.
Adding on to that:
  • reply
  • like
Show more messages
private
This conversation has been locked
private
This channel has been archived