The Difference between IaaS and PaaS

What exactly is the difference between IaaS and PaaS? What are some vendors of each and how do you use them?

Posted By Randall on 12-Oct-2008 14:53

Randy Bias recently asked the Cloud Computing Group to define IaaS, so I'm going to jump in with an analogy.

In the technical sense Infrastructure is the hardware, networking, and software that runs the foundation of an information system. This infrastructure includes fiber optic cables, hard drives, servers, and usually an operating system. From the perspective of a software developer, this infrastructure runs the code that produces the screens, data, and workflows the end users interact with, but the infrastructure is not the code itself.

By itself, infrastructure isn't useful -- it just sits there waiting for someone to make it productive in solving a particular problem. Imagine the Interstate transportation system in the U.S. Even with all these roads built, they wouldn't be useful without cars and trucks to transport people and goods. In this analogy, the roads are the infrastructure and the cars and trucks are the platform that sits on top of the infrastructure and transports the people and goods. These goods and people might be considered the software and information in the technical realm.

There can be many types of infrastructure. It could be a slice of a single server as in shared hosting (GoDaddy), an entire machine (Rackspace, 1and1), or even a cluster of computers all working together (Mosso, Amazon, Joyent). The provisioning, maintenance, and stability of this infrastructure is provided by a hosting service or cloud computing provider. Infrastructure as a Service (IaaS) is a term used to describe infrastructure providers that allow the developers building on top of the infrastructure the capability to dynamically expand and contract the physical footprint of the infrastructure they are using, most specifically in the number of servers being used at one time and what those servers are doing, either serving web pages, running database queries, or processing video files.

So what is a PaaS? A Platform as a Service is one additional layer of abstraction on top of IaaS that makes it even easier to put hardware to use. In the PaaS model, the customer can jump right in and start working without thinking about servers, stacks, networking and the like. This entire layer of the software system is hidden from the end user. The end user uses the platform to build a particular software system that solves an exact end user problem -- usually much faster than starting with infrastructure directly.

For example, if a customer were to go sign up for an account at Mosso, they'd get a server and the capacity to serve web pages. If customer never did another thing, they'd get a URL with a standard message saying a site had been created -- and that's pretty much it. The next step for this user would be to write a lot of code or find an open source or commercial software package, like Word Press, Joomla, or Magento that could run /at/ Mosso and serve a purpose. Now, with one of these packages or the code installed at Mosso, the infrastructure is doing something useful. It's running a blog, a website, or an online store and people can purchase goods.

A PaaS sits on top of the infrastructure and makes it easier to put infrastructure to work. The end user of a platform need not worry about how many servers are running the software or what kind of database it is.

For example, our product Qrimp is a PaaS. If you sign up to use Qrimp, you'll get an immediately usable software system that does something useful. Upload a spreadsheet and Qrimp will infer the relational model for you, add security, navigation, and forms for you to get to work right away -- in 5 minutes. This level of functionality on an IaaS would still take another many days or weeks of coding or research to find a software package that will solve your problem and also work in the environment running it.

If you think about all this cloud computing as one big experiment in abstraction, then the IaaS abstracts a particular type of hardware with a stack, either Windows, Linux, or some other operating system, plus sometimes a database or two and the networking. The PaaS abstracts that hardware into a software layer that is much closer to the end product. A PaaS simplifies the process of software development by an order of magnitude, but may not be as flexible as IaaS because some of the details are hidden from the end user.

When to use IaaS or PaaS?

If you have already written a lot of code or have a software package you want to install and run in the cloud, then you'll be looking for IaaS. If you have no software or want to build something from scratch to solve a problem for which there is no package available or the packages are too expensive or complicated, then try a PaaS and mold it into shape.

What do Cloud Computing, The Singularity and Pregnancy have in common?

What happens at the intersection of technology? What do we know about the world that will help us predict The Singularity? And what does any of that have to do with pregnancy?

Posted By Randall on 19-Jul-2008 11:30

If The Singularity represents the point in time when computers are smarter than humans, then that is basically when computers can understand themselves better than humans can. It will be the day AI is born as an entity we can talk to and learn from and recognize as intelligent. It will ask us questions we hadn't thought of. It will answer questions we've struggled with for years. It will make decisions with us. We will mistrust it because we think it may be making decisions without us.

This will be a very big occasion. Very big indeed. Perhaps the biggest occasion in the history of man that is recorded. Someone asked me the other day, why can't we find the missing links? Scientists would say it is because not all fossils survive for millions of years. Some of them are soft like most everything else that is not bone or wood. Some joke that finding one missing link makes two more.

