Sergey Nivens - Fotolia


These IaaS examples show data centers can share the load

Not every IT workload belongs directly under your control in the data center. Consider these IaaS pros and cons for example workloads.

You might not be ready to go all in on AWS like GE and Netflix have, but it's feasible and advisable to start moving some applications on to cloud infrastructure.

Infrastructure as a service (IaaS) is a virtual package of servers of various sizes; storage; databases and network services like firewall, load balancing and content caching delivered from shared, multi-tenant data centers. IaaS is typically purchased on a usage-based, metered plan without contracts or term commitments, although reserved resource subscriptions are also available.

The considerations and IaaS examples presented here will help an IT organization determine which parts of its internal data center infrastructure to replace with IaaS.

IaaS requirements

Applications that make good candidates for IaaS must already run virtualized on an enterprise hypervisor system like VMware vSphere or Microsoft Windows Server Hyper-V. Ideally, a good IaaS example has few dependencies on internal data sources, particularly real-time data feeds. If the workload does rely on internal data sources, ensure that these are accessible via representational state transfer application programming interfaces, known as RESTful APIs, or standard database protocols such as ODBC or JDBC.

The best candidates for infrastructure as a service hosting currently run on outdated systems that would require an upgrade if the application remained in the company's data center.

Other strong candidates for IaaS have uneven capacity needs, whether bursty -- e.g., subject to uneven user demand -- or temporal -- e.g., seasonal, monthly, weekly. These applications can be rapidly, or even automatically, scaled on IaaS.

Moving infrastructure and applications to IaaS is a multivariate decision. It's not just a question of cost; in fact, cost is often the least important factor.

IaaS examples exist for legacy applications and newly created, greenfield apps, but generally the latter group finds a more natural fit. Application developers can design greenfield apps from scratch with the cloud in mind, using a distributed, loosely coupled, microservices architecture. Distributed cloud apps exploit basic IaaS compute and storage as well as higher-level services such as load balancing, auto scaling, content caching, Apache Hadoop/MapReduce data processing, Apache Spark or equivalent data analytics and mobile back ends.

Most IT organizations are a mix of traditional IT and emerging digital business applications. System and application characteristics and requirements differ in this bimodal IT state, where some apps need conservative changes and others benefit from agile, fast fail processes. This second group usually includes multidisciplinary teams and is more apt to rely on cloud services such as IaaS than the first group. Whether or not you agree with the concept of bimodal IT, borrow concepts from mobile app startups by using Agile development methodologies, multidisciplinary specialists and rapid release and update cycles for new applications.

Due to the ease and low cost of deployment, along with the ability to rapidly add IaaS capacity and services, new projects should start and likely remain in a public cloud. Should these apps need to be brought in house, whether for cost, regulatory, security or other reasons, the deployment process involves procurement, installation, configuration and testing of servers, storage systems, network switches, virtualization and a cloud stack software such as OpenStack or VMware vCloud -- a process that takes weeks.

Although legacy infrastructure is often best left alone, there are situations where IaaS can add value via increased flexibility, reduced upgrade expenditures, better redundancy and availability or new capabilities previously unavailable on legacy systems. These IaaS examples generally entail hybrid cloud architectures with the data center infrastructure augmented by IaaS. In cases where the application is relatively simple or tightly integrated and with few dependencies on internal data sources, however, a forklift upgrade to IaaS is feasible and perhaps preferable.

Real-world IaaS examples

There's no prescriptive formula for when and where to use infrastructure as a service, but the following scenarios illustrate situations where moving private data center infrastructure to the cloud can pay dividends -- or not.

Scaling an externally facing application of service. Two key benefits of IaaS are easy and rapid scaling and global distribution. Smaller companies without excess IT capacity can enhance and scale an existing customer-facing application delivered out of an internal data center. For example, a regional online travel agent can expand into new markets far from its transaction processing application's primary base. Since the application in this example was built on Microsoft SQL Server, it was relatively easy to lift and shift to Azure, Microsoft's hosted cloud infrastructure. Moving to IaaS and properly scaling infrastructure tripled performance, with an additional 50% gain projected from future upgrades.

