Monday, March 24, 2008

Elastic Servers and Amazon EC2 Security Groups

If you have accessed the Elastic Server Manager which runs on port 2999 in each virtual machine we create, then you have probably noticed the Firewall tab.

Each Elastic Server comes with a built-in firewall which can be administered via the management UI or its web services. The Firewall tab can be used to manage the ports used by your server.

Some components have their default firewall ports already set in the Firewall tab. That is because someone (most likely us at the moment) has implemented what we call a "firewall rubberband" for that component. The whole topic of using "rubberbands" to snap things into Elastic Servers will be documented more fully in an upcoming post.

Regardless of what the specific server's firewall is doing - when using EC2 - you need to be aware of the Security Group which controls Amazon's firewall and access to your running EC2 image. Currently, we DO NOT coordinate the firewall settings of your VM with the Amazon Security Group (although on the roadmap). In order to access some of your services you may have to manually configure the Amazon Security Group.

Here is an example:

Suppose I build a Shindig OpenSocial server via Elastic Server On-Demand using my Amazon EC2 credentials. When I attempt to access my sample gadgets I can't get a connection via:

http://amazon-public-dns-name:8180/gadgets/files/container/sample1.html

Where my Amazon public DNS name is something like: ec2-72-44-51-65.z-1.compute-1.amazonaws.com

and 8180 is my Tomcat port.

The reason is even though my VM's firewall is accepting traffic on the Tomcat port, the Amazon firewall for my image is not.

To correct this I use the Firefox plugin for EC2 called "EC2 UI". After configuring the plugin with my credentials it lists the Public and Private AMIs I have access to. In the picture below you can see that I have launched an AMI called "pat-dig". You also can see that it has been launched in the "pat-dig" group.


To change the port settings in the security group I click on the Security Groups tab. In the picture below you see the result; the port settings for the pat-dig security group. Port 8180 is not one of them. The ports you see are the default port settings we use when making an AMI through our service.

In the bottom third of the screen you see the Group Permissions. To add the port 8180 permissions for Tomcat, click on the green circle with the checkmark in it. This will pop up the UI box below, where you enter the rule that inbound traffic on port 8180 should be delivered to the VM instance on port 8180.


After entering 8180 as the "from" and "to" ports. I click on add - which results in the refreshed display of the Security Group below.


I can now access my Shindig container running under Tomcat!

Monday, March 17, 2008

All at once I saw a crowd

Last week James Governor of Redmonk published a blog entry entitled “15 Ways to Tell Its Not Cloud Computing”. It drew some very interesting commentary from Mark Cathcart, John M Willis, Chris Petrilli and Gerrit Huizenga.

James was kind enough to acknowledge my input in his blog entry and in return I’d like to offer some views on why I substantially agree with his blog post. Please note that this is an emerging space and the idea of a cloud remains nebulous. So what James is really saying, I think, is: let’s ask what we want from cloud computing in the next few years.

Clouds are all about delivering a “retail like” experience to users - even within the enterprise. Here is an analysis what this might mean.

If you peel back the label and its says “Grid” or “OGSA” underneath… it’s not a cloud.

Clouds are about offering compelling economics for infrastructure as a service instead of as on premise servers or big desktops.

Clouds offer a fundamentally different abstraction than Grids. If there is a metaphorical ‘label’ then you should not be able to ‘peel it away’ at all. Grids provide a mechanism for running processes that implement a specific API, across multiple compute resources. Clouds provide a service for users to run whole applications by deploying them to a virtual data center.

Of course clouds can use a grid technology under the hood, for example to schedule slots. But the point is that many complexities are hidden from the user in order provide a clean and simple service. Whether the cloud is “public” like Amazon EC2, or in some sense an “enterprise” or “private” cloud, it delivers a “retail experience”. You should not need to read and understand multiple long documents to use it. I know of several hedge funds running grid style compute farms on EC2 using map/reduce on Xen images - it’s easier that way.

If you need to send a 40 page requirements document to the vendor then… it is not cloud.

In my opinion a cloud should offer “self service” capability. The cloud should not itself need to be customised by the provider, for individual customer use cases. This is not just about “productising” for the retail market. Consider an enterprise with two data centers. Clearly it saves money and time if applications can be migrated between data centers without refactoring. An enterprise knows it has implemented a cloud, when this is possible. Achieving this requires a certain abstraction.

If you can’t buy it on your personal credit card… it is not a cloud.

