It's Release Week for Ubuntu and CohesiveFT

Today Ubuntu released the latest version of its operating system, 8.10 (aka Intrepid Ibex). In an unsurprising twist of kismet, the CohesiveFT team is delivering our own bouncing Ubuntu bundles of joy, available now in the Elastic Server factory! Coincidence? We think not.

The Stats
Initial Elastic Server support for Ubuntu comes in the form of the Hardy Heron 8.04LTS version for 32-bit, including Amazon EC2 small, on the most popular bundles in the Elastic Server factory.

Where can I find these so-called bundles?
To quickly locate Ubuntu-ready bundles, go to the Bundle Explorer and search for the tag, Ubuntu 8_04LTS. This tag indicates that the specific bundle has been tested and approved for use in your Elastic Server. If your favorite bundle isn't Ubuntu-ready yet, you can push your component to the top of the list by posting a request (including a link to your bundle) to our support forums. We add new bundles on a regular basis. Currently, the most popular bundles in the Elastic Server factory are:

• MySQL 5 - CFT Rubberband [5.0.32] (1361 servers)
  
• Apache 2 HTTP [2.2] (772 servers)
• PHP 5 [latest] (705 servers)
• Ruby on Rails [2.0.2] (704 servers)

Why is this cool?
Like Ubuntu, we're all about freedom. Elastic Server gives you the freedom to choose the components you want from our library of horizontal, open source and third-party software components. Don't like those? Upload your own components with our Build-Your-Own (BYO) option (here's how). Did we mention the Community Edition of Elastic Server is free? Oh, it is.

If you've never assembled an Elastic Server, you are missing out on the point-and-click ease of assembling virtual servers in minutes and deploying to the cloud or virtual machine. Take a peek inside the factory and see what 1,600+ users have assembled thus far.

We're expecting
When you're building an automated assembly factory as awesome as Elastic Server, there are a lot of moving parts to consider. We are excited to offer support for a new operating system. And with new users regularly adding components, the platform continues to thrive. You can expect more bundles of joy as our Elastic Server family grows.

What's next for Ubuntu Elastic Servers?
We've got our eye on Intrepid Ibex. Even with its long beard and supposed "Alps" location, we expect you'll be seeing Ubuntu 8.10 available in the factory later this year. Watch this space for more updates.

Until then, happy stack making.

FINEST OF PRINT: Ubuntu and Canonical are registered trademarks of Canonical Ltd. We were told we could use this stapler.

VPN-Cubed™ - Security and Control in the Clouds

We couldn't wait any longer. Today, we announced the availability of VPN-Cubed, our packaged service (think half software half service) for enhanced cloud security. VPN-Cubed is an encrypted virtual private network (VPN), enabling customer-controlled security inside a single cloud, across multiple clouds, and between clouds and private infrastructure.

We see the current economic downturn as actually increasing Cloud Computing interest. Rather than writing that $2M check for your data center hardware refresh, wouldn't you rather manage your infrastructure as a service? Moving part of your infrastructure to the cloud turns capital expenditures (or fixed costs) into operational expenditures (or variable costs). According to IDC, a global provider of market intelligence, cloud computing is poised to capture 25% of IT growth spend by 2012. Yet, in a recent IDC survey, 74% of IT executives/CIOs cited security as the top challenge preventing their adoption of the cloud services model. Today, clouds are secured by the cloud providers, but from a governance and compliance point-of-view shouldn't you take additional measures - that you control - to secure your cloud assets? CohesiveFT's VPN-Cubed gives customers the confidence to utilize cloud computing by offering a layer of security that the customer controls.

We have always positioned ourselves as a cloud/virtualization complement, enabling users to adopt cloud computing quickly and easily with the Elastic Server® Factory for VM and cloud image assembly. Dealing with what we call the "more of everything" problem (more software components, more virtualization formats, more cloud providers, and more operating systems), CFT is at the forefront of helping customers control their infrastructure in the cloud.

We are not a security company, but we have always recognized the importance of, and pioneered techniques, to provide a customer controlled security layer inside cloud computing topologies. We started by shipping all Elastic Servers with their own unique identity and firewall. As we worked with customers looking to deploy clusters to the cloud we recognized a new and not well understood problem: the need for additional cloud security at the cluster level. Our solution is a cloud VPN, which includes well known components like openVPN within a novel implementation for use in cloud computing scenarios. VPN-Cubed is our way of moving the cloud security conversation forward.

The typical VPN is used as a tunnel between Corporate HQ, branch offices, or employees' computers for secure communication to email servers and the like. Usually VPN implementations are "cheap and cheerful" infrastructure, sometimes it goes down for minutes and people just deal with the transient outage. "Brown outs" or "blackouts" of mission critical infrastructure aren't unacceptable so we added redundancy measures to VPN-Cubed. What happens when your cloud vendor drops? VPN-Cubed is uniquely configured to deal with multiple clouds, vms and operating systems, giving you the control and flexibility to failover (cloudburst) to another cloud provider. VPN-cubed lets you run your whole cloud topology as a cloud WAN.
CohesiveFT is always working to provide you with YOUR stack in the virtualization or cloud format of your choice, we want you to extend that to include YOUR security in the cloud. Start the cloud security discussion with a member of the CFT team by visiting our VPN-Cubed page. Realize cloud computing benefits instead of just reading about them.

We're #1, (and #2, kind of #3, and #6, and part of #10)

Yesterday, Gartner Group announced their top ten technology trends for 2009.

Heading up the list of 2009 trends is Virtualization, followed closely by Cloud Computing. Since we started down the Virtualization and Cloud path more than two years ago, some might say that we saw this coming. We've specifically architected our Elastic Server platform to meet these changes in the virtual landscape. Our automated "factory" lets you assemble custom virtual servers in minutes, and deploy to the cloud or virtual environment.

We are pretty excited about how big virtualization has become (thank you VMware for the 10+-year-hard slog), and how interesting the skyscape of clouds is becoming.

We started CohesiveFT with the premise that 4 major trends were colliding in the data center and were going to reshape the IT environment from development thru deployment; open source, open standards, virtualization, and loosely couple architectures. In many ways I think of cloud computing as the "first derivative" of these trends - and has become a trend of its own, a 5th driving trend reshaping the IT landscape.

Also, surprising was Gartner's #3 (Servers-Beyond Blades), #6 (Specialized Systems), and the now ever-present Green IT at #10. It seems like these are additional byproducts of the same forces. The way I see it, we have been fortunate to live through a "silent earthquake" in IT, and the aftershocks keep delivering smaller - but interesting enterprise impact.

If you're thinking about how you might adapt your IT department to meet these 2009 trends, come check us out. In the meantime, we'll keep doing the voodoo we do to stay ahead of the curve.

Elasticizing Your Ruby on Rails App

CohesiveFT's Elastic Server platform is a web-based factory without all the noise and occasional grime. Inside the factory, you can create a server "blueprint" that is created from components in our library, or components you upload yourself. Your custom-assembled server can be deployed to a variety of virtualization and cloud environments. Did we mention the Community Edition is free?

In this blog post, Yan Pritzker is going to show you how to quickly get your Rails app from your local repo, or from GitHub, up to Amazon EC2 in a few easy steps.

To make this post easy to follow, the first section will talk about turning your Rails application into a component in our library, and the second section will talk about how to use that component in an Elastic Server running in the cloud.

Part 1: Turning your Rails app into a component in Elastic Server

Log into Elastic Server with your free community account and click on My Packages under the Account tab.

Select Ruby on Rails from the Package type drop-down menu, and fill out the form with the name of your application. I'll be doing an example using my Working From Home application, a simple way to let coworkers know where you'll be on a particular day.

Click through to Step 2 to upload your application. Either use a zip or tarball you created locally, or if you use GitHub as your repository host, use a convenient url like http://github.com/your_login/your_project/zipball/branch_name to have Elastic Server grab your project directly from GitHub. Cool! Using GitHub makes it really easy to build new versions of your application as Elastic Server components.

Your package will begin building. This should take a minute or so.

If your application has special startup needs (such as running migrations to create the initial dataset), you may want to create a component to do this. Go back to creating a new package, and choose a Run On Boot script. This is a quick way to do boot-time configuration and maintenance for your Elastic Server.

Meanwhile, back at the My Packages screen, your packages should have finished building. Since we'd like to always take these two packages together, we'll connect them by creating a bundle.

The bundling process lets you select the packages you like and group them together. Use the Package Bundler view to select your packages from the My Packages tab, and place them in the cart. Then click the aptly titled, "Create The Bundle" button under the cart to, yes, create your bundle.

Once your bundle has been created, Elastic Server can assemble a server! You'll be taken to the page created for your bundle. Click the Add to Cart link to get it into your bundle cart and prepare to build a server. Note this Known Issue: We currently have a ten-minute delay before a package can actually be used in a server, which is not "as it should be." We're working tirelessly to make this issue go away, so thanks in advance for understanding.

Part 2: Assembling Your Elastic Server

Since we're building a Ruby on Rails server, we'll need to add components like Mongrel and Nginx or Apache and Passenger to our server. A great place to start is the Rails Community Portal, a special page that groups together the best Rails components available on Elastic Server. This page also has some instructions and a link to a Capistrano script that can help you deploy your apps directly to Elastic Servers running in the wild.

You could build a page just like this for your product, company, or team, but we'll get into that in another post :-) After picking the components you like from this page, we're ready to go to the configuration screen.

Important: Please note that in order to deploy your server to Amazon EC2, you'll need to add your AWS credentials on the cloud manager page. This page uses SSL for security and your credentials are stored in encrypted fields.

The configuration screen lets you name your server and pick a virtualization or cloud format. We'll be going straight to Amazon EC2 for this demo, but a great way to test your applications is to download a VMWare image and run it in VMWare Fusion for Mac or VMWare Player for Windows. Note on the left side we have a list of components going into this server. This information is always saved with every server you build, making it easy to recreate the same setup at any time, in any format you choose. No more having to rememember exactly what you tweaked to get your box to work :-)

When you click the build button, you'll be taken to the dashboard, which shows you the progress of your server. Depending on the amount of software going into your Elastic Server, the process may take from 5-15 minutes. When it's finished, you'll get an email with a link to your newly running Amazon EC2 Instance!

You can also check out the status of your instances at the cloud manager. This page provides easy access to your running instances, as well as a link back to the Elastic Server information, so that you always know what's running in a particular server. Just one thing left to do to launch our app!

Clicking on the Admin Console link on the cloud manager, or from your email, you'll be taken to your freshly minted Elastic Server running in the cloud. The web-based admin console, also known as Elastic Server Manager will prompt you to change the default admin password for security. Then, you'll be on to the services screen where you'll see an entry for Mongrel/Nginx or Apache/Passenger, or whatever configuration you've picked from the Rails portal.

Components in the Elastic Server library come with plugins called rubberbands that enable components to provide their own configuration screens for the Elastic Server Manager. Imagine shipping your Elasticized Rails app with its own admin screen that makes it easy for your users to administer the server without knowing anything about Rails? We'll pause while you imagine...

To start and stop your Rails application, simply click the Start or Stop button next to the service. Congratulations, your Rails app is now running on port 9000! Don't forget that you can now easily start and stop more instances of the server using the cloud manager, and explore the Elastic Server Manager for more fun stuff like the ability to view your application's logs without ssh into the server.

And that is how you Elasticize your Rails app. Thanks for joining us. We welcome your feedback in the comments, or our friendly support forums.

Fear (of virtualization) is the path to the dark side...

Fear leads to anger. Anger leads to hate. Hate leads to suffering.” - Yoda

OK. I couldn't resist given the recent eWeek article on The Dark Side of Virtualization.

I stipulate to the article's author and its source Bob Waldie, CEO of Opengear, that virtualization can bring some challenges. But, I would harken the situation as more like the picture of Dorian Gray than some amorphous dark side.

The challenges that come from adopting virtualization are mostly a function of the things you are already doing wrong. The reason IT is complex and expensive is certain fundamental IT processes are broken already - and putting them under the stress of the agility of server devices and the number of server devices that are possible is just too much. Businesses do not have a limited appetite for the number of problems they want to solve using IT, they have a limit to the amount of IT complexity they can manage. Thus, they fall far short of their business aspirations because of what amounts to being technology management limitations.

So, let's look at the bright side where using a platform like Elastic Server can help you win in the epic battles of good vs. evil, light vs. dark, and Matt Damon vs. Mark Wahlberg.

eWeek #1) Are you sure that virtualization will, in reality, deliver you a positive ROI? (Translation: Increased management and administration costs may prevent this)

This is the easy one. Even in the most minimal case - this is a no brainer of slightly lower admin costs - lower capital costs and a shift of capital costs to operating costs.

Here is an example:

• you have 20 physical servers - and you consolidate them into 20 VMs running on 10 servers

THEN:

• you have fewer moving parts that can fail and plugs that can be unplugged
• you have slightly higher concentration risk (2 logical servers fail in the event of one physical server fail)
• you have halved your floor space needs (ok think of a tiny datacenter with 20 towers standing neatly at attention)
• but you still have the same logical footprint of 20 servers (no increase, no dcrease)
• you did this consolidation as hardware reached the end of its lifecycle
• you didn't buy 10 new servers (you saved the money of new hardware)
• you saved the cost of installing the new hardware with specific applications on the hard drives
• when you acquire the next new machine, installation of the virtual machine capable software (the hypervisor) is installed by Dell (or in the odd event you don't buy from Dell, some other hardware vendor)
• when the new server arrives you plug it in, and filecopy the 2 virtual machines from the old server (basically filecopy of 2 files) to the new server during your maintenance window
• you fire the VMs up on the new server
• you unplug the old server
• you throw it away

Ah...but where do the virtual machines come from? How does your staff assemble them? In this model of a relatively static, low turnover operating environment - you can certainly use "P2V" tools (physical-to-virtual) which turn hard drive images on your physical servers into virtual machines. Chicago-area-based Vizioncore has a slew of these capabilities.

"AHA" - you shout, "There is a dark side! What if I have a high turnover environment where we need to be re-building our servers all the time?" This is where things get bright. The more dynamic the environment the more likely what you want is not "P2V" - but "Z2V" (zero footprint to virtual servers).

This is the gist of what the Elastic Server platform can do for you. With a little bit of work you capture those server definitions as templates which can be easily modified and assembled on demand in the virtualization format of your choice - without there ever having been a physical server. There is no server, click a button, now there is a virtual server ready to roll out to your virtualized infrastructure. Magic!

eWeek #2) Do you have the IT staff to deal with increased complexity? (Translation: Virtualization is complex)

IT is complex. One of the things that drives this type of IT complexity is the practice and belief that servers are hard to configure and deploy (and redeploy). This is true but doesn't need to be true. Let's look at the timeline and how we got here:

1988: Compile C code into an executable, copy that single file to a server. Proc it up. Done.

1998: Pile a bunch of HTML files into a Apache, WAR up some Java code. Done.

2008 (V1): Gather up tens of thousands if not hundreds of thousands of files, 2/3s of which will never see a compiler, gotten from between a dozen and 100 open source and commercial source frameworks, each of which is understood by a subset of your development teams, and not very weel by your operations teams and consistently get those files into the right places on the server. (Magic files, in magic formats, deployed to magic locations on the hard drive, in the thousands.) The state of the art of the process ranges from "done by hand" to "maven scripts that almost any Tom, Delilah, or Harry can change".


2008 (V2): Incrementally import each of the libraries into the Elastic Server platform (into a private repository or a community repository). Capture the semantics of how you want them to behave in assembly time scripts or runtime scripts. Mix and match them for the server targets you want to create. Click "assemble" and minutes later you get a virtual machine. Copy the VM to the server. Done.

It has taken us 20 years but we have gone from homogeneous infrastructure-single file deploy, through a maelstrom of ever more heterogeneous infrastructure with multithousand file deploy, to heterogeneous infrastructure-single file deploy (the VM). The x86 virtual container is a pretty cool deployment mechanism.

If done right - virtualization can be a driving factor in dramatically reduced IT complexity. The opportunity now exists to assemble your software servers from parts not unlike how hardware servers are assembled from parts.


eWeek #3) Are you resourced to manage the likely increase in demand? (Translation: Virtualization will be so successful for you, that once you get used to the agility and ROI that it affords can you meet the demand?)

Again. Absolutely. With the automated assembly capability of Elastic Server, you can assemble virtual servers at will - in the format of choice. Resources to meet demand? How about having the Amazon Datacenter at your disposal? Take the same server template that you assembled in VMware format, now select Amazon format with your EC2 credentials. Done. Server ready in minutes.


eWeek #4) Are your datacenter layout and power and cooling facilities and management sophisticated enough to manage consolidation? (Translation: It might get hot!)

Ok. If you are doing virtualization consolidation on a massive scale - this becomes an issue. But at that scale I would argue you probably have the skills involved. Me - I am back to the cloud on this one. Take non mission critical systems and move them to the cloud providers. (Frankly, I am comfortable moving mission critical systems to the cloud.) For sure, I am comfortable with Amazon, IBM, BT, Flexiscale, etc. dealing with the power and cooling "hot spots".


eWeek #5) What impact will virtualization have on your level of service (Translation: With more virtual servers per physical server, what is your failover strategy?)

Sorry. I see this as a push. And maybe I'll do a whole post on this soon as part of the "cloudbursting" topic. Failover is complex in general. Virtualization gives with one hand and perhaps, perhaps, takes with the other. But virtualization + cloud + loosely coupled architectures + Z2V + a few other bits gives you great agility. Being quick on your feet is a key part of the failover equation.

eWeek #6) Do you have the tools to be able to monitor/ manage your new sensitive complex environment (rack-side and remotely)? (Translation: You still need traditional rack tools and do you want to lock into just a single vendor solution?)

I agree with the guys from OpenGear. I am sure there are cases where you need magic boxes to switch between displays for the different physical servers and have console access to the virtual servers. See their website if this rings a bell.

But lets look at it from the dynamic assembly point of view. An assembly process for virtual servers gives you un-paralleled control of what is in the bill of materials for each server. This allows you to ensure that your monitoring agents are in every assembly, that remote desktop software, if desired, is in every assembly, that network ports for terminal access are enabled properly in every assembly.

Additionally, the value of this approach is it is cloud-friendly. The folks at Amazon and Flexiscale (nice as they all are), aren't going to let you install magic hardware boxes in their datacenters. It would be quite uncloudy of them. But - using the Elastic Server platform you can ensure that the magic software boxes are ready, waiting, and chock full of ROI.

So maybe there can be a dark side, but I for one think it is a pretty bright day up in the clouds. Maybe with virtualization it is as simple as, "Do. Or do not...".