If your business is considering the cloud for your server provisioning needs, you may have very good reasons to do so. The cloud can offer a very affordable way to start a small web service with more control and security than you might get from shared hosting yet without the high cost of a fully dedicated machine. The cloud can make it very easy for you to scale your business up smoothly from modest server traffic initially to super-heavy traffic needs once the world has discovered your killer application. The cloud can allow your organization to automatically provision computing resources in response to wildly fluctuating demand during the course of a day or from one day to the next. The cloud can offload the hardware management, network maintenance, and backup responsibilities to your cloud provider so that you don’t need a dedicated staff of IT specialists.
The path to the cloud is not free of pitfalls, however. If you are planning a move to the cloud for your organization, Boomcycle would like to draw your attention to some “gotchas” that managers often do not realize before authorizing a jump into the cloud.
1) Moving Your Application to the Cloud Does Not Guarantee Scalability. While the cloud does make it much easier to scale hardware resources up or down, this does not mean that you can just keep adding more and more computing power to serve infinite amounts of traffic. There is an upper limit to the amount of RAM, the number of cores, and the storage speed that you can get from a single server — virtual or dedicated.
Depending on the popularity of your site and the nature of your application, you may need to consider a clustered architecture at some point because you have exceeded the computing capabilities of a single machine . This means that you’ll need to set up your application to utilize multiple machines to share the burden. Adapting your application to make use of a cluster rather than a single machine is typically a substantial endeavor. This brings us to our second point.
2) Your Application May Be Poorly Suited to a Clustered Architecture. It all depends on the nature of your application and the building blocks you’ve used to construct it, but it is frequently the case that even popular software packages are not designed to work in a multi-machine environment. It is usually the case that some form of modifications to the application itself are necessary to utilize multiple machines to server your customers. This might be as simple as offloading image, style, and script assets to a CDN or it might be as complex as visiting each and every query to use a different database engine. It may in some cases require radical alterations to your application.
3) The Ability to Provision Computing Resources Via API Does Not Magically Scale Your Application. Just because your cloud provider has an API which allows you to spin up new servers easily does NOT mean that your application will magically know how to scale itself. You still have to establish your own logic to recognize when more resources are needed and create processes to integrate these new resources into your cluster/system. A typical problem one faces at this stage is how to get the latest version of one’s application code onto newly allocated machines. The menagerie of little details involved in deploying one new server can add up to be a sizable task of its own.
4) Your Cloud Provider May Not Have A Suitable Code Library for Their API. If you already have a staff of developers, they are probably accustomed to working in a particular language. E.g., .NET, Java, PHP, Rails. Interfacing with your Cloud Provider’s API is easiest if they offer a nice, robust, well-documented code library written in a language that your development team understands. While most Cloud Providers offer a variety of code libraries in different languages, these are often poorly-documented and in many cases incomplete. In other cases a provider may use a FOSS API which does not take into account provider-specific features (such as Rackspace’s RackConnect feature). Depending on provider and language, your mileage may vary. If a good, solid code library is not available, your development team will end up developing code on your dime to take up the slack.
5) Provisioning Computing Resources By API Has Inherent Problems. By their very nature, dynamically allocated virtual servers come with various built-in problems. They usually have serious problems delivering mail directly so you’ll need to route all mail through a mail service (e.g., Amazon SES or SendGrid). Cloud API requests, like any HTTP request, are sometimes refused, sometimes fail, and sometimes fail to connect entirely. In many cases, you may need to design your application to try again when an API request fails. Virtual server spin-up latencies can be ghastly sometimes — or the server allocation may fail entirely. Your application may also need to account for these latencies and failures. Your Cloud Provider may offer a very limited number of operating system distros — and these images may be woefully out of date by the time your make use of one. With some cloud providers, there’s no clear way to distinguish reputable, safe server images from exploited ones. Such problems are inherent to the very nature of dynamic server provisioning and reliability can vary significantly from provider to provider.
If your organization is contemplating a move into the Cloud, consider contacting Boomcycle. Let us be your guide. We can take a look at your system and help you evaluate your options. If a move is in the cards, we can help devise a plan to insure reliable scalability.