« November 2012 | Main | February 2013 »

January 2013

January 30, 2013

Cloud Computing Service Models

In this post I will look at the three different service models for cloud computing as defined by NIST. More specifically I will look at the management and operations overhead for each one of the models and compare it to the traditional on-premise model.

Cloud Service Models

Traditional Model

Let's look at how things have been done in the past. Traditionally enterprises have been responsible for managing their own IT infrastructure as well as the software stack that runs their applications. For small companies that meant hiring polyglot employees with wide range of skills varying from low level networking to high level application support. For larger ones, that can afford more staff, it meant creating specialized teams responsible for only networking infrastructure, or only storage or servers and virtualization. However for lot of those enterprises the core business has never been managing IT infrastructure - the only thing they are interested in is to manage their line-of-business (LOB) apps.

Here are just some of the tasks IT teams enterprises have been required to do in the past:

  • Build racks with servers and wire them into the network
  • Build storage arrays and wire them into the network
  • Configure routers
  • Configure firewalls and DMZ zones
  • Install operating system software on the servers
  • Create virtual machines (if virtualization is utilized)
  • Install operating system software on the virtual machines
  • Install databases, set up replication and backups
  • Install middleware used for hosting the application code
  • Patch and update operating system software
  • Patch and update databases
  • Patch and update middleware
  • Patch and update runtime
  • Install application software
  • Patch and update application software

Although long this is by no mean the complete list of tasks that IT personnel has been responsible for. From the list above only the last two (install application software and update application software) have been essential to the core business of the enterprise. In addition to the IT operational costs (OpEx) enterprises also incurred significant capital expenditures (CapEx) used to procure the necessary hardware.

More than a decade ago hosting providers recognized the need to help businesses with those tasks and allowed them to outsource the build-up of infrastructure, and concentrate on just managing their applications. Although hosting providers helped enterprises with OpEx and CapEx they still lacked some of the essential cloud characteristics like on-demand self-service, rapid elasticity and measured service as outlined in Essential Cloud Computing Characteristics.


Infrastructure-as-a-Service (IaaS) Model

IaaS model was the first model that complies with NIST cloud computing characteristics. In essence it offers cloud computing environment consisting of virtual machines. It offers self-service portal where you can on-demand start a virtual machine with preferred operating system, it is broadly accessible, elastic (you can easily start identical virtual machine or shut down exiting one), it uses pool of virtual machines that are collocated on common hardware, and at the end it measures your usage of those virtual machines.

If you look at the picture above you will see that the IaaS model provides automation in the lower layers (up to the virtualization layer) of the application stack. What that means is that tasks like starting the virtual machine, adding it to the network, configuring the routing and the firewalls and attaching storage to it is automatically done by the automation software. The vendor that provides the service is also responsible for managing any hardware failures and service the underlying hardware.

As you have already noticed the IaaS model provides cloud services up to the virtualization layer of the application stack. However as a consumer of the IaaS service you are still responsible for managing the virtual machine. Hence you are still responsible for patching and updating the operating system on the VM, installing and maintaining any databases or middleware that your application uses in addition to maintaining your actual application.

IaaS is very similar to the traditional hosting model with the added benefits of self-service, elasticity and metering.


Platform-as-a-Service (PaaS) Model

With PaaS you have much less things to worry about. As you can see from the picture the whole stack needed for your application is managed by the vendor. Your only responsibilities are your application and the data your application uses. In addition to the tasks managed in IaaS case the vendor (or in the case of private PaaS the platform owner) is also responsible for patching and updating the operating system, installing and maintaining the middleware as well as the runtime your application uses.

One important thing that you need to be aware of when using PaaS is that the automatic updates the vendor does may sometimes have negative impact on your application. Why is that? Very often OS and middleware vendors do incompatible changes between versions of their software. If your application depends on any underlying OS and middleware functionality it may break between platform updates. And because you are not in control of those updates you may end up with your application being down.

The premise of PaaS though is not only to offer maintenance free application stack but also additional services that you can utilize in your application. Very often PaaS providers are exposing middleware and databases as services and abstract the connectivity to those through APIs in order to free up developers from the need to locate the actual systems. Additional services can be authentication and authorization, video encoding, location based services etc. Using the PaaS services will allow you to abstract your applications from the underlying stack and as long as the APIs are kept intact it will be protected from failures between platform updates.


Software-as-a-Service (SaaS) Model

