Every technology company starts with a great idea. And in the early stages of application design, the decisions you make can have a long-term impact. These design decisions are critical and can make or break both the product and the company. At GoGrid, we’ve helped a lot of customers architect applications for the cloud and along the way we’ve learned a thing or two about the decisions you need to make. Here are 3 key questions to help you get started.
1. Traditional data center or cloud infrastructure (IaaS)?
One of the first and most important decisions is whether to go with a traditional data center or architect in the cloud by leveraging an infrastructure-as-a-service (IaaS) provider. Although a traditional data center provides absolute control over hardware and the software, there’s a significant downside to maintaining the hardware. These costs can be significant, but if you move to the cloud, you can avoid them completely. The GoGrid, Amazon Web Services, and Microsoft clouds are all maintained by professionals, allowing you to focus on your application rather than the hardware. By going with an IaaS provider, you also gain application flexibility that lets you scale resources up and down as needed. And we can all agree that in most cases, scaling an application horizontally is preferable to scaling vertically. This option is especially important when your application reaches global proportions and you require specialized features like global load balancing to ensure minimal application latency or even support for regional application variations (think multiple languages for global applications).
2. Where does multi-tenancy reside?
In most cases, you’ll also need to make a decision about where multi-tenancy resides. If you were to architect in a traditional data center, you might take a shortcut and decide to put each customer on a separate machine. However, doing so would be a mistake for a few reasons. First, applications no longer run on a single box that’s scaled up, which means isolating users to individual machines no longer makes much sense. What’s worse, that approach would create a management nightmare by requiring you to monitor thousands of machines as your application scales users. Plus, this type of architecture locks you into a particular vendor or service provider, and you probably don’t want that. So where should multi-tenancy reside? The answer is easy: It should reside in the application layer above the virtual machine or server layer. By architecting multi-tenancy into the application layer, you’re free from lock-in and able to scale resources as needed, avoiding costly over-provisioning. You’ve also allowed customers to scale beyond the resource constraints of a single server. Equally important, this approach lets you architect failover scenarios that ensure high availability and consistency even if the underlying platform has an issue.