6 Aug 2015 in Series: App Principles, Legacy Apps

Share Nothing, Scale Everything

In the previous post in this series, we explained how the shared-nothing architecture places additional constraints on cloud app developers. We also explained how embracing these constraints enables apps to have high scalability and high availability.

In this present post, we explain how to adapt an app for the cloud by removing any dependency on the file system, in order to make it compatible with a shared-nothing architecture.

Replacing the File System

A tower of filing cabinets set against the sky

Putting your file system in the cloud is asking for trouble...

If you’re deploying an existing app to the cloud, whether it’s an internal app or an off-the-shelf app, you may find that there are some points of contention.

The most common problem we have found is that apps designed for traditional hosting environments expect the file system to behave like a database. That is, they write out a file, and then expect that this file is going to exist at some point in the future.

This is a problem for languages like PHP, where many of the off-the-shelf apps have existed since long before the cloud was popular. These apps generally assume that you are only using one server, and that the master copy of your site lives on the server.

Unfortunately, this causes some problems. This model does not work when you want to scale across multiple servers, or when you want to keep the master copy of your site in a revision control system like Git.

Let’s take one example: WordPress. The default WordPress configuration requires write access to the wp-content directory on the local file system. If you log into the WordPress administration console and make some changes, WordPress may update a file on the local file system. But if you have multiple servers, none of the other servers have this updated config.

If, on the other hand, you re-deploy from Git, your configuration changes will be overwritten! You could try to use something like gitdocs to automatically propagate changes, but what happens when you have a merge conflict, or your local state becomes particularly byzantine? Your app could fail instantly, or it may even experience hidden corruption, failing later in such a way that makes it difficult to debug.

So what’s the solution?

Read More
6 Aug 2015 in Deis v1 PaaS

Deis v1.10 Community Release Planning Meeting

The Deis open roadmap is influenced by the needs and concerns of our community. To help us plan Deis releases, we invite the community to attend monthly release planning meetings to share with us any issues they'd like to see addressed in the next release.

This week, we held a planning meeting for Deis v1.10. A video of the meeting is on YouTube.

Meetings are coordinated on our mailing list. If you're not already a member of the deis-users mailing list, I'd encourage you to sign up. We have a great community of users who share all sorts of experience running Deis in different environments.

See you at next month's planning meeting!

4 Aug 2015 in Series: App Principles, Legacy Apps, Perspective

Functions, Threads, and Processes. What's Next? Cows

In the previous post in this series, we discovered that setting up a server before you even boot it is not only possible, but gives enormous productivity rewards in a cloud architecture. In this post, we look at the four essential principles of designing your app for the cloud.


Using a cloud architecture places extra constraints on app developers. These constraints cannot be worked around, and therefore app developers must get to grips with them before they start designing their apps.

Because the constraints are often unusual and unintuitive, it is worth also understanding the context behind the constraints. Why are they necessary? How do they improve the reliability of applications? Are there no alternatives? With these questions answered, an app developer can plan more confidently, knowing that they are taking the optimum path.

All of the core constraints emerge from one fundamental principle: cloud computing must account for random failures. To cope with this you will need multiple servers, and when you have multiple servers you also need a strategy for setting up and maintaining these servers with as little effort and as few subsequent interventions as possible. Such strategies are said to belong to the cattle model, because they contrast with the usual non-cloud method of dealing with servers as something like pets.

Read More
30 Jul 2015 in Series: App Principles, Legacy Apps

Configure Before You Boot

In the previous post in this series, we learned how the pets vs. cattle metaphor teaches us a new way of approaching cloud server architecture. Instead of unique pets which require constant, individual care, we focus instead on cattle which are identical, homogenous units that can be added en masse and removed with ease. Cattle servers are, in other words, fungible resources.

"It takes a family of three to care for a single puppy, but a few cowboys can drive tens of thousands of cows over great distances."

Joshua McKenty, CTO of Piston Cloud

This post explains more about the cattle mindset, sometimes called the noflake approach. In contrast to a pet server, which is looked after by an administrator beavering away at a console, we want cattle servers to be configured with no intervention at all.

Read More