In Chapter 1, we discussed the defi nitions of each cloud service model. Figure 5.1 summarizes each cloud service model.
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 fi ve categories:
1. Technical 2. Financial 3. Strategic 4. Organization 5. Risk
Cloud Stack
User
Application
Login Registration Administration
Authentication Authorization User Interface Transactions Reports Dashboard
OS Programming
Language App Svr Middleware Database Monitoring
Data Center Disk Storage Servers Firewall Network Load Balancer Application Stack
IaaS VendorCustomer Customer Customer
Vendor Vendor
PaaS
SaaS
Infrastructure
Stack Components
Who Is Responsible Service
Models
Figure 5.1 Cloud Stack
The technical category focuses on areas like performance, scalability, secu-rity, 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 benefi ts 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 limita-tions 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 appli-cations with an extreme number of transactions, PaaS cannot deliver the per-formance 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) solu-tions 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 fi rst 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 part-nered 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 qualifi ed to redeem any digital offers that were in their digital wallets. The redemption message was returned to the POS system in subsec-ond 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 fi nancial 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 applica-tions, it is much easier to calculate the TCO, but for projects that are migrat-ing solutions to the cloud or are new but are constrained by existmigrat-ing 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 ret-rofi tting 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 solu-tion where IT still does a lot of the heavy lifting. If control is the most impor-tant 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 fi rst 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 fi nd 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 fi nal 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 end-less 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 com-pany may weight each category differently. For example, a comcom-pany 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 tech-nical 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 fl ipside, 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.