The Deis project is happy to announce v1.9.0, which introduces Kubernetes and Mesos tech preview schedulers, provides custom health checks for your apps, and lays groundwork for the future with graceful upgrade tools.Read More
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
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
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
Please join us in welcoming Kent Rancourt as a core maintainer of the Deis project!
Kent Rancourt is a software engineer, lifelong martial artist, avid hiker, and self-described comic book nerd. His background is in application development and architecture as well as devops.
Kent lives in Connecticut and will be working remotely. He'll be focusing on production-hardening Deis.
Follow Kent on Twitter: @krancour