One Application Per Cloud Server Makes Life Easier

Before the cloud, it was important to run as many applications as possible on a single server. Why?

• Because you had to use up all that juicy hardware that it took you so many months to provision.

• Because it was hard to configure and manage physical machines, so you wanted to concentrate them to make it easier for system administrators to manage.

• Because you did your best to standardize entire stacks so your J2EE applications could run in harmony in a single WebLogic instance (ha!).

• Because it was the cool thing to do.

In the cloud, it's easy to provision new servers. The means you can run each application (or just part of an application) on its own server. Why?

• You don't have to wait months for IT to give you a machine.

• You've bought into the DevOps movement and have lots of automation to help install, configure, integrate, and test your stacks and applications, so it's not a big deal to spin up a new instance.

• You're comfortable using the best tool for the job, which means you frequently deploy components written in Java, Ruby, and JavaScript.

• You use a combination of SQL and NoSQL data stores, such as MySQL, PostgreSQL, Redis, memcached, CouchDB, and HBase.

• You want to avoid dependency conflicts.

That's a nice list of reasons, but I see you're not convinced. Let's look at the really compelling reasons to separate your apps.

• It's easier to scale applications running on their own instances. You don't have to worry about dragging along Application B with its measly 1,000 hits per month when you need to scale out Application A getting 1,000 hits per second.

• Some applications don't scale as well as others. What if Application B won't even scale beyond a single instance? Load balancing it along with Application A might break it badly.

• Independent applications are safer. If all your apps are on the same instances and those instances go down, you lose all your apps at once. That's not good for SLA's and uptime measurements. It's better to spread out your risk across instances and even clouds.

• Isolated apps are easier to manage. When you need to apply an operating system patch required for Application A, do you really want to test Application B to make sure it won't cause a problem? And what happens if there's a dependency conflict?

• It's simpler to test isolated apps. In your QA environment, it's incredibly convenient to fire up new instances, test them, and blow them away when you're finished. If your applications are mixed, you need to test Application A in context with a fully configured production version of Application B to make sure there aren't unintended side effects related to forcing them to co-habitate.

Once you're on board with this line of reasoning, it's easy to see why many cloud savvy technologists also deploy key stack components on their own instances, isolated from the rest of the application. For example, you could place your application server on one instance, your caching server on another, and your various SQL and NoSQL data stores on still other instances. With this arrangement, you can easily deploy, upgrade, scale, test, and monitor each tier independently of the others. Yes, it's more work when you're just getting started so I don't recommend you do all this work right away. Instead, wait until you're done with your basic application development and have stabilized your stack components and versions somewhat. At that point, you can decide whether you believe your application needs to be exploded either for extreme scalability purposes or for the reasons outlined above. If so, break up your application into the appropriate number of pieces.

Whether or not you choose to spread your application stack across server instances, I highly recommend you put no more than one application per cloud server unless you have special circumstances in play. For example, if you value performance far more than scalability, you might want to collocate applications that communicate frequently to avoid network overhead. In most cases, you'll be better off splitting them up.

With one application per cloud server, it's easier to develop, test, deploy, upgrade, scale, monitor, and manage your software. This best practice in the cloud will pay for itself in no time.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @CloudSwing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.