Platform-as-a-Service (PaaS) provider Heroku recently announced an expansion of their global footprint and introduced a set of architectural updates. Although missing a Safe Harbor agreement, Heroku is the latest PaaS vendor to establish a European presence. They have also added a new “scale up” options for cloud processes, isolated networking, and a tool for checking the production readiness of an application.
Heroku – owned by Salesforce.com – is one of the original providers of PaaS services and supports applications written in Ruby, Java, Node.js, Scala, Clojure, and Python. Instead of deploying applications to virtual servers, Heroku developers interact with compute units called dynos, which are isolated containers that run web or worker processes. Dynos traditionally have 512 megabytes of memory and developers are trained to scale applications out to more machines when a dyno’s capacity is reached. While Heroku is a mature cloud provider known for its robust add-ons marketplace of cloud services and innovative features like their data snapshots called Dataclips, they’ve spent a good portion of 2013 repairing customer trust after failing to disclose changes in the platform that resulted in poor performance and excessive costs. However, this recent collection of platform improvements has begun to change the narrative for the company.
In a recent blog post, Heroku announced access to European data centers as part of a public beta. The platform features available in Europe match those available to US customers. Heroku promises lower latency for European users while delivering a unified management and deployment experience regardless of where the developers and administrators reside. A subset of the add-ons marketplace is available for European applications and many of those latency-sensitive add-ons are deployed directly within the European region. Heroku is providing developers with a tool – called heroku fork – that migrates an application from the US region to the European region. Heroku joins other PaaS providers with European data centers including Microsoft Windows Azure, Google App Engine, CloudBees, and Engine Yard. However, unlike Windows Azure and Engine Yard, the Heroku PaaS does not yet participate in the EU Safe Harbor program. According to Heroku, this certification is on the way.
Heroku is not yet a registered participant in the Safe Harbor program. We’ve laid the groundwork for becoming Safe Harbor certified and expect to have it soon. The Europe region public beta is designed to let you build high-performance apps for European users. It does not currently address data residency or jurisdiction concerns. You should assume that some portions of your app and its data will be in, or pass through, datacenters located in the US.
Heroku is also changing how applications scale on their platform. With the introduction of 2x dynos, application developers can now provision compute units with 1 gigabyte of memory and twice the CPU of a traditional dyno. In a blog post by the Heroku team, they provide three use cases for scaling vertically.
1. Concurrency for Rails with Unicorn - The first use case is increasing concurrency on single-threaded Rails apps using Unicorn. Due to the improved in-dyno queuing efficiency that results from increasing the number of Unicorn workers, doubling the workers in 2X dynos while halving the dyno count often results in better performance.
2. JVM Languages - The modern JVM has an explicit memory model designed for multi-threaded concurrency, and has many frameworks explicitly designed to take advantage of this property. Utilizing more threads requires more memory for both the thread stacks and for objects created by these threads. The JVM is fully capable of taking advantage of the vertical scale in a 2X dyno.
3. Memory-intensive background jobs - image processing and geospatial processing often need larger dynos. If you’ve gotten an R14 out-of-memory error and this is not a leak, 2X dynos might be for you.
Not every application will benefit from additional compute power and memory, and Heroku encourages developers to use a variety of tools to uncover whether horizontal or vertical scale will improve application performance. Heroku highlights the open-source log2viz dashboard that shows memory and CPU consumption, and an add-on from leading Application Performance Management vendor New Relic to point out concurrency issues.
The networking model offered by Heroku is also changing. Previously, dynos shared network interfaces and this resulted in what they describe as a “low grade information leak” where dynos could potentially observe connection details from other dynos. No longer. Heroku now provides fully isolated network configurations for each dyno, as described in a bog post.
For local networking within a dyno, processes can now listen and connect on any port they want. This lets you use the local network interface to send data between processes running in a single dyno. Dyno network interfaces are firewalled off from the external network access, including from other Heroku dynos. For a web dyno, the only permitted external network access is on the TCP port specified in the
$PORTenvironment variable. This is the port used by the Heroku router to forward HTTP requests to the dyno.
Heroku has made this change to all dynos and claims that no updates are needed for running applications. However, they admit that a few bugs have crept up but they have quickly issued updated components for developers to use.
Finally, Heroku introduced Production Check which examines applications and looks to see if best practices have been applied. Applications are tested for dyno redundancy, correct DNS and SSL settings, use of a production-grade Heroku Postgres database, and properly configured monitoring and logging. While this optional verification process is far from comprehensive, it offers a valuable service to developers who may not be familiar with deploying cloud-friendly applications to a distributed, public PaaS.