Chapter 5

Choosing the Right Cloud Service Model

It takes less time to do things right than to explain why you did it wrong.

—Henry Wadsworth Longfellow, poet

One misperception about cloud computing is that one cloud service model fits all. That is the equivalent of choosing one tool to build a house. Obviously, it takes many different tools to build a house because there are so many different components that make up the architecture of the house. There is a concrete foundation; infrastructure items like plumbing, electrical, and sewage; interior items like walls, floors, and windows; and external items like roofs, driveways, gutters, and so on. Each component has its own set of requirements and therefore requires a different collection of tools. Obviously, laying and paving the driveway requires much different tools and processes than installing the plumbing or tiling the floors. It is a no-brainer that building a house requires many different skills and many different tools, and each component of the construction of a house has its own characteristics within the architecture of the entire house.

Building enterprise-grade software in the cloud is no different. Just as a builder uses many different tools and skills to build a house, an enterprise should use different cloud services models within the enterprise. Some companies pick a single cloud provider like Amazon Web Services (AWS), which provides Infrastructure as a Service (IaaS) solutions, or Azure, a provider of Platform as a Service (PaaS) solutions, and force-fit all solutions into that cloud service model whether it makes sense to do so or not. This chapter focuses on explaining what use cases make sense for each cloud service model. Companies that understand the pros and cons of each cloud service model will likely implement solutions on all three.

Considerations When Choosing a Cloud Service Model

In Chapter 1, we discussed the definitions of each cloud service model. Figure 5.1 summarizes each cloud service model.

Figure 5.1 Cloud Stack

There are many factors that go into choosing the right service model. Decision makers should consider the feasibility of each cloud service model based on the following five categories:

The technical category focuses on areas like performance, scalability, security, regulation, business continuity, disaster recovery, and so on. Performance and scalability requirements are critical for deciding between PaaS and IaaS service models. One of the greatest benefits of PaaS is that platforms abstract the underlying infrastructure from the developer so the developer can focus on business requirements while the platform handles autoscaling. Since PaaS vendors are responsible for scaling all of their tenants, they enforce limitations on the amount of resources that can be requested by a tenant. For most applications, the limitations are set so high they are not a factor, but for applications with an extreme number of transactions, PaaS cannot deliver the performance and scale. Some of the top-visited websites, like Facebook, Twitter, and Pinterest, leverage IaaS cloud service models because they cannot rely on a platform to achieve the scale they must deliver.

Both IaaS and PaaS solutions offer Database as a Service (DBaaS) solutions that automatically manage database management tasks like replication, autoscaling, monitoring, backups, and more. One limitation of DBaaS is the lack of control over the database. My first start-up, M-Dot Network, winner of the 2010 AWS Global Start-Up Challenge, had a unique technical solution for processing digital incentives at point-of-sale (POS) systems. M-Dot partnered with POS vendors to build a message broker that was integrated and shipped with POS software. The message broker sent the shopping orders and items to M-Dot’s cloud-based digital incentive platform on AWS. The digital incentive platform would process the incoming data and determine if shoppers qualified to redeem any digital offers that were in their digital wallets. The redemption message was returned to the POS system in subsecond response time. Anyone familiar with the retail industry knows that POS systems require extremely high service level agreements (SLAs) and the worst thing a third party can do is shut down a retailer’s POS system. M-Dot wanted to leverage Amazon Relational Database Service (Amazon RDS), Amazon’s DBaaS application programming interface (API), to take advantage of the advanced features and automation of database management tasks. However, the consequences of the database going off-line were so great that we chose to manage the database ourselves. This strategy paid off. AWS had a few well-publicized outages, and in several of those outages, RDS was either down or impacted. Because M-Dot chose to manage the database itself, we never missed a POS transaction on any AWS outage even though many popular websites were completely down. It came with a cost, though. We invested a lot of time and money in architecting a fail-over solution that included master–slave and cross-zone redundancy.

The financial aspects should focus on total cost of ownership (TCO), which requires a lot more thought than calculating the price per hour or per month of a cloud service. If the project is focused on building new applications, it is much easier to calculate the TCO, but for projects that are migrating solutions to the cloud or are new but are constrained by existing legacy architectures, the TCO is much more complex to calculate. For the latter, decision makers must estimate the cost to change and/or integrate with the legacy architectures. In many cases, moving to the cloud brings costs of retrofitting existing architectures so that they can be integrated with new cloud services. On top of the costs to build new services in the cloud, other costs may include projects to reengineer legacy architectures, employee training, hiring new employees or consultants, acquiring tools or services to assist in reengineering, and much more.

