As the world becomes more cloud-centric, and more of our apps and business depend on its capabilities, the trust, control and management of cloud services is more important than ever. Since the first days of Heroku — and Platform-as-a-Service in general — many companies have struggled to balance the impact and success of the cloud with the control offered by traditional software and on-premise infrastructure. Too often that balance tips back towards software, with companies choosing to meet those requirements by building and running their own platforms, inevitably becoming frustrated by the resulting complexity, cost and poor experience.
Today Heroku is introducing Private Spaces, a new Heroku runtime that delivers the best of both worlds; the simplicity and success of the cloud, combined with the network and trust controls historically only available with on premise, behind the firewall deployments. Available today in public beta, Private Spaces is powered by Heroku Dogwood — an all-new runtime architecture that augments the current Cedar runtime. Spaces are being released as part of Salesforce’s new App Cloud, also launching today.
Heroku Private Spaces
A Heroku Private Space contains all of the familiar elements of a Heroku app, including dynos and data services. These elements are deployed and run in network isolated environments, separating the “private” application, including its associated data, from the “public” systems that keep it up, running and healthy.
The new mix of multi-tenant control plane with private runtimes is what makes this architecture unique, and allows it to share an identical development and deployment experience with the Heroku you know today. You develop and deploy apps in Private Spaces just like you would normally on Heroku; Heroku Button, git push deployments, review apps, pipelines, seamless scaling, self healing and Elements Ecosystem — are all included in Private Spaces.
Even better, this isolation architecture also allows for more geographic control; Spaces can be deployed in Frankfurt, Germany, Tokyo, Japan, or in the United States in either Virginia or Oregon, with more regions to be added in the future.
Using Private Spaces
Creating a Private Space is as simple as executing a single command
$ heroku spaces:create acme-prod
Once provisioned, the Heroku experience is the same as you use today, with the addition of a new space flag:
$ heroku create myapp --space acme-prod
You can also create and manage spaces from the dashboard:
Once created, the space becomes a deployment target for your apps, much like Cedar is implicitly today. You can create multiple apps within a space, each with its own set of dynos and add-ons; since they share a space those apps will share a network boundary and associated network controls. And those apps and spaces can sit alongside your Cedar apps; it is expected that developers will use both Private Spaces and traditional Heroku depending on the requirements and development stage of a given app.
Most importantly, there are no additional configuration or operational requirements to use your space; it runs and scales just like the rest of Heroku. Under the hood, the components that comprise a space are run and managed automatically - despite the fact that spaces are private, there is no additional operational burden for developers using them.
Global Regions
Since Private Spaces are discrete, self contained Heroku runtimes, they can be deployed with new kinds of flexibility - including new geographic options. As part of provisioning a space, you can specify one of the newly supported regions.
$ heroku spaces:create acme-jp --region tokyo
From there, the rest of the experience is transparent, and any operation associated with that space - including creating new apps, scaling dynos or even adding Postgres or Redis data stores, will automatically happen in that region. Note that Heroku's core services, such as git repos, app builds and the control API service, are located in the Virginia region and will not be local to spaces running elsewhere.
Secure Enterprise Service Connectivity
Applications in a Private Space reside in an isolated virtual network with access controlled at the network level. Space administrators can choose from which other networks applications can be accessed and thanks to a built-in NAT gateway, apps in a Private Space can be granted access to restricted services in other networks using IP allowlisting.
This makes it easy to create a secure production environment for Salesforce applications where Heroku dynos and databases can process and store customer data within a secure, locked-down network boundary. Similarly, Heroku apps can now be securely integrated with on-premise services protected by network access controls allowing developers to move more workloads to the cloud.
Private Data Services
Few applications consist of just running code. One of the most critical parts of an application from a security and governance perspective is the database. The ease with which data services can be added and managed on Heroku has always been critical to rapid delivery and the overall experience.
Data services in Private Spaces are exactly as easy to create and manage as they have always been. Simply add the add-on as usual:
$ heroku addons:create heroku-postgresql:standard-4
Creating postgresql-triangular-2817... done
Adding postgresql-triangular-2817 to myapp... done
Setting DATABASE_URL and restarting myapp... done, v3
This database will be created in a private space.
Heroku automatically detects that the app is in a Private Space and sets up a new database within the Private Space. You can verify this by looking at the DATABASE_URL:
$ heroku config:get DATABASE_URL
postgres://udv...:pd0...@10.1.32.86:5432/db36mo7ajub9dg
The database host has an IP address in the non-publicly-routable 10.0.0.0/8 address space and cannot be accessed directly from the Internet. The same is the case for Heroku Redis. The data services can only be accessed from dynos in the same Private Space and via a bastion host by users with explicitly granted access and valid Heroku credentials.
Dyno Networking
Dynos running in a Private Space are connected to a single private dyno network allowing dynos to communicate with each other using any TCP or UDP port and protocol. This lets you do new and interesting things with your Heroku apps. For example, web dynos can communicate with each other and share session state over a gossip protocol. Web and worker dynos can communicate with each other without going over the public Internet. Dynos from different applications can even talk to each other as long as they are in the same Private Space. This can be useful for deploying diagnostics applications that consume diagnostics streams from other application dynos over the private network.
Space Access Controls
Being part of Heroku Enterprise, Private Spaces take full advantage of fine-grained access controls. Access control can be delegated to apps inside Private Spaces allowing organizations to manage large application portfolios without unnecessary bureaucracy.
The new network controls allow for elegant separation of responsibilities where Space administrators control network access while developers retain maximum self-service deployment without compromising security.
Learn More
You can learn more about Private Spaces by attending our technical deep dive on October 8th, where we’ll walk through a live demo and go deeper into different use cases. If you’re attending Dreamforce, you definitely want to attend the Private Spaces session on Thursday at 12pm or stop by the Heroku area in the Dev Zone anytime to get a live demo. You can also hear from a current participant of the Heroku Private Spaces limited beta on Friday at 10am with Align Technology, who’ll be sharing their experiences using Private Spaces for multi-region and network-isolated applications. Heroku Private Spaces is in limited beta today; you can get on the list to participate in the betas today.