Building a Smart Elastic Server

Today we opened up public beta access to our newest Elastic Server factory site, Smart.ElasticServer, that exclusively serves the IBM Smart Cloud Enterprise (IBM SCE) environment. The timing couldn't be better as it coincides with IBM's SCE announcement activities at their Innovation Centers around the globe. Many of the IBM Business Partner success stories being told are a result of the use of CohesiveFT products and services like the Smart.ElasticServer site.

Smart.ElasticServer.com is an IBM SCE-tuned implementation of our ElasticServer.com factory that has been providing multi-cloud image assembly automation since 2008. Our partnership with IBM is focused on providing enterprise application migration to the SCE. So aside from bringing the style sheet inline with Big Blue's color palette, we have tailored this factory site to allow virtual server import features and functions not currently available on IBM SCE. It allows IBM customers to start their application migration paths from datacenter to cloud, cloud segment to cloud segment, or cloud to cloud.


SmartImport
IBM SCE users can import Linux-based Smart Elastic Servers to their account in SCE using the Smart.ElasticServer factory. Imported Elastic Servers can either be built from scratch or using imported VMware images provided by the user. Users log into Smart.ElasticServer.com and link their Smart.ElasticServer account with their IBM SCE account. This association allows SCE customers to use "SmartImport" capabilities. IBM is enabling its SCE customers access to the Smart.ElasticServer image factory as part of the SCE public beta program. For more information visit Smart.ElasticServer.com or contact CohesiveFT.

Download our SmartImport PDF and start moving virtual workloads to IBM SCE today.

Slick.

Meet cft_smartcloud Ruby gem...

More and more of the CohesiveFT solution set is up and running in the IBM SmartCloud Enterprise on a daily basis. Our image automation folks, dyed in the wool Ruby-ists, came up with this Ruby language binding for the SmartCloud REST API.

For those of you who are object-oriented types, Ruby fans, SmartCloud users, or the curious - it is a neat interactive experience. It follows the naming convention of the REST API pretty faithfully but adds the "display_*" methods as convenience function to the "describe_*" calls.

My favorite is: smartcloud "display_instances(:order => 'Location')"

Check out the video here:
http://www.youtube.com/cohesiveft#p/u/0/-WdSHP2iwDM

If you have Ruby and the gems system installed, it should work using "gem install cft_smartcloud" and then "smartcloud help" from your command line.

Enjoy!



*on a Debian/Ubuntu variant you might need to say "PATH=$PATH:/var/lib/gems/1.8/bin" or call "/var/lib/gems/1.8/bin/smartcloud"

Open letter to Microsoft Partners (sort of): Don't retrain today.

OK. I hate open letters. I hate the faux header, footer, salutation, etc..

But, if I were of the wont to create such a thing, this is the closest I have come. I saw a tweet which pointed me to this article headlined:

Microsoft's Ballmer: 'Come on in, the cloud's lovely - just don't forget to retrain'


THIS MAKES ME CRAZY!
This is how Cloud Computing can fail in the enterprise (which is where Microsoft lives these days, they are not a darling of the Web 2.0 crowd).

I run into this "meme" plenty enough in the cloud circles - so it isn't Steve Ballmer alone.

And it isn't his fault I am limit up on this concept, but the message of "Hi, we are new, we are different, and in order to use us you have to re-architect, re-configure, re-learn everything!" is a pretty rotten message AND IT IS NOT TRUE!

One of the things that is so great about cloud is that super smart people have spent hundreds of millions of $$$ (billions?) at this point (thanks AWS, IBM, et. al.) so that I can un-learn a lot of things.

That is much better then re-training. I would love to have more things to forget. But so far I am happy forgetting how to manage datacenter hardware for one big category of cost savings.

Another great thing about cloud is that it runs x86 workloads. And you know what? My enterprise is full of those darn x86 workloads. And to make it even better, those x86 workloads don't need to be infinitely scalable, they don't need to run as formalized SaaS, they don't need to run as PaaS. They are "POA" - plain old applications. And I just need them to run somewhere. Hey - cloud is somewhere. Can't I use that?

Back to "plain old apps". If I have to re-learn, re-train on everything what is the point? First of all, why would I re-learn, retrain to use MSFT technologies in the cloud? If I am going to re-learn, re-train why don't I learn Linux, or the Oracle stack, or SalesForce and Force.com, or Google AppEngine for that matter.

However, if I just want my x86 Windows workloads to run - do I have to re-train to use the cloud? If I am a Microsoft Partner do I really need to re-learn and re-train just to move my products or services to the cloud? Blechh.

Questions:
1) Can't I just move my Windows servers in some relatively easy way shape or form to "the cloud" and get going?

2) Do I have to boil the ocean and move whole datacenters at a time?

