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. AEA Case Study: Use Case for IaaS
All remaining components are candidates for IaaS. Jamie has determined that the future transaction count is too high for PaaS, and he believes he can still meet the date even though it will take more work leveraging IaaS. Here is his list of components that will run on IaaS.
Buyer services. High volume, millions of customers.
Business process. The workflow will be built on IaaS but will call out to services that handle the payments (SaaS) and pay sellers (integration with bank).
Utility services. Leverage the IaaS utility services.
Common business services. These are high-volume services shared by both the buyers and sellers.
AEA Case Study: Cloud Deployment Models
The next thing for Jamie to research is what cloud deployment model makes sense for AEA. After meeting with the product manager and other business and IT stakeholders, Jamie wrote down the following notes about deployment models:
• PCI DSS is out of scope due to selecting SaaS vendor for payments and leveraging a bank for transferring funds to sellers.
• Limited amount of PII (personal identifiable information) data, and users accept terms and conditions when they register.
• Sellers may be located outside of the United States and have concerns with data in the public cloud. • Risk of public PaaS and IaaS outages.
• Need to reduce infrastructure footprint. • Need to get to market fast.
Most of these constraints point to using a public cloud. Since this platform does not require heavy regulation and speed to market is urgent, the public cloud option is very attractive. One concern that Jamie has is the public cloud might scare away international third parties. Another concern Jamie has is how to deal with cloud service provider outages. He knows from his research that if he leverages a public IaaS provider like AWS, he can maintain uptime when AWS has outages, but it requires significant investments in redundancy and fail over. He also knows that if the public PaaS has an outage, he is at the mercy of the provider until it recovers. However, if the PaaS goes down, only the seller services are impacted, not the auctions. The only impact is that new products can’t be listed, but sales will be able to continue. Jamie accepts that risk for the time being.
Long term, Jamie decides that a hybrid cloud solution makes the best sense. With a hybrid solution, Jamie can keep all critical data on-premises and attract more international partners. He can have the baseline workloads running on-premises and leverage the public cloud for spikes in traffic. In addition, the public and private cloud can provide fail over for each other. He can leverage a hybrid PaaS that can run on both the private and public cloud.
However, Jamie has a short-term fixed date that is very aggressive. Building private cloud solutions is much more involved than public cloud solutions. It also does not help meet the goal of reducing the infrastructure footprint. Jamie builds a roadmap that shows a public-cloud-only option in the first six months. The public cloud solution will have to include redundancy across virtual data centers. In order to justify adding servers for the private cloud that he targets year two to deliver, he also recommends moving the CRM and ERP systems to SaaS solutions, which will reduce a large amount of infrastructure costs in both hardware and licensing. Jamie’s decisions are unique to his company. His decisions were impacted by the business case, the time constraints, his organization’s readiness, and his personal knowledge and experience of his industry and his customers. There are no right or wrong choices here. Jamie could have chosen to do the entire solution in a private cloud or entirely on public PaaS and would likely be successful. But he weighed in on the constraints and made the best decisions he could based on the information he had.