Strategic requirements may come into play as well. The more important speed-to-market is for an initiative, the more likely the decision makers will look to leverage SaaS or PaaS over IaaS simply because much of the IT work is being performed by the cloud service providers, as opposed to an IaaS solution where IT still does a lot of the heavy lifting. If control is the most important strategy, it is more likely that the decision makers will gravitate toward an IaaS solution where IT has more control over the underlying infrastructure, whereas with SaaS and PaaS the infrastructure is abstracted from the end user. Business strategies such as consolidating data centers, reducing costs, being first to market, handling enormous scale, selling product globally 24/7, integrating with partner supply chains, and others all contribute to deciding which cloud service model to select. Too often companies pick a cloud vendor solely based on technical preferences without putting enough weight on the business strategies that are driving the cloud initiatives.

An assessment of the organization may play a role in what cloud service model to choose. Does the IT organization have the skills to build solutions in the cloud? If the company does not have strong IT skills in the areas of distributed computing, web development, and service-oriented architectures (SOAs), maybe it should lean more toward SaaS and PaaS service models or find a partner that can build cloud services on IaaS. The lower down the cloud stack the company goes, the higher the degree of competence the staff needs.

The final category is risk. How much risk is a company willing to assume? How long can the solution be down? How damaging is a security breach? Can the government seize the data in the cloud with a warrant? There are an endless number of questions to consider when it comes to risk. Risk also is a major determining factor in whether a company chooses to go with a public cloud, a private, or a hybrid of both. Often, areas such as privacy, data ownership, and regulation are very strong factors in the determination of which cloud service model and which deployment model to use.

Every company and even each individual cloud initiative within a company may weight each category differently. For example, a company building a social media site where customers volunteer to post their personal data, like pictures, videos, and so on, will likely put a higher weight on the technical requirements to achieve high scale and uptime and a lower weight on risks, given that nobody dies when your favorite social media site goes down. On the flipside, a medical company responsible for processing medical claims most likely weights the risk category as high as or even higher than most of the others. In the following sections we will discuss use cases for each service model and show some examples of how AEA addresses its key decision points.

When to Use SaaS

Software as a Service is the most mature of the three cloud service models. Early pioneers like Salesforce.com have perfected the execution of delivering complete applications in the cloud that cloud service consumers can access over the Internet with a browser. The SaaS providers have total control over the infrastructure, performance, security, scalability, privacy, and much more. SaaS vendors typically offer two ways for their customers to use their applications. The most common method is a web-based user interface that usually is accessible on any device that can connect to the Internet. The other way is to provide APIs to their customers so service consumers can integrate features into their existing applications or with other SaaS solutions.

A company should use SaaS to outsource all applications, features, and services that are not a core competency, assuming it meets its needs and is affordable. For example, if a company is not in the business of writing HR, payroll, customer relationship management (CRM), and accounting software, it should not build these applications. Buying these applications and running them on-premises is not cost effective with the emergence of SaaS alternatives. Why buy the software and servers, manage the servers, and pay people to manage, patch, secure, and provide other non-value-add tasks to keep these services running?

SaaS solutions fall into many different categories. The most popular are enterprise business applications like CRM, enterprise resource planning (ERP), accounting, human resources, and payroll. There are a number of IT infrastructure SaaS solutions that deal with security, monitoring, logging, testing, and so on. The data category includes business intelligence, database as a service, data visualization, dashboards, data mining, and more. The productivity category includes collaboration tools, development tools, surveys, e-mail campaign tools, and much more.

Because SaaS providers cater to many customers they often do not provide the same level of flexibility that a company would have if it built its own application. Sometimes companies choose to build their own applications because there is a feature or a configuration that they want but can’t find from the SaaS vendors. Before a company decides to build it itself, it should consider all of the tasks that SaaS vendors perform on their customers’ behalf and factor them into the total cost of ownership:

• Vendor is responsible for security updates and patches.
• Vendor manages all infrastructure and data center.
• Vendor usually provides mobile compatibility for majority of phones and tablets.
• Vendor provides compatibility across all major browsers and versions.
• Vendor frequently updates features and updates are seamless to end user.
• Vendor manages databases, including capacity planning, backup recovery, and so on.

