Orchestra Elastic Apps For Everyone

It’s been a long time coming, but we’ve finally made our auto-scaling elastic app capability available to everybody on Orchestra. Previously, this was only enabled on an account-by-account basis. An elastic app is smart enough to scale up when your traffic increases and scale down when your traffic decreases. You don’t have to do anything, and you can deploy this sort of app right away. Sign in to your account now and select “Deploy An Elastic App” from the sidebar.

So how exactly do elastic apps differ from basic apps? Well, our basic apps offer you a single fixed amount of resources. For small apps, or staging versions of your production apps, this is fine. But for bigger things that need to handle a variable load, we have elastic apps. These apps start with one scale unit and increase by one scale unit at a time as your resource usage increases. As resource usage decreases, we scale you down by one scale unit at a time too.

But what’s a scale unit? One scale unit provides up to 1.2 GB RAM and 2 Dual Core CPUs burstable to 1GHz. Behind the scenes, this may be provided by one or more server instances. We do this to maximize the redundancy of your app, and its fault tolerance to network outages, restarts, and other low-level problems that you shouldn’t have to worry about. This ability to recover from problems ensures that your apps are auto-healing, as well as auto-scaling.

What does this mean for your app? Well, on a day to day basis, the app will run with as many scale units as it needs to function properly. You don’t have to guess at what this might be, because our system works it out for you. And when someone links to your site in the middle of the night, and you experience a traffic peak, we scale you up to handle the increase in resource usage. And then we scale you back down again when traffic returns to normal.

How should you write elastic apps? Well, if you want to take advantage of our auto-scaling and auto-healing, your apps will need to embrace a shared-nothing architecture. In the general case, that means you need to design your app so that individual instances of it can be killed off and respawned at any moment. This means keeping all your data in separate database like MySQL or MongoDB, which we provide addons for. And it means that you need to write file uploads to a shared storage service, such as Amazon’s S3. But whatever you do, don’t write anything important to local filesystem, or it will be lost when we auto-scale or auto-heal.

If you have any questions about this, or about how best to build elastic apps for Orchestra, please get in touch. At the moment, apps are capped to eight scale units. If you need more than that, you can request a higher cap by submitting a support ticket. In the future, we plan to add more intelligent ways of handling and safe-guarding scale unit allocation. We’d love to hear your thoughts. And if you haven’t seen it already, check out our revamped pricing model.