Archive for the ‘ Infrastructure As A Service ’ Category

The Cloud SPI Model Part 3: Infrastructure as a Service, the Service of Last Resort

Infrastructure-As-A-Service (IaaS) rounds out the SPI Model. For IT professionals, IaaS, especially in the form of virtual machine services, is the most familiar of Cloud offerings, it also puts the most obligation onto the company IT department. We call it the “Service of Last Resort” because while IaaS still has some of the advantages of the Cloud, it has the fewest.

Amazon EC2 is one of the original products in the IaaS space, offering the ability to build a virtual machine that runs on Amazon’s hardware. Microsoft Azure also has a virtual machine offering in this space, and there are many hosting companies like Rackspace that offer hardware transparent virtual machines.

IaaS aims lower down the stack toward the IT professional. They can build VMs for a variety of purposes, including providing infrastructure for developers. And it is far more feasible to migrate existing applications into an IaaS offering. But this flexibility comes at a price.

With IaaS, you don’t own the hardware, but from the operating system onward, you are responsible. Users of IaaS products need to worry about operating system updates, platform patches and the like – the only thing you’re not responsible for is the hardware itself.

For organizations with strong IT personnel, this isn’t that big a deal, but it is a cost and if you don’t have the skilled people available, it can be a serious problem. IaaS should be the cloud offering of last resort – you’d rather have a SaaS or PaaS product, but when that isn’t possible, IaaS is better than not being in the Cloud at all.

Recalling the tenents of OSSM: On-Demand, Self-Service, Scalable and Measured, it is far easier to violate OSSM with IaaS, especially around scalability. When you’re building your own applications on your own platform, it is easy to create non-scalable scenarios where only a single instance of the VM will operate correctly. You can make it a big VM, but you’re still confined to only one. Building applications that scale symmetrically across multiple VM instances is doable, but hard.

Ultimately building scalable applications in the IaaS world requires the same skills it would take to build scalable applications on-premise, only with more constraints – often IaaS products limit what sorts of load balancing you can do, networking and instrumentation options. The key to success with scalable applications in any environment is a close working relationship between the developers building the application and the operations people who need to run it.

Platform-As-A-Service (PaaS) actually simplifies building scalable applications by limiting the feature set available to developers and designing in scalability from the beginning. But those limitations make it very challenging to migrate an application, typically PaaS-based applications end up being greenfield implementations. But at least PaaS helps lead you to the “pit of success” for scalability – you’ll get no help from IaaS.

IaaS is more than just virtual machines – there are other services that exist in the space, especially data storage. IaaS data storage comes in a number of flavors. Amazon S3 is a simple file storage service, nothing more, nothing less. You pay for the space you consume to store your files, and fees for number of bytes uploaded and downloaded. The instrumentation isn’t fancy, but it is there. S3 follows OSSM perfectly and if it fits your requirements, it’s a great IaaS product.

Microsoft’s SQL Azure is a database-in-the-cloud solution. Microsoft considers it a PaaS offering since you don’t own the operating system, but it does blur the line between a development platform and simple infrastructure services. Under the hood SQL Azure is Microsoft SQL Server, but with some specific limitations. Not all existing SQL Server databases can be migrated to SQL Azure, especially big databases – SQL Azure tops out at 50GB.

Between the file storage of S3 and the SQL database of SQL Azure there are a number of interesting products. Amazon SimpleDB slides neatly into this space between the two, storing simple items with attributes. Google has a similar product in the space with Google Storage, and Microsoft’s Azure Table Service is similar also. All the services offer automated redundancy and Content Delivery Network (CDN) like features.

Beyond virtual machines and storage, networking services like load balancing, instrumentation, messaging queuing and the like all end up as part of an IaaS offering. When focused on the goal of delivering ultra-reliable, available-anywhere applications to your users, you’ll end up using combinations of these IaaS products.

In the real world, most organizations will end up with a combination of SaaS, PaaS and IaaS implementations. Understanding the advantages and disadvantages of each of the offerings is vital – in virtually every case you’d rather have SaaS over PaaS over IaaS. With SaaS, you only need to train your users on their new tool. With PaaS, you’re retraining developers as well as users. And with IaaS, you’re taking on new IT infrastructure which requires more training and additional risks.

