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 DNS infrastructure.
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:
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.