Archive for the ‘ Innovation ’ 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 2: Platform As A Service – When You Need to Build Your Own Application

The goal of any information technology department in an organization is to provide services to the personnel of the organization to make them more productive and profitable. Cloud technologies have emerged as a way to provide a wide variety of very capable services at a reasonable, granular cost. These services are delivered in the form of software, and Software As a Service (SaaS) is the way to deliver it.

So why bother with Platform As a Service (PaaS) or Infrastructure As a Service (IaaS)?

The main reason is that the software your users need isn’t available in the Cloud, so you’re going to build it yourself.

PaaS is the next Cloud product down the stack from SaaS, but is arguably the most difficult to implement. Where a SaaS offering is aimed at end users, a PaaS offering is meant for developers. These developers build software on top of PaaS to provide services to the users.

One of the first products in the PaaS space came from Salesforce.com, called Force.com. It’s a set of tools to allow developers to build applications running on the same platform that Salesforce.com runs on. Salesforce.com is the SaaS offering, and Force.com is the PaaS offering.

Amazon’s product in this space is Amazon Web Services. Google has a product called App Engine that serves a similar role to Force.com. Microsoft Azure is a product with huge potential in this space because it takes the massive group of existing developers and cloud-enables them – if you know how to build ASP.NET applications, you’re most of the way to building applications on Microsoft Azure. And making developers productive is the key challenge to any PaaS offering.

What makes PaaS so challenging is the fact that it is a platform – a platform that developers have to learn to use. Developers skilled in one platform, for example, Microsoft’s .NET Framework, are not going to be as skilled in another platform like Force.com. Often organizations are surprised at the impact changing platforms has on developers – it takes longer to build software and often that software has more bugs until the developers get more experienced with the platform.

As with any other new development platform, organizations need to plan in training time, consulting and mentoring to increase the rate at which their developers get proficient in the PaaS product. Picking minor projects to start with is also wise.

PaaS offerings, like SaaS offerings, are built to be highly scalable – which requires particular programming styles. Scalable architectures set very specific limits on certain things that developers can do, for example, limiting the ability of the developer to store data about a user in the computational part of the application, rather than in a database. Developers want to do this because it’s fast and efficient – but at the expense of scalability. Because PaaS is built to scale, the platform will not offer those sorts of storage options and can frustrate developers used to having those services available.

Ultimately these limitations are beneficial – you want the software your developers build on PaaS to be able to scale to whatever the users require. It takes time to get used to these constraints, as it does with any other specific requirements of a new platform.

For better or worse, migrating an existing application to a PaaS environment has proven very difficult. Most successful PaaS products are “greenfield” implementations – built from day one to run on a given PaaS offering. Even if the programming language is the same between the old platform the application was originally built on and the new platform of the PaaS offering, because the platform is different, the services are different which ultimately means the architecture is different. And rearchitecting an existing application is like trying to change the foundation on an existing building – dangerous, difficult, and in many cases, doomed.

PaaS still provides most of the benefits of SaaS: You don’t own the hardware, the operating system or the platform software that your application runs on. All of that is maintained by the cloud provider. But your developers do have to learn how to work with the platform the Cloud provider offers, and to operate in the constraints. In the end the goal is to deliver software that benefits the users.

However, not every set of application requirements fit into a PaaS offering and you need to go even further down the stack to Infrastructure As a Service, the subject of the next blog post.