So you’ve made the decision to dive into “the cloud” head first. One question: Why? Don’t misinterpret our curiosity: there are many benefits to using cloud technology over more traditional hosting methods. However, it’s important to remember that “the cloud” isn’t all magic behind the curtain, and great caution must be taken when making new operating and engineering plans.

Let’s start from the beginning. It’s a common mis-conception that cloud computing is powered by newly discovered technologies, but the basics have existed for quite some time. In fact, there are many similarities between cloud computing and the mainframes of the 20th century. Under any cloud’s hood, there are servers, powered by electricity, networked together across one or more data centers. In most setups, a software- based layer of virtualization enables multi-tenancy on each physical machine. Additional software packages, likely customized by a specific provider depending on what services are being offered, complete the stack. It’s the combination of these data centers and overlying software, abstracted away from the end-user like a “black box”, that enables providers to offer public cloud services to their customers. Alternatively, when a business decides to rely on its own resources for cloud computing, the company has then chosen to implement a self-maintained private cloud.

Because the majority of technology behind “the cloud” is software-based, there is a wide range of potential service (“as a service”) offerings across different levels of the hosting hierarchy - and it’s easy to get overwhelmed with acronyms:

  • Infrastructure as a Service (IaaS) solutions abstract away the physical servers, electricity, HVAC, network, and other data-center requirements and deliver virtual server instances to end users. Examples include Rackspace Cloud and Amazon EC2, which offer Linux and Windows servers on- demand without revealing specifics of data center locations, physical hardware specifications, or other users of the services.
  • Platform as a Service (PaaS) solutions place a layer of abstraction on top of raw server instances, offering out-of-box web hosting or even source control management. In these cases, all of the data center infrastructure and operating system(s) are abstracted away from the end user. Examples include Bitlancer Strings, Amazon Map Reduce, Amazon Simple Queue Service, and Heroku.
  • Software as a Service (SaaS) solutions place multiple layers of abstraction on top of raw server instances, offering services like email hosting or accounting software. In these cases, all of the data center infrastructure, operating system(s), software to power the technology, and software to maintain the product are abstracted away from the end user.

In any of these offerings, some level of the stack is out of sight from end-users like you, creating the non- transparent “cloud” of mystery and the potential benefits and headaches that go with it.

All implementations, whether public or private, are vulnerable to stability problems and bottlenecks. Like any other data center, system resources are prone to failure, and technicians still handle hardware installation and troubleshooting. In fact, most clouds are built on top of commodity hardware, which is likely subject to higher failure rates and diminished fault-tolerance. In developing a cloud architecture plan, it’s important to balance the benefits of cost savings with risk tolerance and an acceptance of cloud limitations. It’s scary to see the flood on Twitter when a portion of the Internet becomes unresponsive and an entire page of tweets fills up with complaints about public cloud downtime - we have screen shots. In these cases, providers attempt to resolve their issues while also handling thousands of “eta” requests that they simply can’t keep up with. In Infrastructure as a Service offerings, you will encounter ephemeral instances (hosts that fail to respond after a certain period of time), restricted I/O, noisy neighbors, and forced horizontal scalability. Platform as a Service or Software as a Service solutions are very high-level and “black box” to the end user. While these solutions often save time, complexity, and cost, customers are at the mercy of the preparedness and transparency of the provider should trouble arise. Keep in mind that many Platform as a Service and Software as a Service products are built on top of Infrastructure as a Service offerings: when there’s trouble at the lower level, it moves up the stack fairly quickly.

We’re not trying to dissuade anyone from using cloud technology, especially with a hybrid or properly implemented private model. Utilizing the public cloud is a great way to save time and money, especially for a young start-up. Running a data-center is hard work, and traditional shared hosting can only handle so much traffic before bottlenecks begin to become apparent. The ability to instantaneously scale cloud resources when necessary should be quite attractive to teams looking to experiment, move fast, and not be blocked by lack of available horsepower. Most cloud stacks, whether public or private, tend to offer API support, allowing customers to automate the deployment of new resources. Also, depending on the expansiveness of the product offering you choose, you may be able to limit the amount of in-house operations team members, potentially saving staffing costs. Most importantly, properly-utilized cloud technology can help engineers focus almost entirely on developing their product, and worry less about infrastructure, back-end operations, and support. However, it’s very important to keep in mind these bullet points when deciding if cloud is right for you:

  • Have you calculated the money you’ll save? Cloud offers linear growth in infrastructure expense, and can seriously reduce costs for startups and small businesses. However, while cloud resources tend to be available on demand, there may be reduced quality of service for I/O intensive applications like MySQL databases. It may actually be cheaper to stick with traditional bare metal hosting with guaranteed I/O, increased throughput, and co-tenant-free environments, so be sure to research your options.
  • Have you calculated the time you’ll save? Cloud can save engineers and developers a lot of time! However, applications must be built for horizontal scalability and designed for failure, so do not simply cut and paste an existing code-base into the cloud. If you do not have the internal knowledge or the resources on hand to build your application correctly, we do not recommend switching to a public or private cloud solution.
  • Do you know the three different types of Engineers? The first type is laid back, and likely doesn’t care what infrastructure is used on the back-end, provided they can continue to build product and write code. The second type uses a technology simply because it’s up-and-coming and one of the latest bubble buzzwords; in some cases, cloud is no exception! The third type utilizes the cloud correctly, but their experience will be lost should they leave the company, leaving possibly inexperienced engineers in charge of maintaining the cloud infrastructure. It’s important to keep these three engineering personas in mind when making important decisions. Do not, under any circumstances, cut and paste your application to the cloud simply because one or two engineers suggest it is the correct path - it requires a completely different way of thinking and the entire team must be on board!
  • Are you prepared to deal with being in the dark? With the popularity of the public cloud, service outages tend to flood support queues, and finding accurate time estimates to recovery is often difficult. If you’re going to trust your data, infrastructure, and product to a cloud provider, be sure to choose one with excellent support.
  • Are you aware of the security implications? Public Cloud is partially cost-effective because resources are shared with other tenants. It’s very important to make sure proper security precautions are taken before moving to a public cloud provider. Remember that random roommate you moved in with in College to save yourself some cash? Didn’t work out too well, did it?
  • Are you choosing the right cloud? The one thing all “clouds” have in common is that they abstract away a layer of “thinking” from the end user. If your start-up is full of developers with operational skills, consider a provider like Rackspace Cloud or Amazon EC2. Be sure to architect your application properly for the provider you choose. If you’d rather focus more on development and less on operations, trading in some flexibility and control, look into Platform as a Service providers like Bitlancer Strings (Conductor Edition) or Heroku.
  • Are you forgetting the middle ground? It’s possible to use private cloud technology like OpenStack. Also, some advanced providers like Rackspace offer hybrid solutions, combining automated and managed public cloud technology with private, dedicated infrastructure. Some cloud providers even try to emulate traditional infrastructure, offering persistent cloud instances and automated migration in the case of failure.

Bitlancer is a very large proponent of cloud hosting when implemented correctly. Cloud hosting is only a tool, not a magic wand. No matter what infrastructure options you select, it’s important to continuously re- evaluate your choices over time. Is Cloud right for you? Bitlancer can help you decide.