Well - sort of. This is about managing cost when multiple users share common server infrastructure. Without a means to capture costs of use and attribute them to users, explaining where value comes from becomes a matter of guesswork. This hampers investment in new enterprise projects by staff who want access to shared infrastructure, and commonly leads to ‘guerilla’ use of things like Amazon EC2 by staff on their own credit cards.

At CohesiveFT we meet customers who tell us that, as they migrate to ever larger pools of shared infrastructure services, they are unable to understand which business units are using which resource and when. Individual business units are unable to calculate cost/benefit. Costs get aggregated to maximum granularity and have to be justified by the CIO and CTO to the CEO and COO. In practice this makes it impossible to get things done.

The solution that I think the cloud model enforces is based on the discipline of a retail model. If data center providers made all users attribute costs as if they were paying by credit card, then everyone would know how much they were paying and for what. This would break down barriers to financing and starting new projects however small.

If they are trying to sell you hardware… it’s not a cloud.

Clouds represent a way to separate ‘opex’ from ‘capex’. People making investment decisions about cloud resource needs should not need to factor in any amortised capital investments in hardware, because they only pay for what they need, when they need it. When a business case is being made for a new enterprise project, if hardware purchasing costs do not appear in the ROI calculation, then you probably have a cloud. Then, the data center managers decide how much hardware to buy and at what price to offer their cloud services to business units. An internal market may be used for dynamic pricing.

If there is no API… it’s not a cloud.

If there is no API then it is not a service. Clouds virtualize resources (e.g. CPU, storage) as a service. Hence clouds must have APIs, e.g. a means to load and start up an application, or to stop it.

If you need to rearchitect your systems for it… it’s not a cloud.

The key word here is ‘need’. What we are discovering is that virtualizing whole compute environments may be the right way to ‘do’ utility computing. Whether computers are delivered as bootable images or as VMs, this means that people are not required to completely rewrite their application to run it in the cloud. Do we need to explain why this is more attractive than the alternative? I didn’t think so.

Note that people surely will come up with new ‘green field’ applications that depend critically on the cloud infrastructure. These ‘virtual stacks’ are very exciting too.

If it takes more than ten minutes to provision… it’s not a cloud.

Is this controversial? As John M Willis points out, the whole notion of provisioning is being replaced by autonomics and elasticity for managing running systems. At CohesiveFT, we also argue that elasticity really means provisioning includes built-to-order system assembly.

If you can’t deprovision in less than ten minutes… it’s not a cloud.

This is really critical. Being able to stop something and clean it up, is much more important than being able to start it. Anything else just adds friction which translates into less incentive to use the service in the first place and hence less agility and other benefits.

If you know where the machines are… it’s not a cloud.

Location matters for many applications such as trading systems, and complex clusters, because location impacts latency. But then the latency properties of a service ought to be exposed as part of its contract with the user. Then, perhaps users are willing to pay more for lower latency, or for better bit throughput.

What clouds ought to do, however, is get us away from any ‘my rack, your rack’ thinking because that breaks the retail model by recoupling opex to capex.

If there is a consultant in the room… it’s not a cloud.

Of course if you want to build your own clouds and work out the business case for moving system administrators over to new roles such as “virtual sysadmin” then get a consultant.

For actual use of a retail-like service by the enterprise, or within the enterprise, you should not need a personal shopper unless your use of clouds is a vanity project.

If you need to specify the number of machines you want upfront… it’s not a cloud.

The point is that you can increase your load whenever you like, so long as you can pay for it. Hence it does not matter if you start with zero machines or ten thousand. This is not the same as saying “you cannot request how many machines you need”.

If it only runs one operating system… it’s not a cloud.

This is about cloud providers not forcing end users to adopt their particular operating system distro and build. It characterises the difference between the new ‘self service’ clouds based on virtualization technology, and the CPU-rental model of a couple of years ago.

Generally the people we meet have their own ideas about which O/S to use on their computers, so why not extend this to the cloud? The alternative is to offer a data center service which only runs a particular O/S build - this kind of Linux, that distribution, and that build. In an enterprise, this simply does not scale across multiple data centers over time. For a retail cloud, it’s out of the question. This is why it is hard to see retail and enterprise clouds working commercially unless the compute unit is a virtual image or bootable image.

If you can’t connect to it from your own machine… it’s not a cloud.

Clouds are about consolidating resources in order to benefit from economies of scale. When a service is inaccessible or unavailable, then that diminishes its value to the service provider as well as the end user. We have found that people want to do things like spread their loads across their own machines, and data centers, or across multiple clouds securely. We call this ‘multi-sourcing’. Obviously some degree of secure accessibility is a prerequisite for this.

