(MODAClouds) Heroku
Important
This document is part of the MODAClouds deliverable D6.1, thus superseded by it.
Important
This document was created in March 2013, thus its contents might be currently outdated.
Overview
Heroku is a classical PaaS solution, featuring a large degree of flexibility for the targeted application, ranging from the largest set of supported programming languages, to the availability of third party integrated services.
What sets it apart from other PaaS's is the simplicity of developing and deploying applications that target this platform, the only requirement being to respect the general accepted best practices, as summarized in [Heroku-1] and detailed in [12factor]. For example while Google App Engine requires the developer to choose exactly one of the three supported languages, then to strictly adhere to a reduced API and use Google's customized data stores, in contrast Heroku allows the developer to run almost any well behaved web application, and exposes access to resources ranging from the classical SQL databases to distributed search indexes.
Regarding the tooling, the deployment is almost completely driven via the Git distributed versioning system, but at the same time there are CLI tools --- based on web services --- that allow full control of the application.
Characteristics
type | PaaS |
suitability | production |
application domain | web applications [Heroku-1] |
application architecture | n-tier applications [Heroku-1] |
application restrictions | container [Heroku-2] |
programming languages | Ruby, Python, NodeJS, Java [Heroku-3] |
programming frameworks | any |
scalability | manual [Heroku-4] |
session affinity | non-deterministic [Heroku-7] |
interaction | WUI, CLI, WS, API [Heroku-9] |
disponibility | hosted |
portability | out-of-the-box |
services | large palette of managed services [Heroku-6] |
monitoring | none (however there are addons) |
providers | Amazon EC2 [Heroku-2] |
multi-tenancy | multiple organizations |
resource sharing | n:1 |
Limitations
(Update 2013-06: see also the newly published limitations page [Heroku-11].)
OS resources (per instance):
memory | 512 MiB (soft-limit) and 1.5 GiB (hard-limit) [Heroku-2] |
disk | unspecified |
CPU's | unspecified |
deployment | 200 MiB [Heroku-8] [Heroku-10] |
Network connections:
inbound | HTTP exclusively [Heroku-7] [Heroku-10] |
outbound | allowed (with exceptions) |
internal | disallowed [Heroku-10] |
Notes
Although Heroku has official support for some programming languages, it can support practically any application that can be run on Linux, via their buildpack feature [Heroku-4].
As above, out-of-the-box Heroku doesn't provide any type of monitoring --- except maybe the existence of the processes --- but there are available various third party addons that monitor the running application from within. Unfortunately even with these addons we can't get any data from within the platform.
With regard to the network accessibility, for inbound network connections only HTTP --- for the domain under which the application was registered --- is forwarded to the processes with the web type, while any other access from the exterior does not seem to be supported; on the other hand, it is hinted that the HTTP router does support the CONNECT verb --- a unique feature among existing PaaS's --- enabling thus the proxying of arbitrary protocols. For outbound connections it seems that there aren't any constraints except the best practice policies, and the fact that the source IP address might change at any time. The connections between various processes, thus internal, seem to be disallowed [Heroku-10]. (The documentation isn't definitive any of these regards, especially about the existence of any quota.)
The cost does seem to be higher when compared with VM's (with higher capacity) from the underlaying provider (Amazon), and especially when using addons. On the positive side, for each application there is an amount of free time which would allow a user to run a single process for a month, (or multiple processes for a fraction of a month).
ModaClouds integration
Heroku provides unique possibilities, not found in other commercial PaaS's, for integration with ModaClouds. For once we could provide customized buildpacks [Heroku-5] that would augment the user's application code with our probes, without impacting his development, packaging and deployment experience.
Moreover, because Heroku allows the user to run multiple types of processes, and because we can customize the deployment, we could run the support services that ModaClouds needs directly inside the same application instance. On the other hand because the platform itself is hosted over Amazon EC2, we could easily deploy our services there.
Finally, the API exposed by Heroku [Heroku-9], although simple, it allows fine grained control over the application, from changing the number of instances of a certain process type, to attaching addons or accessing logs.
References
[12factor] | The Twelve-Factor App |
[Heroku-1] | (1, 2, 3) Heroku DevCenter -- The Process Model |
[Heroku-2] | (1, 2, 3) Heroku DevCenter -- Dynos and the Dyno Manifold |
[Heroku-3] | Heroku DevCenter -- Languages |
[Heroku-4] | (1, 2) Heroku DevCenter -- Buildpacks |
[Heroku-5] | Heroku DevCenter -- Scaling Your Process Formation |
[Heroku-6] | Heroku Addons |
[Heroku-7] | (1, 2) Heroku DevCenter -- HTTP Routing and the Routing Mesh |
[Heroku-8] | Heroku DevCenter -- Slug Compiler |
[Heroku-9] | (1, 2) Heroku API |
[Heroku-10] | (1, 2, 3, 4) Heroku DevCenter -- Frequently Asked Questions about Java |
[Heroku-11] | Heroku DevCenter -- Limits |