Tag: Legacy Apps
11 Aug 2015 in Legacy Apps, Perspective

Why Your App Won’t Work In The Cloud

There are two kinds of apps for the cloud: ones that work and ones that don’t. The ones that work are called Twelve Factor apps, and they work because they were written specifically for the cloud. We call the ones that don’t work legacy apps. And these are designed to run on traditional VPS hosts.

Unfortunately, most popular apps are legacy apps. They weren’t written with the cloud in mind, so they generally won’t work without modification. Legacy apps include offerings such as WordPress, Magento, and Drupal. They might also include any in-house apps you are thinking about moving to the cloud.

So what’s to be done about this? Is there any way to run legacy apps in the cloud?

Read More
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.

Read More
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.

Introduction

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.

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