The NIST model of cloud computing is composed of five essential characteristics, three service models, and four deployment models. I thought it would be interesting to do a quick write up of how LegalCloud.net fits into the v15 NIST definition of cloud computing. It's a model I certainly support, but do find a bit inaccessible to newcommers to the cloud at times. But, that will change over time. What follows is some information about how LegalCloud.net, a real life cloud computing service, fits into the NIST model.
Service Models:
LegalCloud is an IaaS model cloud. We are specifically delivering data center infrastructure to law firms on a globally.
In the not so distant future there will be PaaS and even possibly SaaS opportunities associated with and deployed by LegalCloud and it's partners. There are many possibilities.
Deployment Model:
LegalCloud is a Hybrid Cloud composed of both community and private types.
Our Community is Law Firms and only law firms. This focus allows us to uniquely and completely address the needs of our clients.
As a Hybrid cloud, we provide both on-premise and off-premise services for our customers that bridge the gap between their own facilities and the cloud facilities we manage as is appropriate and necessary.
Essential Characteristics
The LegalCloud console (1.1), which is in Alpha at the time of this writing, is the tool that our clients use to self-provision servers in any of our globally distributed data centers. For the first time publically I’ve included a couple of small screen shots from our staging environment. The things they provision are networking, compute, storage, and a few other related things. The storage components in particular are interesting because they can be further dynamically provisioned and grown (or shrunk) on-demand.
The resources that clients provision via our console are from pools of resources. In our case they are not truly location independent as we must provide a certain amount of auditability. But, they are deployable in various geographies.
Rapid elasticity is primarily a function of programmatic interaction w/ API based controls. We will not have API access for our first release. But, we most certainly will layer it in over time. Now, which one to pick?
Our console in association with something we call a pod manager is essentially a part of a distributed monitoring tool that allows our clients to keep an eye on what’s going on for key metrics in their pod.
LegalCloud has an currently uncommon “broad network access” model. It’s production environments are only available to clients via secure VPN technologies or private lines (point to point or MPLS). We do not allow general access via the internet at large. Period. Within legal cloud all clients, while they do share some infrastructure, they do not co-mingle their data/networks.
That wraps up my comparison of how LegalCloud can be fitted to the NIST cloud computing model.
What’s next?
What is missing from the NIST model today, if it belongs there at all, are the security aspects. I have seen what is likely to be important and solid work going on around an initiative called A6. It discusses Audit, Assertion, Assessment, and Assurance API. This is also now known as A6. There is a great amount of discussion going on in this arena and I’m looking forward to analyzing LegalCloud relative to the A6 API as it matures.
So, as soon as possible, I will write about the other issues around security related concerns and some of the issues that matter to our clients around varous A6 stated concepts.