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 now 11.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 DNS infrastructure.
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.
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:
X-Now-Trace: sfo1

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:
X-Now-Trace: sfo1,bru1

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 environment variables:
  • NOW_DC=sfo1
  • NOW_REGION=sfo
This is useful for instrumentation or determining, for example, the closest database or storage bucket to connect to.
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. Deployments are always global. Once your code is successfully deployed, it runs wherever in the world is it enabled.
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).
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.
To try it out, just run now inside a directory, or now file.txt for a direct file upload.
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.
If Now is not yet at your nearest major airport, stay in touch.