Before a company decides to write the application itself, it should compare the value of the feature(s) that the SaaS tools cannot provide against the TCO of building it itself. Another part of the equation is to consider the opportunity cost for shifting the resources to another project or reducing the number of resources to lower costs. Once a company builds an application it must pay ongoing to keep it current and fix bugs. The speed of change in technology is amazingly fast. Can a company continue to invest precious IT resources upgrading legacy applications to work on the next new phone or tablet? When the next social media darling, like Pinterest, appears out of nowhere, can companies quickly react and integrate with the API? To stay current with technology, companies will have to invest a substantial amount of resources to make these upgrades. Every hour spent keeping up with technology changes is an hour a company is not using to build the next new product or an hour it is not using to reduce costs.

AEA Case Study: Use Case for SaaS

Let’s take another look at the business architecture for Acme eAuction’s future PaaS platform in Figure 5.2.

Figure 5.2 Business Architecture

Here are some of the constraints (organized in the five categories we discussed previously) that Jamie collected in Chapter 4:

1. Technical. Dynamic traffic loads from third parties, increase security.

2. Financial. Reduce infrastructure costs.

3. Strategic. Increase revenue via third-party integration.

4. Organizational. Lack of cloud and SOA skills.

5. Risk. Must get to market quickly (six months).

As Jamie looks at the constraints on his project, it is obvious that speed is important. The ROI of the entire initiative is based on an aggressive time frame. Time is a major constraint on the architecture. There is a risk of opportunity costs if the project is late. The team has been asked to reduce the infrastructure footprint. Another critical constraint is the lack of skills. Here is Jamie’s assessment of the constraints on the architecture:

We have very little time to get this high-priority project to market. We lack the skills at the current time, and we need to find ways to get to market with less hardware than in the past.

Jamie decides that based on these constraints he needs to evaluate where within the business architecture he can leverage SaaS solutions to address the constraints. He knows from his studies that anything that is not a core competency is a good candidate for leveraging SaaS solutions. After reviewing the business architecture, he writes down the following components as SaaS candidates for his team to research and validate:

API layer. His team has limited experience writing Representational State Transfer (RESTful) APIs in the cloud. They have to support multiple third parties, resulting in the need to support multiple stacks, manage API traffic performance, quickly integrate new partners, and so forth. An API management SaaS tool looks like a good solution.

My cart. There are many shopping cart SaaS solutions available.

Payments. If they offload payments to a Payment Card Industry Data Security Standard (PCI DSS)-certified SaaS solution, the entire platform will not be in scope for PCI DSS audits. This will save a lot of time and money.

Utility services. All of the utility services are candidates for SaaS because they are not core competencies. However, they may be provided from a PaaS or IaaS solution, as well.

Enterprise systems. The ERP, financial system, and CRM systems are perfect candidates for SaaS as they are not core competencies and there is no added business value for managing them internally. They are not in the critical path for the first phase (integrate with third parties), but they may have a significant contribution to the goal of reducing infrastructure.

---

When to Use PaaS

PaaS is the least mature of the three cloud service models. The first generation of PaaS solutions, like Google, Force.com, and Microsoft Azure, required that the buyers use a specific programming language and run on the service provider’s infrastructure. For start-ups and small businesses these constraints may have been acceptable, but for enterprises it is quite a different story. Enterprises are complex organizations with many different architectures, technology stacks, and application needs. The lack of flexibility for both the programming language and the infrastructure turned off many enterprises and slowed the adoption of PaaS. Over the past few years a number of second-generation PaaS service providers have emerged. These service providers saw an opportunity to address the enterprise customers’ needs. Many of these new PaaS vendors now support multiple stacks and some allow the PaaS software to be deployed on the infrastructure of the service consumer’s choosing. In addition to the newer PaaS service providers, many of the original PaaS service providers now support multiple languages like Ruby, PHP, Python, and Node.js. Cloud Foundry and OpenShift are two open source projects that are gaining traction and can be deployed on any infrastructure. One of the advantages of open source cloud-based solutions is that with commercial vendors, if they go out of business, the service consumer has no choice but to quickly move to another platform. With open source the service consumers have control over the software and stay on the platform for as long as they wish.

