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
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.
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
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).
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.