There is a little here on CIOupdate about CIO concerns with cloud security. The article is short and a little overblown in how both sides are represented.
I’m currently talking to CIOs and CISOs at large enterprises and I’m not hearing any ‘panic’ so much as pragmatic concerns about securing cloud usage. The folks who are in charge of evaluating cloud services seem to be more concerned about auditability, accountability, and cost controls than enforcing enterprise security mechanisms on cloud systems.
To paraphrase a VP of Enterprise IT at a Fortune 50 company
This looks like an identity management problem to me. I’m more concerned about knowing what a user stored in the cloud or what servers are in use. How do I remove those files or turn off those servers when that user leaves us?
CloudScale will elegantly enable the secure management of clouds. Best of all, it was developed by infrastructure and security experts!
June 23rd, 2008
Greg Borenstein, principal behind Music for Dozens and out loud thinker sums up the potential long term impact of Amazon’s successful cloud computing model. It’s an insightful article and I think worthy of a close read, including the comments.
First Greg correctly sums up the obvious:
With the announcement of Amazon’s much-anticipated SimpleDB service this week, we now officially live in a world where the kind of enormous systems run by Google, Yahoo, Ebay, et al — systems that power huge portions of the web (where 500+ million users is totally mundane) — are available on demand in small doses and at reasonable prices to anyone who needs them.
And then talks about the impact on typical web developers:
On this infrastructure, the only real difference between running a small application (a custom CMS for a medium-sized non-profit, for example) and a large one (say, Digg) is the size of your monthly bill.
…
Within a few years, a scale of computation that is currently only available to a handful of multi-billion dollar companies will be available to any pair of dorm room-bound hacker kids with $30/mo. and a pair of MacBooks.
Unfortunately, Greg misses the mark here. While Amazon Web Services (AWS) are a strong evolutionary step forward, it’s clear that by themselves, despite Amazon’s excellent marketing, they do not create ‘web-scale’ (we prefer ‘cloud-scale’) systems. They only enable developing web-scale systems without deploying your own infrastructure.
Even today’s giants, like Amazon, rely heavily on know-how and expertise that is not readily available to the masses. There are no systematic approaches to building scalable, distributed, secure, and reliable systems. Well, not yet anyway . . . (more below)
Greg makes some additional comparisons to watershed technology moments:
For a few clues as to what happens when the current, if obscure, state of the art becomes an industry-standard lowest common denominator, it helps to look at some history. This has happened at least twice in the last thirty years: once when industry standardization around x86 hardware lead to the collapse in prices for DOS- and then Windows-compatible PCs that made them ubiquitous around the world; and again when these same PCs reached a level of power and the open source software written to run on them reached a level of affordability and reliability that, together, they displaced the expensive and proprietary server systems and radically lowered the barrier to entry for web-development leading, as Tim O’Reilly has clearly outlined, to Web 2.0.
I think these are apt, comparisons, but not taken to their logical conclusion. It’s truly the synergy of commodity hardware and commodity (open source) software that allowed cheap x86 systems to displace Big Iron. The software, in this case, provides the systematic mechanisms for repeatably leveraging cheap hardware. Without it, people would have to individually cook their own operating system and the applications on top of it or pay for expensive enterprise software.
You can think of open source software in this context as the institutionalized know-how for running cheap commodity hardware.
There is currently no parallel for web-based cloud computing services
Tools like Amazon’s S3, EC2, SimpleDB, and the others are simply one-off point services. They are more akin, respectively, to a disk drive, a CPU, and a rolodex. By themselves they have only minimal use. It is only when they are combined together well (and with other services?) by an operations or development architect with knowhow that you have a synergistic effect that allows the creation of cloud-scale computing infrastructure.
Greg’s first commenter hits the nail on the head:
The mere existence of these services is far from breaking down the barrier necessary for *anyone* to scale to amazon/ebay/google size services. There are at least, as I see it, 2 things still missing that won’t be “commoditized.”
First, is the know how. Building a scalable application (really, application infrastructure) is not the same as building a basic app. And if anything, the general trends have shown that there is a great wide void of knowledge in the market about how to do this successfully.
Second, is the management of this architecture. Ask any company running a large number of EC2 instances how they are managing it. Most likely, they are using a number of custom built tools. If they’re lucky, they managed to shoehorn some of the existing systems management tools into doing what they need. Either way, there’s a lot that goes into making this work.
Which is accurate and part of why CloudScale Networks exists. It is possible to write a new generation of software that institutionalizes the running of Internet infrastructure. Possible and inevitable.
Greg follows through to the crux of the matter by highlighting how the new economics suddenly make it feasible for folks to pursue long tail plays or other business models that were previously not possible.
Cloud computing is here to stay and it is absolutely a game-changing evolution of Internet infrastructure. We need to embrace and hasten the arrival of this model.
December 18th, 2007
Introduction
MicroVMs are a technology I was playing with for the first product we considered spinning out, the Virtual Server Room, a sort of virtual appliance micro-cluster in a box made up of back office IT servers. I thought I would write a bit about MicroVMs because I think they are going to have a special place in a future where virtualization is a dominant technology.
MicroVMs are to virtual appliances what small embedded systems like Linksys routers are to larger scale hardware appliances, like a NetScreen-50 firewall. Today’s typical virtual appliance is typically a simplistic packaging of a traditional OS and a bundled application. Some folks, like rPath and JumpBox have either created tools that more sophisticated packaging of these virtual appliances, like a traditional appliance, or, in the case of JumpBox, literally attempt to recreate the hardware appliance experience with a virtual machine.
I think that over time we’ll start seeing more sophisticated virtual appliances, but they will continue in the mold of the current crop and essentially under the hood is a general purpose OS that has been heavily customized.
Contrast this to small embedded appliances we see every day like Linksys routers, the iPhone, and similar products. Or more esoteric embedded systems like those from Dust Networks. Most embedded systems have specialized operating systems. Even when based on a more general purpose OS, they tend to have been stripped of almost anything recognizable to the original OS and, becoming in effect an embedded OS. This is usually done for power or simplicity concerns.
In fact, the smaller the appliance, the less likely it is to share attributes with general purpose computers. Smaller appliances have no disk drives, no consoles, no serial port access, with only a single button to reset them to ‘factory default’.
Imagine the equivalent for today’s virtual appliances. This is what I call a MicroVM.
MicroVMs
Given that resources such as disk, memory, and compute are so cheap why would a MicroVM that mimics a typical small form-factor embedded system be of interest? There are a number of reasons, which are generally similar to those for a virtual appliance, including:
- Increased security
- Ease of deployment
- Disposability
But in my mind, perhaps the most interesting usage is the temporary deployment of services at run-time in front of already deployed virtual machines. For example, say that you want to deploy a network sniffer in front of an already deployed virtual appliance? This is easy today. An IT staffer will simply put a laptop or a network sniffing device temporarily in-line with a physical server. But with a virtual server it is much harder. In fact, we’re regularly seeing more complex network setups inside of a single physical server while the tools to troubleshoot and debug those setups have not become more sophisticated.
An Example
As part of the Virtual Server Room (VSR) project, which never saw the light of day outside of the lab, I developed a MicroVM based on the excellent pfSense (firewall) live CD-ROM. This firewall MicroVM built on top of VMware technology had some interesting characteristics:
- Booted from a ‘live’ CD-ROM
- Configuration state was saved to a ‘floppy disk’
- RAM footprint was 64MB
- No disk drives
This allowed me to install a network firewall in front of every customer’s Virtual Server Room using a mere 64MB of RAM, 35MB of disk space for the ISO CD-ROM, and 1.44MB per MicroVM for the ‘floppy disk’ image. In return, for each customer I had a full-fledged, easy to use and maintain firewall including routing, NAT, and a dedicated DMZ segment for ‘public’ virtual appliances. (In this particular case, the pfSense live CD-ROM is a MicroVM out of the box essentially, I just added control, configuration, and provisioning tools on top of it).
The embedded characteristics made adding a firewall to each VSR trivial and painless.
Wrapping Up
This is a very small example, but I think in the future we’re going to see most virtualization platforms (what the folks at CloudScale call a ‘virtual fabric’) such as VMware Virtual Center, VirtualIron, EC2, and XenSource make it very easy to change and modify the ‘physical’ structure inside the fabric itself at run-time. In those cases, adding MicroVMs on the fly for diagnostics, security, or similar capabilities is a no-brainer. How many security and network engineers would love the ability to slap a specialized tool into their current networks on-demand and in seconds? Most, I think.
We’re going to see a number of interesting use cases like this in the near future. MicroVMs, coming to you soon…
July 12th, 2007