Consumer-facing marketing content. For consumer product manufacturers and retailers, the company website is often the most important way to reach customers and influence buying decisions. Websites must be dynamic, engaging and snappy, no matter where the customer is located -- qualities that make them good candidates for IaaS deployment. Many consumer-facing sites use popular content management systems such as Wordpress, Joomla or Drupal along with custom code, all of which work well on cloud infrastructure. These systems are easily deployed using rebuild packages or recipes and scale as needed.

The value of IaaS becomes apparent when running a marketing or sales campaign that is more successful than anticipated. It's next to impossible to scale internal IT infrastructure systems fast enough to meet unexpected demand. Infrastructure as a service can quickly redeploy apps to larger instances and new regions, as well as accelerating the app with services. For example, AWS can improve an app's static content and workload distribution via CloudFront content delivery network, Route 53 domain name system service and S3 object store.

Disaster recovery backup sites. Disaster recovery is one of the classic infrastructure as a service examples. Smaller organizations might not have a secondary location for DR at all, in which case IaaS could save the company in a cataclysmic event. In other situations, the backup site is outfitted with old, surplus equipment that's undersized, seldom tested and at its end of life. IaaS can provide on-demand capacity equivalent to that in the main data center with no capital expenditure (Capex) on equipment. Even large enterprises with multiple regional data centers can exploit IaaS as a secondary location in each region -- preventing costly, performance-sapping failovers to distant facilities.

Test and development infrastructure. The other archetypal example of IaaS is test and development deployments. R&D and IT engineering organizations often make sizable investments in test hardware to accommodate code builds, beta and stress testing and product staging. All of these can be replaced and improved upon by IaaS which grants each developer a private, virtual sandbox of servers, storage and networks without the need for Capex investment or system managers.

Enterprise applications in every organization invariably have a wide variety of characteristics. Some have variable and unpredictable workloads, others are built using a cloud-friendly, scale-out architecture while still others have become a commodity that's widely -- and less expensively -- available as a software as a service product. All three categories are great candidates for the cloud.

When to avoid IaaS

In some cases, such as a cash-starved, tech-savvy startup, IaaS is the only option. Conversely, for legacy financial systems or applications with highly regulated and sensitive data controls, the cons of IaaS outweigh the pros and the workloads are best handled on internal data center infrastructure.

Legacy systems. Applications that are tightly integrated with legacy business systems and processes, where a move to IaaS could prove highly disruptive, should stay in house. Most enterprises rely on a plethora of largely static legacy applications, often in maintenance mode and sometimes highly customized, that run business-critical systems. The risk-reward ratio of changing a stable, working implementation is far too high to consider a cloud deployment.

Some organizations also prefer to keep systems with sensitive data, particularly customer and financial information, in a controlled data center. Extending the appropriate server and network security controls into the cloud, while feasible, can be complicated.

Costly cloud instances. It can also be prudent to pull IaaS-resident applications on to an owned infrastructure should they grow to the point where the monthly costs are well over $10,000. In this example, IaaS operating expenditures are more expensive than the  Capex and Opex involved to build and operate the requisite infrastructure in house. This case is particularly true if the application workload is relatively stable and unlikely to need dynamic capacity.

Recommendations and caveats

Moving infrastructure and applications to IaaS is a multivariate decision. It's not just a question of cost; in fact, cost is often the least important factor.

Organizations must consider the complexity of the move, including disruption to existing operations, the intensity of application modifications required and IT willingness and capacity to learn and incorporate new management portals and processes.

Conversely, don't underestimate the unique benefits of IaaS because working with IT infrastructure in your existing data center setup is easier. IaaS pros include easy, rapid and low-cost scalability, offloading of routine system administration tasks such as updates and patches, avoided  Capex, and more precise spending thanks to usage-based pricing models. It's a nuanced problem; however most organizations will find many IaaS examples where the move makes the application far superior to the status quo.

Next Steps

Ways to tame your AWS budget

Cloud market changes on the horizon

Bridging the cloud and legacy systems

Dig Deeper on Server hardware strategy