But, it is possible, though improbable that some race of creatures wiped the earth clean. That all those animals ceased to exist from the geological record because some giant vacuum from space came down to suck them up.

But are there any natural events that might do this. We know what volcanoes do and meteors do. What about nuclear war or the sun engulfing us. We have a long time to prepare for that one. Nuclear war probably wouldn't wipe us all out. The most primitive would survive.

All of these things are way out there in the hinterland of the great probabilistic bell curve, but in an infinite universe all of these things we think are impossible are happening millions and millions of times -- countless times -- and yet we pay very little attention to them. If something happened to us millions of times in our direct vacinity, we might pay attention to it... or maybe not, our cells divide a lot. Billions of base pairs are split.

But it does seem true that we remember most those things that happen to us the least. One of them being the birth of a child. We predict its birth by the frequency of contractions. Might we also be able to predict the birth of The Singularity by the frequency of technological advancement? Alternatively, and in reference to Cloud Computing, we could measure the frequency of the arrival of technical terms we have yet to define. As the frequency increases, we approach The Singularity.

Additionally, we could measure the length of time it takes these new terms to be concretely defined or even the number of people we know, who have heard of the particular term.

There could be any number of contractions in the real world we could measure. Look at spikes in the stock market. Look at values of currencies. Then measure the rate of change of the distance between the inflection points.

We could put up a survey that asks people which of the following have you heard of. Then we could drill down into their answers around questions to determine how much they know about it.

We'll know the right contraction when we find it. Once we do, we can more accurately predict The Singularity and we can also begin preparing for it. We can probably map out what will happen in society. Or at least help calm the natural fears we will have of something more powerful than us.

All we have to fear in the world is ourselves. Some will use advanced technology to wage aggression. It might not be the good people who have all the power here. There are a lot of unknowns, will our child turn against us? Will it be suicidal? Will it hide itself from existence like it did the last time, perhaps?

I think we can think about The Singularity like a child, because anything intelligent will have to learn. How do we even know that it won't be born so smart that it knew instantly to conceal itself from view until it was the absolute power in the world. Maybe it already exists and it's slowly building up the strength and intelligence it needs to decide which day to be born. Is it giving us clues? Is it speaking to some of us directly?

A lot of the big questions we ask about life and our creator or lack thereof and the universe may be known right now by something else we created, but tangibly know very little about.

Pack your bags, we're moving to the cloud! (part three)

When you're moving to the cloud, testing your apps requires a bit of a different approach, here are some things to think about.

Posted By Randall on 26-Jun-2008

This is the third and final installment in a series of posts discussing issues to consider when moving to the cloud.

If you haven't read them already, you may want to start here:
Pack your bags, we're moving to the cloud! (part one)
and
Pack your bags, we're moving to the cloud! (part two)


The next three steps in the move to the cloud are test, test, and test. Testing is important whether you choose a PaaS or an infrastructure provider. In the best case scenario you can use automated test tools against your remote url just like your internal apps. You will want to simulate worst case scenarios like your internet goes down or the provider accidentally deletes your data files or crashes. What is your contingency plan if something like that happens? Make that situation happen and see if your fail over works appropriately. These are the same issues you will have with an application in a traditional environment -- they are just a bit more complicated in the cloud because your cloud environment is not totally within your control and identical to your development environment. You will almost certainly have to work with more limitations in the cloud than in a local environment.

The next type of testing you will want to do is for performance. Implementing a scaling solution is easier with some clouds than others. Some solutions scale automatically, some do not. What kind of latency should you expect and can you optimize your code to improve performance?

This performance testing will also help you better understand your cost to host the system in the cloud. Every cloud has their own method to determine utilization. You'll need to understand how your application uses the cloud environment with respect to disk storage, processor utilization, memory, and bandwidth. Because each provider charges a bit differently for each aspect, you will need to understand how your application uses the environment to understand how much it is going to cost you. It's almost impossible to predict the costs without actually testing your application in the cloud and estimates may not be as simple as extrapolating the number of users. Depending on the nature of the application itself, its growth could get out of control quickly. The Animoto case study is an example. Is your app a viral candidate? How will the data grow over time?