SaaS is the model with the highest abstraction and offers the most maintenance free option. As a SaaS consumer you are just using the software offered by the vendor. As depicted on the picture the whole stack is maintained by the vendor. This includes also updates for the application as well as application data management. SaaS model is very similar to the off-the-shelf software model where you go and buy the CD, install the software and start using it.

Traditionally one of the hardest problems application developers had to deal with was the data migration between different versions. SaaS vendors are also responsible for migrating your data and keeping it consistent. Similar to the off-the-shelf software model you can rely that you can access and read your data once you upgrade to a new version.

The SaaS model is the most resource-efficient model because it utilizes application multi-tenancy. What this means is that the same application instance handles multiple user-organizations. This is good for both the vendor and the customer because better resource utilization brings the maintenance costs down and hence the price for the services down. On the other side though tenant data is comingled and there is the security risk of one tenant accidentally getting access to another tenant's data.

Although not exhaustive the cloud computing service models explanation above should be enough to kick-start your initial discussion about your cloud strategy.

January 21, 2013

Essential Cloud Computing Characteristics

If you ask five different experts you will get maybe five different opinions what cloud computing is. And all five may be correct. The best definition of cloud computing that I have ever found is the National Institute of Standards and Technology Definition of Cloud Computing. According to NIST the cloud model is composed of five essential characteristics, three service models, and four deployment models. In this post I will look at the essential characteristics only, and compare to the traditional computing models; in future posts I will look at the service and deployment models. 

Because computing always implies resources (CPU, memory, storage, networking etc.), the premise of cloud is an improved way to provision, access and manage those resources. Let's look at each essential characteristic of the cloud:

On-Demand Self-Service

Essentially what this means is that you (as a consumer of the resources) can provision the resources at any time you want to, and you can do this without assistance from the resource provider

Here is an example. In the old days if your application needed additional computing power to support growing load, the process you normally used to go through is briefly as follows: call the hardware vendor and order new machines; once the hardware is received you need to install the Operating System, connect the machine to the network, configure  any firewall rules etc.; next, you need to install your application and add the machine to the pool of other machines that already handle the load for your application. This is a very simplistic view of the process but it still requires you to interact with many internal and external teams in order to complete it - those can be but are not limited to hardware vendors, IT administrators, network administrators, database administrators, operations etc. As a result it can take weeks or even months to get the hardware ready to use.

Thanks to the cloud computing though you can reduce this process to minutes. All this lengthy process comes to a click of a button or a call to the provider's API and you can have the additional resources available within minutes without. Why is this important?

Because in the past the process involved many steps and usually took months, application owners often used to over provision the environments that host their application. Of course this results in huge capital expenditures at the beginning of the project, resource underutilization throughout the project, and huge losses if the project doesn't succeed. With cloud computing though you are in control and you can provision only enough resources to support your current load.

Broad Network Access

Well, this is not something new - we've had the Internet for more than 20 years already and the cloud did not invent this. And although NIST talks that the cloud promotes the use of heterogenous clients (like smartphones, tablets etc.) I do think this would be possible even without the cloud. However there is one important thing that in my opinion  the cloud enabled that would be very hard to do with the traditional model. The cloud made it easier to bring your application closer to your users around the world. "What is the difference?", you will ask. "Isn't it that the same as Internet or the Web?" Yes and no. Thanks to the Internet you were able to make your application available to users around the world but there were significant differences in the user experience in different parts of the world. Let's say that your company is based on California and you had a very popular application with millions of users in US. Because you are based in California all servers that host your application are either in your basement or in a datacenter that is nearby so that you can easily go and fix any hardware issues that may occur. Now, think about the experience that your users will get across the country! People from East Coast will see slower response times and possibly more errors than people from the West. If you wanted to expand globally then this problems will be amplified. The way to solve this issue was to deploy servers on the East Cost and in any other part of the world that you want to expand to.

With cloud computing though you can just provision new resources in the region you want to expand to, deploy your application and start serving your users.

It again comes to the cost that you incur by deploying new data centers around the world versus just using resources on demand and releasing them if you are not successful. Because the cloud is broadly accessible you can rely on having the ability to provision resources in different parts of the world.

Resource Pooling

One can argue whether resource pooling is good or bad. The part that brings most concerns among users is the colocation of application on the same hardware or on the same virtual machine. Very often you can hear that this compromises security, can impact your application's performance and even bring it down. Those have been real concerns in the past but with the advancement in virtualization technology and the latest application runtimes you can consider them outdated. That doesn't mean that you should not think about security and performance when you design your application.

