This post contains content about Now 1.0 – Learn about the latest version, Now 2.0.
Now 2.0 - Upgrade Available
Earlier this year, we announced
our Global Anycast DNS. By
using our upgraded nameservers, your users will resolve
domains hosted on our platform in
just milliseconds, anywhere in the world.
Today, we are happy to announce the general availability of
our BRU1 (Brussels, Belgium, Central Europe) datacenter.
In addition, we are happy to announce that all static
deployments will be automatically served by our two production
datacenters (SFO1 and BRU1).
If you have deployed statically with Now, odds are that your
users are already enjoying drastically reduced latency worldwide.
This brings us even closer to our vision of a Global CDN
that works just as well for dynamic workloads
and static content, with
a simple interface and API.
In this blog post, we will go over:
How to take advantage of global scaling for your deployments
The new additions to now, now scale and our API
The consistency and reliability model for your deployments and rollouts
Go Global with One Command
As of now11.x.x, which
is immediately available,
you can now take any deployment you make and scale it
to your preferred region.
If you want to decide to which regions your deployment
can be enabled ahead of time, you can
use the --regions CLI parameter
or regions in now.json.
'now --regions bru'
Your deployment will only execute and scale in Brussels
We previously enabled you to mutate the scale settings of
an existing deployment. We have thus
extended the now scale command to accept regions:
now scale my-web-service-jifhg2.now.sh all
The special all keyword refers to every single available datacenter in the Now cloud
You can deploy and scale to a single region
identifier (bru or all), a specific datacenter (sfo1 or bru1) or
supply a comma-separated list. Refer
to our docs for more details.
Just like before, when you invoke now alias to associate a
deployment with a known domain name, we ensure the
scale settings are the same as the currently
aliased deployment, for zero-downtime rollouts.
Regions and Data Centers
We are taking this opportunity to formalize the
nomenclature by which we refer to our infrastructure.
Regions refer to the general geographical area where datacenters
are located. They are named with
an airport code for
ease of identification and memorization. It is worth noting that
we tend to pick recognizable airports, thus
they should be taken as a loose reference.
Regions, however, are used as a convenience. When our clients
make API calls to configure the scale settings
of a deployment, they always translate them into a distinct DC identifier.
The DC identifier refers to the physical datacenter where your
code is executed. Its structure is the region
identifier followed by an integer:
Our multi-dc deployments give you lower latency and
increased reliability, by spreading the execution of your
code across infrastructure providers.
Now automatically distributes your deployment's load across
the regions you have scaled to by leveraging our Anycast
After globally scaling your deployments, the next obstacle
is routing your users to the geographically closest instance.
Our DNS takes care of that automatically, which means all
you need to do is run now alias and
point it to your scaled deployment.
In addition to api.zeit.co, we have made *.now.sh also
automatically resolve to the nearest cluster.
If a request ends up at a Now load balancer where a deployment
is not currently enabled or ready to execute, we
automatically forward the request
to a datacenter where the application has been scaled.
Debugging and Introspection
We have taken several steps to improve your ability to inspect
your deployment's configuration, state of
distribution and routing topology.
If you run curl -I https://zeit.co to get the response
headers from this very
website's deployment, you will see a new header:
Since we are testing from San Francisco, we were taken directly to our sfo1 datacenter
If our deployment was configured to only serve
traffic from Europe, you might instead see the following:
The trace shows the hops taken (the last item is the DC that served your request)
All new deployments will get a NOW_DC environment variable
with the identifier of the datacenter in which
the deployment instance is executing.
For example, when your deployment instance is started
in our sfo1 datacenter, your deployment will receive two
This is useful for instrumentation or determining, for
example, the closest database or storage bucket to connect to.
Inspect with `now inspect`
We have introduced a new way of inspecting the configuration, state
and events associated with your deployment, all
in one view. Just run now inspect <url>:
now inspect shows you config, realtime cluster state and the log of events
Several APIs were improved and introduced to create this
command. We will be discussing them in depth in coming
blog posts. In the meantime, check out
our API docs for more details.
Historically, we have referred to the term "deployment" as
an all-encompassing term for initializing, storing
and building your code as well as executing it.
It is important to now make a strong distinction of the two phases.
Deployment is the process by which we prepare and store a bootable image of
your application and its metadata.
The deployment lifecycle has been simplified to
the following states, which you will see when you invoke now ls:
The state property indicates the state of your deployment
INITIALIZING: Your deployment is being prepared (i.e.: built) for execution.
ERROR: An error occurred during the initialization phase.
READY: The final state. At this point we have a globally replicated, redundant and reproducible image ready to be executed.
Thus, when you invoke now:
We render the deployment URL as soon as the deployment is INITIALIZING.
We render useful logs of the build stage, if any.
We configure the scale settings to be the closest region to you. Since our API v2 release, we already route all API requests to your nearest cluster.
Finally, once we have detected the deployment can execute and receive traffic in that region, we exit 0. This means that at least one deployment instance has to successfully run (a deployment can be comprised of 0 to ∞ instances).
Effortless CDN: Free Global Static Deployments
Static deployments are free – they do not count toward any plan
limits and you can deploy as many times as you need.
With the rollout of the bru1 datacenter, you now effectively
have free static global deployments, out of the
box, as part of the same system.
We are very excited about what this announcement presents to our customers.
Not only will you be able to offer vastly reduced latency to
your customers, this update significantly increases both reliability
and robustness of your existing deployments. If you
scale your deployments globally, you will be serving
traffic from two independent cloud providers and regions, providing
redundancy in the process.
In the coming days and weeks we will be discussing interesting
technical aspects of the architecture, including a deep-dive into
the architecture, our global database setup and more.