Ultimately, in most cases the advantages of moving into the Cloud anywhere in the SPI Model are greater than than the risks – but that doesn’t mean the risks can be ignored. They are part of understanding the larger problem space of delivering great productivity tools to users.

Advertisements

The Cloud SPI Model Part 1: Software As A Service, What You Really Want From the Cloud

For the most part cloud products have sorted themselves into three classes: Software-As-A-Service (SaaS), Platform-As-A-Service (PaaS) and Infrastructure-As-A-Service (IaaS). These three offerings are now being referred to as the SPI Model of Cloud services. So what are the differences, what should you get and who offers what?

As we started deliberating the thinking around SPI, it became apparent that this would be a very long post, so it’s broken into three parts, one for each offering.

It’s important to realize that SaaS, PaaS and IaaS are not mutually exclusive – they build on each other. SaaS is only possible because under the hood there is platform and infrastructure that SaaS depends on. The platform and infrastructure may or may not be available for sale as PaaS and IaaS offerings, but they are there.

All Cloud offerings are ultimately SaaS, it’s just a question of how much you build yourself. With SaaS, you’re building nothing – the application is finished, you just configure it the way you want to use it. Some of these applications have been around longer than the term “Cloud”. Products like Salesforce.com have been sold under the Application Service Providers (ASP) moniker for a long time. As the larger concept of the Cloud came to the forefront, they jumped onto the bandwagon, but it didn’t really change the product.

Changing the moniker didn’t change the application, and the users couldn’t care less. Users don’t care about Cloud or any other technology – they care about getting their work done. How you deliver the tools to them that let them get that work done isn’t important to them. If that tool happens to be software, and that software is delivered via Cloud technology, and it is effective for the user, then the user will like Cloud. But that begs the question, what makes a given technology (like software) a Cloud offering?

The best definition we’ve found for determining whether a given technology is “Cloud worthy” comes from Dave Neilsen of Platform D. The acronym is OSSM (“awesome”): On-Demand, Self-Service, Scalable and Measured. On-Demand means the product is available whenever you want in whatever quantities you want. Self-Service means that you can order the product without needing any support from anyone else (especially the vendor selling the service). Scalable means you can order as much or as little as you want, it works the same regardless. And finally, Measured means that the product is measured in reasonable increments so that you know exactly what you’ve bought and how much it cost. You’ll pay only for what you use.

Using the OSSM standard, it’s easy to see that Salesforce.com qualifies as a Cloud SaaS offering – you are able to order it yourself without any assistance and get to work immediately. You can buy as many seats as you want, enter as many leads as you want, run as many reports as you want. And you only pay for what you use.

Other SaaS offerings including Google Docs and Microsoft Office 365. In fact, mail in the Cloud is arguably the definitive SaaS product. Why go to the expense and effort of operating your own mail servers when you get everything you want from a SaaS offering, typically at a fixed rate per mailbox?

There are a couple of challenges with SaaS. The first is security. For the most part, security for SaaS applications is sufficient, even if it’s nothing more than SSL. But if the security features of a SaaS application don’t comply with your organization’s requirements, there’s often no recourse. The security the application has is the security the application has, take it or leave it.

A more complex issue is regulatory compliance. This is a huge subject unto itself, depending on the industry you’re in, the countries you’re working in and the work you are doing. There are whole web sites dedicated to the topic of regulatory compliance like the Compliance Authority that also talk specifically about compliance and Cloud. Smart SaaS vendors are helping their customers get through regulatory compliance concerns with great documentation and even features – for example, Microsoft’s Office 365 allows mailboxes to be stored outside the cloud so that a customer can fulfill compliance requirements for mail from a particular country to be stored in that country. There’s also sophisticated mail retention policies and auditing.

Beyond these issues, there’s almost no downside to SaaS. And there is a huge upside –  all the things you don’t have to do. You don’t own the hardware, the operating system or even the software you’re running. Someone else is responsible for all of that, you just utilize the product as you see fit. From an ROI perspective, SaaS is a no brainer.

Ultimately, SaaS is what we want from Cloud – the maximum potential with the minimum of ownership and responsibility. But what if the application you need doesn’t exist in the Cloud already? That’s where Platform-As-A-Service (PaaS) comes into play. It’s the next layer down the SPI Model stack, and is the subject of the next blog post.