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
23 Jul 2015 in Legacy Apps

Pets vs. Cattle

I was one of the original developers on Orchestra, the PHP PaaS that Engine Yard acquired in 2011. Many of our customers were using PaaS for the first time, having come from very traditional hosting backgrounds. They were used to uploading things to FTP servers and editing config files remotely — a practice that is still widespread, despite the popularity of Git and sites like The Twelve-Factor App. It is made all the more prevalent by the fact that many off-the-shelf PHP apps are quite old, and still assume this sort of deployment scenario.

Now, this isn’t to be scoffed at. Traditional system administration is based around the notion of physical machines. To add a new machine to a cluster, you might have to purchase it up front, configure it in your offices, and then drive it to your colocation data centre to install it. That could easily take a few weeks. And if that machine later develops a problem, you do your best to fix the issue via SSH. And if that’s not possible, you might have to drive back out to your colocation data centre to fix it or replace it.

Read More