3) Can't I get value and ROI on my investment one business application at a time, with only incremental training activities (say maybe way less training investment then understanding migrating from Windows Server 2008 R1 SP2 to Windows Server 2008 R2)?

Answers:
1) YES
2) NO
3) YES

if the cloud you use is the IBM SmartCloud Enterprise or Amazon EC2 (along with others).

This is what is so confounding about the re-learn, re-train, re-do everything mantra. Amazon EC2 runs Windows 2003 and Windows 2008 quite nicely. IBM SmartCloud runs Windows 2003 and Windows 2008 quite nicely.

So let's recap.

- I have zillion dollar data centers with more guards, guns, gas (halon), glass and metal than I can imagine, run by dedicated teams monitoring 24x7 at the hardware and virtual infrastructure layer.

- I have a web portal that allows me to, oh gosh, "START" and "STOP" and "REBOOT" Windows Servers. Degree of difficulty about that of learning how to check out books at your library.

- I have cheap and cheerful ways of connecting those cloud images to my data center as if they were just another LAN, using common industry equipment that my network admins use every day.

- At this point, (without learning anything about the almost immediate ROI I get out of quite simple yet powerful offerings from the likes of CohesiveFT, RightScale or Enstratus), I have Windows Servers up and running in the cloud but behaving as if "on my network", ready to use whatever automation, monitoring, naming, identity, authentication that I use in my datacenter today.

Where was the re-learning in that?

Re-learning, Re-training, Re-Doing means RE-SPENDING!!!
Do
not
do
that.

Are there things to learn? Of course there are. Cloud automation solutions for image automation, topology automation, network virtualization, backup, recovery, IDS, etc. are all available at TOPOLOGY PRICING not enterprise pricing.

This is super. Migrate. Evolve. Learn (not re-learn). Get quick ROI on simple, clear and immediate wins. Scale as appropriate over the next decade.

You are in the midst of the largest IT migration since the Y2k, but there is no forced end date.

From early 2007 to today, cloud quality and reliability has skyrocketed, prices have dropped, vendors have shaken out, investment has grown, 10s of thousands of successes have been had. This path and pace will continue and you get to decide what to move, and when.

The hoopla of "Infrastructure as a Service" (the part of Cloud CohesiveFT focuses on) is deserved:

- improved time to market
- improved automation
- ROI at the application level
- incremental value
- etc..

But at the end of the day these are x86 computers that we collectively install software on and run. Broadly the same, whilst rewardingly different in subtle, incremental ways.

Please try to learn that first.

(Cheers - Pat K)

VPN-Cubed® vpcPLUS Available Today

Just a quick note, we don't want to steal any of our partner's thunder.

The long awaited update to Amazon Web Services™ Virtual Private Cloud (VPC) beta is finally here. The update opens up the once closed and limited VPC offering to include such features as public access to VPC deployments, control of network ACLs, use of Elastic IPs inside VPC deployments, and controllable connections to S3. All these things make the VPC offering more valuable to users looking to do more with the offering than was previously possible. We applaud AWS for moving forward to offer their customers more connectivity options at the virtualization layer (see Welcome to the User-Cloud Part 1 and Part 2).

As an innovator in the cloud network and connectivity market we have collaborated with many cloud providers on how best to provide networking options to their users. Through our partnership with AWS, we have developed a unique Edition of our VPN-Cubed Virtual Networking Product specifically designed for use with the new VPC offering. We call it VPN-Cubed vpcPLUS. VPN-Cubed vpcPLUS was developed to address the lingering issue that public clouds are 3rd party controlled environments. No matter how many control and security features cloud providers make available to their user base, the virtual workloads are still running in 3rd party network environments (to which the customer has no insight, visibility or control). Since its launch in 2008 VPN-Cubed has been providing our enterprise customers with unmatched cloud networking security and control. By working with AWS to create our vpcPLUS Edition, enterprise users can migrate to the cloud with confidence and control. Check out our VPN-Cubed vpcPLUS page for more information on the use-cases or contact sales to move forward with your vpcPLUS deployment.

teamwork.

Good for the goose? Apparently not the gander.

I think the following is true; although I hope it is not true long run.

If I am using VMware vSphere I use a programmatic API for integration; the vSphere SDK.

If I am a vCloud customer, I use a programmatic API for integration; the vCloud API.*

Why so different? One thing that has been posted on the API forum at VMware Communities says, "we have built them for different uses and contracts."

As a user of cloud infrastructure - whether public or private - why would that matter to the provider of the virtual infra software? Why does VMware think I am so different when I am a customer of my internal IT department than if a customer of a vCloud provider?

One simple answer would be, "we created vCloud concepts after the core ESX stuff - and haven't integrated the code or the concepts yet, but yeah, kind of 'blech' that we haven't yet". I would be good with that, software is hard, and time and constraints are always a killer.