If you need to install software to use it… it’s not a cloud.

“You” means the user - clouds are about making life easier for users. If you are an enterprise with a cloud, or using clouds, then you may have teams all over the world, including folks coming and going all the time, or working from within IT suppliers or at customer sites, then your cloud will have a lot of users. You want to reduce any costs that you are currently paying for them to access your IT resources. This is why a ‘retail experience’ is so essential. Cloud means service.

If you own all the hardware… it’s not a cloud.

Because you don’t want to own all the hardware. It eats up power and space, gives off heat, and needs people to look after it. As more and more “green tape” appears in the form of environmental regulation, and if oil prices go higher, trust me you won’t want to own and be responsible for owning and managing hardware.

If you need a three page blog post to explain it ... it’s not a cloud

Enough already!

Wednesday, March 12, 2008

Sproing!! Elastic Server On-Demand 1.0

CohesiveFT is proud to announce the open availability of Elastic Server On-Demand 1.0. We were in closed beta since last July, learned a lot and incorporated it into our platform. We officially launched 1.0 on Feb. 19th and have completed some post-launch tweaks, including a new automatic guest mode requiring no registration.

Here is a quick recap for those of you who haven't heard about Elastic Servers before now:

Elastic Servers are customer-configured, multi-sourced application stacks built dynamically in virtualization-ready formats and made available for download, or for autodeployment to EC2 with your Amazon credentials. More autodeploy "cloud" options coming here in 2008.

Why do we call them "Elastic Servers"? Basically we are out to let customers build the stack they want - with no more - no less in it - and deployed in new dynamic forms like virtualization containers. We currently support VMware, Parallels, XenSource and Amazon AMIs.

Lots of New Stuff!
  • Community edition with no registration required. You can use the service to build or download 3 virtual machine servers. Later, you can claim your account and register if you like while the browser session is still active.
  • Personal Edition Trial. Create your own component assembly portals! Manage your virtual stacks privately or become a community editor by having your private portal published for others to use.
  • Server Templates. Now useful community servers can be defined as templates. This allows each user who builds a new server from a template to get a unique internal ID for future patch and lifecycle features. Also, no more DHCP conflicts between VMs since we give each one its own unique MAC address.
  • Shared EC2 credentials. You can allow friends to build and deploy EC2 images from your credentials. They can use them, but not see the credential details.
  • Improved community dashboard with 45 day data window. See what types and formats of VMs are being built.
  • Ability to add components to pre-defined server templates. Now you can pop a server definition from a community server or template into the Bundle Explorer for "ala carte" customizations.
  • And drum roll please.....
"BUILD YOUR OWN" is now available.
The number one request we got out of the Private Beta was "that's great that I can build a Stack in minutes, how do I put my own code into an Elastic Server?" When we responded "rsync", people were bummed. What they were asking for was the ability to import code into ESOD, either into a community repository or a personal repository, and use it in a server definition. One of the goals of ESOD is to allow users to take their application stack ‘recipes’, capture them, and allow others to reproduce them as virtual servers automatically with both speed and quality. So the request for personal components should not have surprised us - but it kind of did.

We're back! And with this release you have the ability to import code into the system and make it available to others (or just yourself). We do this with "typed" uploads; we support WAR, JAR, Ruby App, Mule Endpoint and Filesystem Tree in this release with more types coming soon.

Future blog posts will show how easily this facility can be used to make turnkey servers available for others to use.

Please, come be a guest. Even better register and build a component portal for your perfect application or application stack - and we will publish it for others to use!

Thursday, March 6, 2008

From P2V to Z2V


What are the "waves" of virtualization? What is the recent history and what is the recent future likely to look like?

Industry analysts for the most part tag the ubiquity of virtualization in the Enterprise at about 20% by the end of '08. And targeting 50% by the end of 2011. For a variety of sources see the folks over at Virtualization.Info for more analyst data.

Here is how I interpret the past and the future given these numbers.

Wave I - Server Consolidation
I used VMware about 10 years ago at my first start-up, Bedouin. We used it to encapsulate the version control system CVS into what today would be called a "virtual appliance". At the time our usage was not common, and was in fact downright mystifying to the VMware business development people. The prevalent use-case at that time was for consolidation of Microsoft software servers like Internet Information Server and Exchange Server. Since the MSFT OS only allowed one instance of these servers to run on a given copy of the OS, it meant that federated environments ended up with multiple servers just to run departmentally controlled servers, which weren't necessarily fully utilizing the hardware. The gains here were extremely tactical; ability to consolidate similar software servers run by departments onto one server for ease of administration.