Public PaaS service providers manage the underlying infrastructure, networks, storage devices, and operating systems. Tasks like monthly security patching, logging, monitoring, scaling, fail over, and other system administration-related tasks are provided by the vendor so the developers can focus on building cloud-ready applications.

Private PaaS service providers do not provide the abstraction of the infrastructure services like the public PaaS providers do. Private PaaS offers the capability to deploy the PaaS software on both a private and public cloud (hybrid) but at the sacrifice of requiring the service consumer to manage the application stack and the infrastructure.

PaaS vendors provide a platform that is shared by many customers. In order to manage the performance, reliability, and scalability of each customer and to ensure the heavy loads from one customer do not impact the performance of another customer, the PaaS vendors have various limits that they enforce on developers. These limits, sometimes called throttling, protect the platform from getting overloaded by an individual customer, thus protecting all customers in the process. Most PaaS vendors throttle an individual user’s bandwidth to protect against network collisions and congestion. Some PaaS vendors throttle CPU utilization to reduce the amount of heat generation in the data center and to conserve power. Other PaaS vendors that price based on fixed amounts of consumption such as blocks of storage will throttle the customer when the customer has consumed all of the resources that they have paid for. Developers must understand the limitations of their selected platform and design accordingly.

Many PaaS service providers protect their platform and its customers by throttling the database activity of customers. Developers must account for this in their designs. One way is to trap for these types of errors and retry until successful. Another method is to break units of work into smaller chunks before calling the database. This trick can be used to design around bandwidth limitations, as well. For some applications, designing around throttles creates unacceptable delays in processing time or it may impact the quality and reliability of the application. If this is the case, then PaaS may not be the right service model and IaaS should be used instead. Websites with extremely high volumes or highly distributed applications that crunch through enormous amounts of data are typically poor candidates for PaaS.

But not every application or service has the extreme processing requirements of a streaming video company like Netflix or a popular social media website like Twitter. Many workflow-driven B2B-type applications are prime candidates for PaaS. In a typical workflow, a product starts with an order and flows through a repeatable process flow until the product is built, sold, shipped, and invoiced. Dell uses Salesforce.com’s platform called Force.com to deliver $1 billion in deal registrations with over 100,000 channel partners, so it is safe to say that PaaS solutions can scale admirably.

When to Use IaaS

If an application or service has performance or scalability requirements that require the developers to manage memory, configure database servers and application servers to maximize throughput, specify how data is distributed across disk spindles, manipulate the operating system, and so on, then you should leverage IaaS. If you don’t need to worry about those things, then you should consider PaaS.

At M-Dot Network we had a requirement to deliver 1 million transactions per minute from retailer POS systems to the cloud and back in subsecond response time. In order to accomplish that feat we could not be throttled by our cloud vendor, and we had to make tweaks to the operating system, the application server, and the database to achieve the desired throughput.

Another factor is cost. PaaS can reduce costs substantially by reducing the amount of work and the number of resources required to build and deploy applications. However, the PaaS pay-as-you-go model can get extremely expensive when data gets into the tens of terabytes or when the bandwidth or CPU demands exceed normal levels. As of March 5, 2013, Amazon has reduced the costs of its EC2 (Elastic Compute Cloud) 26 times, and other IaaS vendors have been following its lead. As time progresses the cost of IaaS may become so low that PaaS providers might have to follow suit in order to compete.

Another reason for leveraging IaaS over PaaS is related to mitigating risks of downtime. When a PaaS provider has an outage, the customer can only wait for the provider to fix the issue and get the services back online. The same is true for SaaS solutions. With IaaS, the customer can architect for failure and build redundant services across multiple physical or virtual data centers. AWS has had some highly publicized outages in recent years and major websites like Reddit, Foursquare, and others were down. But many other sites survived the outage due to cross-zone redundancy. Most times when AWS has an outage, PaaS provider Heroku, which runs its services on top of AWS, is impacted. Heroku customers are out of luck until both AWS and Heroku recover. Many AWS customers can and have survived an AWS outage.

As we move up the stack toward SaaS we increase speed to market, reduce the number of human resources required, and reduce operational costs. As we move down the stack toward IaaS, we get more control of the infrastructure and have a better chance of avoiding or recovering from a vendor outage.

Common Cloud Use Cases