But the answer above doesn't say that, it says as an enterprise IT user of private cloud I have dramatically different needs than an enterprise user of a public cloud.

Maybe the confusion is "who is the customer"? I think it could be that VMware doesn't recognize enterprises as "multi-tenant" environments, basically the same as if it was a vCloud provider. Their customer is the virtual infra provider, whether the enterprise IT Operations Manager or the MSP/Co-lo/Hosting provider Operations Manager. In the former case, users of virtual infra are invisible to VMware, with an orientation that internal, centralized IT still gets to be in charge of everything. In the latter, they have to provide capabilities to me the vCloud provider's customer, otherwise the vCloud won't get used.

I wrote about this in "Welcome to the User-Cloud" - where I raised the issue of the need for separation of concerns between the needs of the virtual infra provider and the virtual infra user.

So, in short summary, I am not being critical. I really am wondering why such a difference is perceived and expressed in the VMware product lines? Would love to hear what others think.





(* The fact that there may not be a vCloud provider that has fully implemented the vCloud 1.0 API yet is a different issue, and one for another day. If anyone knows of a vCloud provider with full 1.0 API support please give me a tweet @pjktech and I will correct/update here.)

- Pat K

Oh Hello VPN-Cubed 2.0

VPN-Cubed 2.0 has arrived. Why 2.0? This release is a direct result of over two years of interaction with our customers understanding the specific requirements of use-cases from various industry verticals and geographies. VPN-Cubed 2.0 represents a major step forward adding functionality like the new Manager Firewall and API compatibility (more on those later).