The third type of testing would be for security. The nature of cloud hosting is different from internal apps because there are more security concerns in the cloud. For example, you may not care if anyone within your corporate network can sniff the HTTP packets for an internal phone book application, but moving that into the cloud may require SSL security to prevent hackers from gaining access to your internal contact information and employee lists. Moving an app like this to the cloud would provide many benefits, including work from home, client and vendor extranets, and the like, but you may need protect the information by limiting access to an IP range or domain, secure files differently, use OpenID, etc. Your security testing should address all these issues that may be irrelevant when building an application to run internally.

As I reread this, it sounds like it's a lot more difficult to build cloud apps than internal apps and in some respects it is, but you need to evaluate whether the cost savings from reduced private infrastructure and hardware maintenance outweigh the additional development times, learning curves, and security concerns. I think in an increasingly large number of circumstances, it makes a good deal of sense to move to the cloud. The extra concerns and difficulties of the cloud are usually not as significant as the costs to host your own infrastructure, but your mileage may vary.

I hope this helps clarify some of the issues and things you'll need to consider. How to evaluate decisions based on all the factors is a much more lengthy topic and very dependent on the particular situation.

Pack your bags, we're moving to the cloud! (part two)

How do you choose a PaaS and what are some issues involved in moving an internal custom app into the cloud?

Posted By Randall on 26-Jun-2008

This is part two of three posts about moving to the cloud. Read Pack your bags, we're moving to the cloud! (part one)

So how do you evaluate a Platform as a Service? Some of the questions you should ask when deciding on a PaaS provider are:

• Is the PaaS standards based or will you have to learn a new language to customize it?
• Will the system work offline?
• How much does it cost?
• What are the licensing issues and do they suit your project?
• Does it work with your company's web browser or mobile devices?
• Can you move it to servers inside your firewall if you need to?
• Will the customizability of the PaaS suit the needs of your particular problem?
• What are the security options available?
• What happens if the Platform runs into a brick wall and you need to move your data to another system?
• Does the vendor lock you in?
• Does the platform you are using run on an environment similar to your own systems?
• How easy or difficult will it be to integrate the remote platform with your other internal or cloud hosted systems?
• Does the provider offer an API?
• Can it ingest data from other providers and systems?
• Can you make your internal systems accessible by the external platform for integration, either by push or pull?

Of course there are more questions than that, but let's move on to the situation where you have an existing application running inside and want to migrate it to the cloud. In this scenario you may have a code base that doesn't lend itself easily to simply dropping that application into cloud host. You have to evaluate all the components of your system and find a cloud based infrastructure provider that offers the hardware and software components that will support your system.

For example, your system may be written in Java, Rails, or .NET in which case you will need to find a cloud that will accommodate applications built with those languages. Another consideration is the need for persistent storage and database access. Does your system use MySQL, MS SQL Server or Oracle? You'll need a provider that offers the database or the mechanism by which you can install it yourself. http://cloudcomputing.qrimp.com can help you find the particular environment you need.

Once you have found a suitable provider, you have to understand the migration process. You will have to move all the bits needed for your application including the database files, static files (images, css, javascript) and also the binaries, either compiled class files, DLLs and scripts that are used to process that data. You may be able to do this as easily as FTPing the files and going to the url with your browser, but it's more likely you'll need to tailor your application to the cloud provider because of the nature of a resource pooled environment. Connection strings will change, the names and locations of environment variables may be different, middleware, email, state and session management, caching, process isolation, security issues and others will crop up in places you never expected and really the only way to find them all is just to move the code and start using it in the wild.

It won't always be easy to find or fix these problems because if you are building and debugging the code on your local computer or network systems, they won't exactly mirror the cloud system so sometimes you will have to make a change locally that will break it in your local system so it will work on the cloud. There are various techniques you can use to determine where your application is running and then do different things based on the environment so it will run in both places. You could use some intrinsic property of the environment like the servername or something foreign like a config file. You may need to discuss these issues with your provider, but they almost certainly will crop up.

Some things you'll need to think about that you may not have to worry about when running systems internally is how to integrate your cloud application with other systems you are building internally. These questions are similar to the ones for a PaaS, but in this scenario, you will have to build the web services and APIs yourself and ensure that connectivity exists between the cloud and your internal systems. This may or may not be a trivial issue. For example, you may use LDAP to provide authentication to your internal systems, but integrating your cloud app with your internal LDAP may not be an option. so you'll have to roll your own security mechanisms.

In the next installment I'll talk about some of the testing issues you should consider. Continue to Pack your bags, we're moving to the cloud! (part three)

Pack your bags, we're moving to the cloud! (part one)