Wave II - Server Migration (P2V)
Beginning about 4 years ago early adopters began the practice of P2V or Physical-to-Virtual. This involves running an agent that converts the hard drives of a physical server into virtual hard drives incorporated into a virtual server. Each of the "core" virtualization providers (VMware, XenSource, Parallels, etc.) provide this capability for their brand of virtualization. Additionally, some Open Source utilities like Ultimate-P2V, and commercial products from LeoStream and PlateSpin (just acquired by Novell), have the ability to output from a physical server to multiple virtualization formats.

There is definitely one huge "pro" for organizations that aggressively do this style of server migration; the complete decoupling of your hardware capital investment from your software capital investment. What is the rule once you get a piece of software installed and running on a server? Answer: DON'T TOUCH IT - EVER!!! NEVER! P2V lets you break this rule with relative impunity. Once you have migrated a given hardware server to its virtualized server counterpart, you can actually move it to more powerful hardware over time. You can even move it to run in a different physical location with only small risk. Good stuff - IT gets a structural agility in a key dimension.

What is the big "con"? Basically you have migrated your legacy into the future. It was low risk - but where you once had big, bloated, over-provisioned, hardware servers with generational accretion of software bits of unknown provenance, you now have big, bloated, over-provisioned, virtual servers with generational accretion of software bits of unknown provenance. Because these are virtual bloatware, you aren't going to get much of a gearing ratio between your new virtual servers and the underlying hardware. Maybe you can now run 2 VMs on one server, but in some cases you might end up running only one VM on a physical server. BUT, you gained the ability to manage the two streams (hardware and software) separately, which does help. See this recent article where a smart CIO has gained from a Wave II approach, but he cautions "When assessing the cost of converting to a virtual environment, it's important to realize that virtualization requires additional network storage since it takes 20 GB to load the OS of a virtual machine." There, on the topic of Wave II bloatware - I rest my case. Wave III eliminates this problem and allows you much higher numbers of VMs per physical server.

Wave III - Server Innovation (ZtoV)
In this wave you can attain true server agility because you are doing "Zero to Virtual"; building from component libraries straight to virtual servers in any VM format, with no initial physical footprint. The big win here is you are able to do "lean" provisioning. You use a small footprint OS (one you have configured, or Red Hat AOS, or Ubuntu JEOS, or one of the small footprint OS's for use in virtualized servers) as the base of the server. This means smaller surface area of attack vulnerabilities, streamlined administration, no over-provisioning of then unused commercial licenses, and more virtual servers per physical hardware. A knock-on effect of these lean machines is greater mobility, more easily allowing leverage of utility or cloud infrastructures.

Speed. Agility. Lower costs. I like it.

Think about it. If you have 100 servers, and you have dutifully "P2V-ed" them, what do you do for your 101st server? Do you really build that 20 gig OS build plus over-provisioned application stack and middleware? (DVD's, Installshield, InstallAnywhere, Tar, Zip, GZ and more) Then run the P2V agent? Then move it out a physical server? Or use a component repository approach and go straight to the virtual container?

Where do you find Z2V solutions? Three good examples of ZtoV out there are: my company CohesiveFT (obvious bias on my part), rPath, and FastScale. We each have a different approach to the problem with frankly different go-to-market models and target customers. This isn't the place (at least today) for compare and contrast. The point is that ZtoV is fast, agile and allows you to capitalize on the wave of innovation happening in data center computing today.

In summary
I think Wave I of virtualization is done. It might be happening in the far left tail of the distribution, but there is too much to gain in capitalizing on Wave II and Wave III opportunities to stop at a Wave I approach. The focus of my company is Wave III, allowing customers to pursue "server innovation" through Z2V, but that doesn't mean there isn't a whole lot of P2V to be done out there. That's why Novell paid $205 million for Platespin. That said, I think P2V will be the approach of choice for organizations that have pretty static server infrastructure. And the approach for migrating legacy.

Organizations that have loosely-coupled distributed computing infrastructures (running things like web services stacks, enterprise service buses, message queues, application platforms, page servers, etc.) already have an active application refresh rate. In this refresh process they can use Wave III techniques to gain more leverage. Because of this, it would be too simplistic to say "P2V is for legacy" and "Z2V is for greenfield projects". It is more likely that the refresh rate of an organization's commercial and proprietary applications will be the determinant for which approach to take.

At CohesiveFT we focus on the Wave III model, but expect that organizations will be running both Wave II and III models simultaneously over the next couple years. Of course time will tell.
Related Posts Plugin for WordPress, Blogger...