As we work with cloud-based vendors and enterprises in healthcare, we’re constantly fielding questions related to cloud deployments and models. This is our attempt to summarize what we’ve learned.
I think we all know what cloud computing is, or at least we have certain associations and benefits that come to mind for the term “cloud computing”. NIST has a formal definition of cloud computing. NIST breaks down cloud computing into 5 essential characteristics, 3 service models, and 4 deployment models.
The Essential Characteristics of cloud computing include:
- On-demand self-service. Pretty straightforward. Users of cloud computing are able to provision computing resources (CPU cycles, storage, bandwidth etc) themselves. You can think of the AWS dashboard as the perfect example of this; if you’ve used AWS, you know exactly what I mean.
- Broad network access. Cloud computing resources can be utilized by remote clients using standard mechanisms. I think most modern developers think of web apps and APIs for this.
- Resource pooling. Computer resources are shared. Models like multi-tenancy and virtual machines are used to achieve this. The idea is that resources are dynamically shared, both up and down, between cloud deployed apps. This can present problems in the case of “noisy neighbor”, where your virtual neighbors are consuming and restricting access to resources. Hosting companies are pretty good at identifying and resolving these issues. But often not, which is why once companies begin to scale to larger volumes, dedicated instances become more interesting.
- Rapid elasticity. This is extremely powerful as it enables apps to scale up cloud computing resources as needed, on demand, to support peaks and troughs of usage. Instead of having to build and support high powered services 24/7, those services and resources will scale as needed.
- Measured service. Usage is metered, and cloud computing is typically billed on a per use basis. In the case of pure infrastructure, like AWS, you have little to no wasted money because you are only paying for what you consume. Consumption can include bandwidth, CPU cycles, storage, user accounts, API calls, etc.
Most of these you probably knew of intuitively but, for us, it’s helpful to lay them out. We find there is a lot of confusion, especially in healthcare, about what cloud computing is, who’s using it, and why it is appealing relative to other models of computing. Much of the confusion comes into play when people interchange the terms virtualized computing and cloud computing; virtualized computing is often used synonymously with private cloud. Virtualized hosted environments do not typically allow for self service or automated resource pooling, two of the essential characteristics form above.
The next categorization for cloud computing relates to the amount of control of the underlying resources. Which leads us to back to the NIST defined Service Models, which are laid out below:
- Software-as-a-Service (SaaS. SaaS is a model for accessing an hosted application developed by a vendor. Typically access is through a web app, mobile app, or an API. And it is is usually billed by user, API calls, or seats and billing is subscription-based. Subscription-based models have implications for customers because of the low capital expense to get started and implications for SaaS vendors because of the high negative upfront cash flow outlay to grow (more on this in a later post). The classic example of SaaS is Salesforce CRM; Salesforce has moved into PaaS (Force.com) but it started as SaaS and still generates the bulk of its revenue from SaaS. If you’re a mobile developer you likely know Parse, Urban Airship, and Twilio. There are literally tons of other SaaS vendors, several of which we use at Datica - Box (just made the move from another SaaS - Dropbox), Zendesk, MailChimp, Intercom, Mailgun, Moz, and Close.io. This is the most limited, at least in terms of customer control, model of cloud computing.
- Platform-as-a-Service (PaaS). PaaS models allow you to deploy and scale your own application to cloud infrastructure without managing servers and/or databases. You may have some control over the infrastructure but it is limited. Users of PaaS typically do not have access to the underlying operating system or network devices. Developers can focus on the application, written in a language of their choice, without worrying about building and maintainer the server to run it. The example most developers would think of is Heroku, which is part of Salesforce. There are others, like CloudFoundry and newer offerings like dotCloud. There is also a super cool compliant PaaS that recently launched that’s called…yes, Datica!
- Infrastructure-as-a-Service (IaaS). I think of this as the blank slate of cloud computing that has been the driving disruptive force in computing over the last 15 years. As opposed to SaaS and PaaS, which build layers of abstraction to interact with customers and keep them away from the OS, IaaS vendors provide customers with access to operating system and sometimes network components. You can think of it as a hosted linux prompt. AWS and Rackspace are the prototypes for this. This is usually the cheapest option. It’s a blank slate, and developers can customize down to the OS level. With that control comes more responsibility and ultimately more time spent on infrastructure. The decision that needs to be made in assessing IaaS is whether time and resources should be spent configuring servers and databases, or does it make more sense to spend a little more money on infrastructure but have more resources for your core product and differentiation. Or in other words, should you choose a PaaS offering or stay with IaaS.
In addition to service models, which basically define the level of control customers have over infrastructure, there are also Deployment Models, listed below, which define the group to which cloud computing resources are shared.
- Private cloud. Most often confused with virtualization, private cloud infrastructure is used exclusively by one entity, and can be on or off premise. This is the direction most larger enterprises will move to, including within healthcare. Datica maintains a compliant private cloud. The challenge with most current private cloud deployments is that they provide none of the capabilities that a public cloud (see below) provides such as auto-scaling, API based access to perform a host of tasks etc.
- Community cloud. In this deployment, infrastructure is shared with a group, or community, of users. We think of this as a shared private cloud, and it’s usually a community that has something in common. With Datica, we have a HIPAA compliant private cloud in which we host our community of customers; the commonality in our community is that our customers are concerned about compliance, so we’ve painstakingly created a compliant environment with multiple private private networks. Customers get their own private networks within the Datica cloud.
- Public cloud. This is the infrastructure that developers know best. In this deployment, the infrastructure is for public use. Pretty simple.
- Hybrid cloud. This is where things get interesting. In this deployment, there is a mix of two different models from above. Hopefully using Datica will provide a good example use case. We have a private cloud - Datica manages and maintains the cloud computing resources and it’s exclusive to us. For our customers, we set up private networks within our private cloud, so our private cloud is actually a community cloud for our customers. Additionally, we’re beginning to explore using public cloud resources for certain, non-compliant things such as code sets. In non-compliant deployments, if more resources are needed, such as the case with spikes in usage and/traffic, private clouds will burst into public clouds to gain access to additional cloud computing resources. Key here is to ensure that “post burst”, the additional capacity that was spun up, needs to be powered down else month end bills could be a bit surprising.
The reason we care about cloud computing, including the definition and characteristics of it, is that we firmly believe the benefits of cloud computing have not been realized in healthcare. And we believe much of that relates to a lack of understanding of what cloud computing is, and how cloud computing can be both compliant and secure. Current compliant offerings in healthcare, especially when you look at compliant cloud computing service models, sorely miss the needs of modern app app developers and the industry as a whole; we make the important distinction between PaaS and IaaS, and believe PaaS is the necessary approach to be compliant because of the myriad of compliance requirements beyond dedicated infrastructure. More to come on service models and compliance in a future post.