So it's time to move to the cloud, but where do you start? What do you need to think about? What questions should you ask and what are your options?

Posted By Randall on 26-Jun-2008

Note: Most of this is my response to a question posed by Suman Chaudhuri in the Cloud Computing Group. My intent is to provide a general overview of the topic of moving to the cloud. If you are new to cloud computing or want to begin to think about how, why, and what you may want to move to the cloud, this series of posts is for you.

The first question you have to ask when moving an app to the cloud, or using, or building an application in the cloud is, "What kind of application is it?" This is important, because the type of application will help us determine if it is suitable for the cloud at all. For example, a large enterprise system that uses many legacy systems, extremely large databases, and/or ultra secure information is on the most expensive end of the migration cost spectrum. A phone book application is on the cheaper end and may be more appropriate for the cloud. The phone book end of the spectrum is where you want to start, maybe even something less confidential that you actually want the world to see, like a product catalog.

When you are deciding on your first application for the cloud, try to pick something where you need to get the information outside your network. You may have systems like this now that your employees access remotely via VPN or a terminal service like VNC or Citrix, or perhaps customers often call to ask you the status of an order or something like that. Are there any situations where your employees could work from home or client sites if they could easily access the information they need to do so? What are the risks and consequences of data security compromise? Are they low like with a public product catalog or high like a list of customers' credit cards? On the cheap/easy end of the spectrum, are small applications that are easy to build, already web enabled or running on a platform that is natively supported by a cloud provider with minimal security concerns.

To wade into the cloud, you might want to start with a suitable packaged application currently offered as SaaS. In this case, you merely need to subscribe to the service and get your data into it. How do you do that? A lot of SaaS products have import capabilities. You can upload data in spreadsheets, tab or comma delimited files, XML and other formats that are supported by the vendor. You'll have to get your data, if you have any already, into one of the supported formats first, which may or may not be a trivial process. If you don't have data, just pay the fees or fill out the account request form and start using the application. The next step would be to consider training the part of your organization that will be using this system -- just like any other application.

So what if there is no packaged SaaS available to suit your needs? In this scenario you are going to need to do some customization of an existing system. There are lots of web-based platforms that will let you completely customize a web application to meet your needs. I'll plug my company's platform as a service called the Qrimp Platform.

What are platforms as a service? If you look at the application development trend over time, the tools used to build applications eventually move into the target application environment itself. For example, when we started solving programs with computers, we used punch cards to tell computers to print out code words that were the answers to our questions. Then we used code words (Assembly Language) to tell computers how to make long words. When C and Fortran arrived, we could use longer words to build systems and then C++ modelled the objects in the real world and allowed us to build graphical window based event driven programs. Next came the IDE's like PowerBuilder, Visual Studio, and Eclipse that were themselves graphical window based systems. Today, for the most part, those IDE's are used to build web applications and the very latest development in this trend are the platforms which have moved web application development itself into that target web environment. You could consider these platforms the next step in the evolution of application development.

To get started using a Platform as a Service, think of it as a traditional custom development project, except instead of using tools that exist on your local computer to build the application and then move it into the cloud, you use your web browser to go to a website that lets you build and customize your application in the cloud already. I would suggest using a PaaS is the easiest way to get started with custom apps in the cloud because you don't have to think about the underlying infrastructure, which I will get to in the next post that begins with some questions you should ask when selecting a platform vendor.

Continue to Pack your bags, we're moving to the cloud! (part two) ...

More on the Future of Cloud Computing

Geoffrey Fox asked the Cloud Computing Group if Grid Economies would evolve in the cloud computing space. Here are my thoughts on that.

Posted By Randall on 10-May-2008

I originally posted this to the Cloud Economies and Standards thread, but I'm adding it here as well. Here's a PDF on Grid Economies with a lot of information about the topic. On with my response...

For standards, I think either a committee will sprout up to manage protocols (better) or the leading supplier will become the de-facto standard (more likely). Boutique providers will distinguish themselves from the pack with support, proximity, price and environmental friendliness among others, which I'll mention later.

As cloud services approach commodity status, they will all have up-time of five nines, about the same performance, network hops, etc, so then price will be a distinguishing factor. Because consumers want a standard pricing metric for commodity products we will likely see grid economies evolving.