As Pat outlined in his User Cloud posts (Part 1 | Part 2), cloud computing (of course I'm talking IaaS), is a multi-layer environment with distinct separation of concerns between the physical providers, virtual providers, and the cloud users. VPN-Cubed focuses on the cloud user or cloud tenant. The model for traditional network devices is the big metal boxes we have worked with all these years. On the flip side, virtual networking, driven by the needs of enterprise application topologies, is a new use-case and implementing it takes some real lateral thinking. Virtual networks can be anywhere, anytime and they provide critical control functions for enterprises in the increasingly agile and often anonymous world of virtual/cloud infrastructure. VPN-Cubed 2.0 is the enterprise-ready networking solution for the User Cloud.

What's new in 2.0?
Below are some of the user experience improvements in this release. We have also updated the IPsec subsystem in the Datacenter Connect Editions.

Manager Firewall

We have added firewall capabilities at the Manager level to control traffic into and out of the VPN-Cubed Overlay Network. This adds an additional layer of security and control to your cloud deployments. The Manager Firewall is controlled via the Manager UI using IPTables syntax.

Manager API

The API provides programmatic access to the Manager and the overlay network. Configuration steps previously done via the Manager UI can now be performed via the command line or by script. See the Scriptable Overlay Networks post for more information on how the API can work with Context-Cubed.

The API tool can be downloaded (ZIP | TAR) on the VPN-Cubed Edition pages along with documentation (Cloud Only | Datacenter Connect).

Increased Access to Logs

Links to the logs is now provided via the UI making it easier for users to perform required monitoring and maintenance.

External Ping

Datacenter Connect Editions now come with an External Ping capability for configurations where a nearly permanent IPsec tunnel is required. The External Ping function sets up a continuous ping from the Manager to a destination behind the datacenter-based extranet device. The ping serves to keep the tunnel up by continually sending tunnel traffic.

Topology Naming

Many of our customers have complex deployments with multiple Managers and multiple overlay networks. Topology naming allows alpha numeric naming of individual topologies and Managers displayed on the Manager UI.

All new features are explained in the updated configuration documentation available for download in each Edition's launch instructions section on the website. Visit the VPN-Cubed homepage to see which Edition is right for your use-case.

Welcome to the User-Cloud (Part 2)

Disclaimer: I am talking about IaaS when I use the term "cloud" in this post.

A quick recap from Part 1 where I was outlining what I see as:

The new "separation of concerns"

If you think about it, when you are using a public cloud like Amazon Web Services (AWS) – the team of people running the physical infrastructure have no direct interaction with your application topology; and you don't want them to.

The teams of people running your virtual infrastructure at AWS have ALMOST no interaction with your application topology; and you don't want them to. They see your topology from “below”, they see a clump of x86 VM workloads, and have no knowledge of the semantics of your application topology, and in fact shouldn't.

You, in the user-cloud, know the semantics of your application, you know how it scales, you know where it came from, where it is going, and whether it can migrate from region to region or country to country. And to date you have used either your own self-developed knowledge of EC2, private Eucalyptus, Terremark, etc.., or you used Rightscale or CohesiveFT, or one of the other tooling sets that fit in the category Gartner calls “Cloud Management Platform”.

I believe this is an industry wide trend, and basically creates a new “separation of concerns” in how IT functionality is provided both by vendors and IT staffs, and how IT functionality is consumed (pictured below).

But this gives rise to the question....

Where should my virtual infrastructure and its providers fit in?

We know that a Public Cloud as my underlying physical infra provider cannot take any specific knowledgeful action on my applications, nor do I want them to. It is the same with Public Cloud companies in the role as my virtual infrastructure provider, other than a nominal number of very narrow geographic recovery actions.

What about in my Private Cloud? Today the Private Cloud (agile virtual infrastructures running in my own datacenters or co-lo centers) is often mimicking existing centralized IT behaviors. In this model, a line of business (LOB) or application owner has to go “hat in hand” to centralized IT to make deployments happen.

I would argue this is an evolutionary artifact which will succumb in the face of Enterprise IT successfully evolving into comprehensive virtual infra providers. Imagine if you will, the “private cloud pixies” come overnight and magically transform all of your available x86 hardware stock into one global, integrated/federated, api-driven, virtualized fabric. All of a sudden you would realize how the "frozen chunks of metal" in your physical layer (servers, storage arrays, routers, switches, etc.) had come to define the structure of your business, your control mechanisms, and your attempts at knowledgeful centralization of the application layers. As these devices become only a conveyance for virtualized compute, virtualized storage and virtualized networking – instantly the application layer accelerates to a speed and fluidity that provides poor grasp for IT staff and even less tractable control for an ISV infrastructure that perceives reality from below.

Application owners, managing from “above” know their application, its topology and are best able to deploy it to some set of described resources. These described resources (available VM slots at the simplest) probably are detailed with respect to computer power, memory availability, geography if not legal jurisdiction, storage availability, LAN speed, network edge speed, etc..

The IT operations team (which could report to centralized IT or the LOB) which knows the application best, is best positioned to bring agility and satisfaction to the application owners.

This is the next battleground for the hearts and minds of the buyers of virtual infrastructure in the enterprise. On one hand, public cloud vendors viscerally perceive the new separation of concerns. They do not want their physical infra or virtual infra staff concerned with the discrete details of any one customer's application workload.

Yet, the private cloud vendors and the incumbent virtual infrastructure providers (centralized Enterprise IT) are aligned in wanting to manage the application topology (and accordingly the Line of Business) from the middle as it were. For the IT team running the virtual infrastructure – they are avoiding “giving up” of something they fear to give up. For the virtual infra ISV, they avoid having to find and negotiate with a new buyer. They avoid having to engineer products from the top, that can integrate with their products from the middle.

This picture shows the current trend. Virtual infra providers bringing to market feature sets from the middle (as pictured vDog, vCat and vMagic) putatively to meet the needs of the user-cloud, the cloud tenants.

I don't like this approach. Perhaps, in a self serving sense, I am against this because it means more competition for CFT and others in the Gartner-dubbed "Cloud Management Platform space". But it is more than that. It is a violation of the new and powerful separation of concerns which is playing out quite nicely in AWS / Public Cloud space today and should have its chance in the private cloud space as well.

I am not against the virtual infra ISVs coming up with products for the user-cloud. I am happy for them to deliver a line of “u” products (user-cloud products); uDog, uCat and uMagic that use the public, published APIs of their “v” product counterparts.

What are examples of good "vDogs" or "uDog" counterparts? For one I would say Amazon's SimpleDB. It is a platform service provided from the middle, owned, operated and controlled from the middle - and can be used by application creators to create their own user-cloud applications which they can control. From the same vendor comes a good "uDog", Amazon RDS (Relational Database Service). It is provided at the user-cloud level and it is managed and controlled by the application owner. Another good "vDog" is Amazon VPC (virtual private cloud). Again, it is owned and operated in the midldle, powerful, yet comes with lessened customer control just like its database counterpart. Amazon's ecosystem provides the corresponding "uDog", CohesiveFT's VPN-Cubed; owned, operated, and controlled in the user-cloud level. As I said in my previous post, horses for courses (vHorses?). I won''t point out bad vDogs and vCats here - but they are out there and I recommend thinking through their usage and their violation of the operational planes of control public and private cloud is now affording us.

When we give the cloud application owners control from above, and virtual infrastructure providers stick to managing at the workload level from below, I believe it encourages innovation in enterprise IT organization, innovation in features and functions for managing application topologies, and better interoperability and integration between cloud vendors; whether from the virtual infra or user-cloud perspective.

If we take advantage of the new separation of concerns being afforded us by the emergence of three distinct planes of operational control; physical, virtual and user, then I think we have a chance of maximizing enterprise agility and ROI as they engage in the world of public, private and hybrid cloud infrastructures.

If you are looking for me, you will find me with the rest of the CFT team, in the user-cloud.