For start-ups and greenfield applications, it is common that entire applications are built in the cloud. For established enterprises, it is more realistic that only certain components within an architecture are deployed in the cloud. Here are some common use cases where today’s enterprises are leveraging the cloud to supplement their existing architectures.

Cloud Bursting

Many organizations choose to leverage the cloud to handle peaks in traffic. They may have applications running in their data centers and choose to send excess capacity out to a cloud service provider instead of investing in physical infrastructure to accommodate peaks. Retailers that deal with seasonal spikes around the holidays or companies that process tax returns that have low traffic for most of the year but experience huge peaks during the tax season are examples of companies that might take advantage of cloud bursting.

Archiving/Storage

Some organizations are finding innovative ways to reduce archiving and storage costs by leveraging storage in the cloud. Traditional archiving strategies involve several pieces of infrastructure and software such as backup tape and disk devices, various types of storage media, transportation services, and much more. Now companies can eliminate all of those physical components and leverage cloud storage services that can be totally automated through scripts. The cost of storage in the cloud is drastically cheaper than storage on physical storage media and the processes for data retrieval can be much less complex.

Data Mining and Analytics

The cloud is a great place for processing large amounts of data on-demand. As disks gets cheaper, organizations are storing more data now than ever before. It is not uncommon for companies to be storing many terabytes or even petabytes of information. Analyzing large amounts of data like this can become very challenging on-premises because an extraordinary amount of infrastructure is required to process all of that data. To make matters worse, the analytics of these large data sets are usually ad hoc in nature, which means often the infrastructure is sitting idle until someone initiates a request.

Moving these types of big data workloads to a public cloud is much more economical. In the public cloud, resources can be provisioned only when a request is initiated. There is a huge cost savings both in physical infrastructure and in the management of the systems by deploying an on-demand cloud model.

Test Environments

Many companies are looking to the cloud for provisioning test and development environments and other nonproduction environments. In the past, IT has had to maintain numerous test and development environments on-premises, which required constant patching and maintenance. In many cases, those environments sit idle outside of normal working hours when workers are not working. Another issue is that a limited number of environments are usually available to testers and developers, and they often have to share environments with other teams and environments, which can make testing and development a challenge.

To solve that problem, many companies are creating processes for testers and developers to self-provision testing and development environments on-demand in the cloud. This method requires less work for the administrators, provides speed to market for the testers and developers, and can reduce costs if the environments are shut down when not in use. Better performance testing can be accomplished in the cloud because testers can provision a large amount of resources to simulate large peaks in traffic, where in the on-premises model they were restricted to the amount of physical hardware that was in the data center.

There are many more use cases for cloud computing. The point here is that building services in the cloud is not an all-or-nothing proposition. It is perfectly acceptable and very common for enterprises to have a mixture of solutions within their architectures deployed within their data centers and in one-to-many clouds.

Summary

Choosing cloud service models and deployment models are critical tasks in any cloud computing initiative. The decisions should be based on business drivers, constraints, and customer impacts. Before making these decisions it is highly recommended that the six architecture questions discussed in Chapter 4 are answered. It is also important that all components of the business architecture are considered before making these decisions. An understanding of the future state is also important. As we saw from Jamie’s decision, he built a roadmap that arrives at a long-term future state of a hybrid cloud, which is much different from the initial deliverable, which is a public cloud option. Since he knows that his future state is a hybrid cloud solution, he knows that a hybrid PaaS makes sense in his first deliverable. If he did not look out to the future, he likely would have chosen a public PaaS. When the time came to move to a hybrid solution he would have been constrained by the public PaaS decision. The moral of this story is to take time up front to understand the context of the entire business problem over time, not just the immediate need.

References

Kaplan, J. (2005). Strategic IT Portfolio Management: Governing Enterprise Transformation. PRTM, Inc.

Handler, R., and B. Maizlish (2005). IT Portfolio Management: Unlocking the Business Value of Technology. Hoboken, NJ: John Wiley & Sons.

Hurwitz, J., M. Kaufman, F. Halper, and D. Kirsch (2012). Hybrid Cloud for Dummies. Hoboken, NJ: John Wiley & Sons.

Lee, J. (2013, March 5). “Amazon Web Services Drops Prices Again to Compete with Microsoft, Google.” Retrieved from http://www.thewhir.com/web-hosting-news/amazon-web-services-drops-price-of-ec2-again-to-compete-with-microsoft-google.