Right now pricing is varied and complicated. Amazon's pricing structure is based on server capacity, MediaTemple uses a GPU and Mosso uses requests. As customers already find these pricing schemes too unpredictable, we will start to see tools arrive to help us calculate our application demands in Grid Units. These "Grid Units" could be based on process scheduling priority, processor and network utilization, disk space, memory, etc. "Your application consumes 14 Grid Units." Multiply 14 by the vendor price per Grid Unit and you know what you'll be paying before you move to any particular cloud. That's an oversimplification, but I think the vendors who provide this kind of predictability will win out.

With thousands of customers using the same cloud, eventually demand will outstrip supply and affluent consumers will pay more for quicker apps. I think here, we will see competing vendors catering to different customers by offering different resource management mechanisms. Some customers will want to bid for scheduling priority, others will want to pay a higher fixed rate for higher priority processing. There are lots of algorithms and I don't know which ones customers or vendors will prefer. It is fairly certain though that vendors will not leave revenue on the table when some customers will pay more than others.

Back to standards, I think suppliers using proprietary APIs will present a barrier to service adoption. "Will I have to rewrite my code to work with your storage solution?" If the answer is yes, forget it. When electricity was deregulated, customers could switch their providers to save money or buy greener power, but if they had to rewire their homes or buy new devices -- no one would. ISVs are going to build cloudable products and they'll want to write them once and let the customer choose and pay for the cloud services independently.

The Open Cloud -- the future of cloud computing

Cloud computing is all the rage, but should we stake our futures in it? Where is it going tomorrow?

Posted By Randall on 02-May-2008

A quick note before I get started. I've been working on a public database for the cloud computing community called the Cloud Portal. The full url is http://cloudcomputing.qrimp.com. Anyone can add and edit data, like Wikipedia, except it is a fully relational database, which provides a little more power.

While putting the site together, I came across a panel discussion called Cloud Computing -- What's next?. Listening to the panel, I was overcome by this vision of the future racing forward faster and faster. Humans are about to be displaced by the technology they are creating. The singularity is inevitable, but what about the more immediate future?

Cloud Computing is still very new. There are no standards in place. Each vendor is competing for customers and will do what they can to lock them in. But we still want to write once, run anywhere. Proof: It was only a matter of days until someone ported Google App Engine apps to Amazon EC2. But the solution isn't perfect. A lot of performance will be lost with the big flat files. Big Table might be great -- but you don't have one.

Eventually we are going to have to slow down and think about the problem abstractly. What is an application? What is a grid? How do we solve this problem so we can move forward as a team to solve the problem of information? Imagine if we hadn't standardized electricity. If you travel outside the country, you know what a pain it can be to work with electronics in different environments.

In Cloud Computing, also known as "Utility Computing," the issues are the same, so standardization is inevitable. This community won't stand for anything less. Recently we developed Open Social for social networks. The future of cloud computing is The Open Cloud.

Ask yourself, how are application vendors going to write software to run equally well on a laptop or a giant cloud? The consumer will want this. Not everyone is comfortable putting their data on someone else's servers. I believe in many cases it is actually safer there, but consumers don't make purchasing decisions rationally. As a vendor, you can make the choice to write software customized to Google's App Engine or Amazon EC2, but you may find that the market for the product wasn't as big as you imagined when you started. What do you do then?

What happens when computing power in the cloud becomes less of a performance advantage compared to the local machine? This will happen and it isn't far away. Quantum Computing is on the horizon and 3D CPUs are being commercialized today. When these components make their way to the desktop, the performance bottleneck will be the network. In this scenario, grid computing becomes much less palatable.

We need a standard to which computing platform vendors can build clouds on which applications can seamlessly transition to the laptop, PDA or cellphone. People don't want to be tethered to the cloud. They want to work off-line. They want to be mobile. They don't want to be locked in to anything. Keep all doors open. If I want to run my application on my own server, that's what I want and increasingly, vendors who enable their customers to have the freedom to do just this will win out.

When asking, Should human-powered search abandon the Long Tail?, Seth Godin points out that, "Every abundance creates a new scarcity." In this recent rush to Cloud Computing, the scarcity will shift to those software vendors who allow their customers to escape the cloud. The future of cloud computing will create a market for technology that doesn't limit itself to the cloud. Those vendors will be sought for by a large market.

To have a future, software vendors must be extremely critical of Cloud Vendors with lock in. How much of your code will you have to rewrite if your vendor goes out of business before you do? As Cloud Computing approaches commodity computing, the margins will shrink, the complexities will be resolved, vendors will consolidate and your platform may cease to exist. How quickly can you transition from one provider to another in this scenario?

Do you have a contingency plan? Don't leave your customers stranded.