The good side of the resource pooling is that it enabled cloud providers to achieve higher application density on single hardware and much higher resource utilization (sometimes going up to 75% to 80% compared to the 10%-12% in the traditional approach). As a result of that the price for resource usage continues to fall. Another benefit of the resource pooling is that resources can easily be shifted where the demand is without the need for the customer to know where those resources come from and where are they located. Once again, as a customer you can request from the pool as many resources as you need at certain time; once you are done utilizing those you can return them to the pool so that somebody else can use them. Because you as a customer are not aware what the size of the resource pool is, your perception is that the resources are unlimited. In contrast in the traditional approach the application owners have always been constrained by the resources available on limited number of machines (i.e. the ones that they have ordered and installed in their own datacenter).

Rapid Elasticity

Elasticity is tightly related to the pooling of resources and allows you to easily expand and contract the amount of resources your application is using. The best part here is that this expansion and contraction can be automated and thus save you money when your application is under light load and doesn't need many resources.

In order to achieve this elasticity in the traditional case the process would look something like this: when the load on your application increases you need to power up more machines and add them to the pool of servers that run your application; when the load on your application decreases you start removing servers from the pool and then powering them off. Of course we all know that nobody is doing this because it is much more expensive to constantly add and remove machines from the pool and thus everybody runs the maximum number of machines all the time with very low utilization. And we all know that if the resource planning is not done right and the load on the application is so heavy that the maximum number of machines cannot handle it, the result is increase of errors, dropped request and unhappy customers.

In the cloud scenario where you can add and remove resource within minutes you don't need to spend a great deal of time doing capacity planning. You can start very small, monitor the usage of your application and add more and more resources as you grow. 

Measured Service

In order to make money the cloud providers need the ability to measure the resource usage. Because in most cases the cloud monetization is based on the pay-per-use model they need to be able to give the customers break down of how much and what resources they have used. As mentioned in the NIST definition this allows transparency for both the provider and the consumer of the service. 

The ability to measure the resource usage is important in to you, the consumer of the service, in several different ways. First, based on historical data you can budget for future growth of your application. It also allows you to better budget new projects that deliver similar applications. It is also important for application architects and developers to optimize their applications for lower resource utilization (at the end everything comes to dollars on the monthly bill).

On the other side it helps the cloud providers to better optimize their datacenter resources and provide higher density per hardware. It also helps them with the capacity planning so that they don't end up with 100% utilization and no excess capacity to cover unexpected consumer growth.

Compare this to the traditional approach where you never knew how much of your compute capacity is utilized, or how much of your network capacity is used, or how much of your storage is occupied. In rare cases companies were able to collect such statistics but almost never those have been used to provide financial benefit for the enterprise.

Having those five essential characteristics you should be able to recognize the "true" cloud offerings available on the market. In the next posts I will go over the service and deployment models for cloud computing.

January 10, 2013

Why is the cloud so confusing?

Last week I wrote a guest blog post for Washington Technology Industry Association explaining What Applications Benefit the Most from the Cloud. While working on the post I looked around the Web and once again was reminded that, like with other technology the cloud is becoming more and more confusing. Don't understand me wrong! I do love the technology but there is always one thing that always baffles me - we (the techies) always invent new fancy terms and try to use those to sell the technology (it even happens quite often that we just call an old technology with new name and sell it again). Well, we are pretty good at confusing our customers with our fancy TLAs (TLA stands for three-letter-acronyms if you are wondering :)) hence I decided to start a series of posts explaining the cloud with much simpler terms. 

One of my favorite questions when I interview people is: "Can you explain this to my grandma?" In the "Cloud Computing Explained" series I will try to give practical definitions and examples of every area in the cloud I can think of. It is well know that the best way for people to learn is to relate the new discoveries to something that they already know, hence I will try to explain the cloud with practical examples that you have already seen in the past (going so far back that you grandma may be able to relate:)).

Here is my initial list of things I would like to cover:

  • What is the cloud? Well, lot of people have different understanding about what cloud is - is it Google Docs, or is it AWS, and what part of AWS exactly?
  • Different clouds - IaaS, PaaS, SaaS, public, private and so on.
  • Why would someone want to use the cloud? Because it is cool and new? Well, maybe… :)
  • How much will you pay for the cloud? I hear it is cheaper than to buy but… Don't be surprised by the bill! 
  • Should I throw all my applications in the cloud? Let's try with one first
  • Will the cloud vendors steal my IP? Am I locked with them forever? Well, depends…
  • And the nitty-gritty's of the cloud? I mean things like APIs, Services, SDKs and all the TLAs.

Of course this is a very high level list and I will be happy to hear feedback on the posts as well as what other topics you will find interesting to cover.