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:13pm
the "rush" is in the interest of truth-seeking. We, and I, learned a tremendous lot from that beta. I learned what works and what doesn't. I truly think this new world shouldn't wait and our customers will benefit immensely from it.
I think these systems are all in competition to one another to a very large extent, and I think this is the winner.
like-fill
1
  • reply
  • like
I think all the systems that are embracing the stateful monolithic servers will collapse under their own weight. I think this is also true for the "service mesh" clusters, but those will collapse under both weight and accidental complexity.
  • reply
  • like
So, if you really think that's the future, I'm ok with some customers going in that direction. I think they'll pay a steep price.
  • reply
  • like
That price is not only in the execution cost (paying cents for 100ms of execution vs a monolith running 24x7), but the most concerning part is how much you'll pay for engineering and optimization costs.
like-fill
2
  • reply
  • like
on the app portability side of things, the commitment there is more strong than ever before:
  • reply
  • like
- All of your code should use the language / framework APIs, not custom APIs. [This is what I truly think has been holding serverless back! Lots of weird APIs, context objects and API gateway interfaces 🤨]
Edited
like-fill
2
  • reply
  • like
- All the clients and builder code is MIT licensed and open source, and you can write your own.
like-fill
1
  • reply
  • like
The biggest testament to this is that Next.js continues to work the same way it always has, but then we built a little /next builder to make it compile to serverless easily.
Edited
like-fill
2
  • reply
  • like
But is a custom now json with build and routing that is specific to now but also essential to the workings of the app not by definition lock into now. i am not saying that’s not fair, lots of cloud provider features are proprietary but still offer lots of value. I just try to truly see where now is headed in this regard
like-fill
3
  • reply
  • like
Speaking about the price, how is billing calculated for people that can't migrate all of their instances to v2?
For example I upgraded from Premium to Unlimited, but I realized I can only migrate 1 of my 3 services to v2.
I still have a Next.js app with a custom server and a Python server in a Docker instance running 24x7.
How is that going to be billed on the Unlimited plan?
  • reply
  • like
Not more than a Dockerfile is also a set of instructions that have to be parsed and executed by a runtime, of which many can be written. If anything, now.json is now as simple as it can possibly be. It consists of just two fields primarily: builds and routes :)
  • reply
  • like
(And the routes config is standard PCRE for src matching)
like-fill
1
  • reply
  • like
the old instances will be measured as on-demand of now v1, the new deployments as on-demand of v2
  • reply
  • like
Can you please write the prices for on-demand v1 here? I can't seem to find them on zeit.co since Now v2 has been announced
  • reply
  • like
that’s a fair point, and answers my question. thx
like-fill
1
  • reply
  • like
So if until now I was paying $15/month for 4 instances (2 services deployed in sfo1 and bru1), on unlimited am I going to pay $0.025 * 24h * 30d * 4 instances = $72 ?
  • reply
  • like
The difference between Docker and Now is, however, that Docker can be deployed everywhere, also on premise.
like-fill
4
  • reply
  • like
the main premise of of serverless is that request-response invocations very rarely run 24x7 :)
  • reply
  • like
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
Show more messages
private
This conversation has been locked
private
This channel has been archived