Supersize your Amazon EC2 Assemblies

The New Feature Announcement department is bursting with news about our support for Amazon EC2 large, extra large, and high-CPU instances. As part of our Community Edition, we've historically supported Amazon's small instance which works for many apps. But what if you've developed a cloud-destined, compute-intensive app that's ready to deploy to production? You likely need more memory, more storage and double the bits. Elastic Server now delivers.

Below is a quick refresher on the differences between Amazon's S, L, XL and various high CPU instances. For full details, visit the official Amazon Elastic Compute Cloud page.

• Small Instance - 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform
  
  
• Large Instance - 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform
  
  
• Extra Large Instance - 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform
  
  
• High-CPU Medium Instance - 1.7 GB of memory, 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each), 350 GB of instance storage, 32-bit platform
  
  
• High-CPU Extra Large Instance - 7 GB of memory, 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform

Because we're so excited to see what our 1,000+ community members will build, this feature -- part of our Personal Edition -- is on pay holiday for all of you Community members.
Upgrade your Community Account to the Personal Edition and enjoy this feature for the low, low price of zero. Remember: we don't just manage your servers, we help you build them from zero to virtual, so start assembling now!

TIP: Working on a project that involves more than just you? Don't forget that you can securely share your Amazon EC2 credentials with your team. As with most disclaimers following any announcement, we welcome your feedback about anything that goes bump in the code. Happy building!

Amazon Elastic Compute Cloud (Amazon EC2) is a trademark of Amazon.com, Inc. or its affiliates in the United States and/or other countries. This font is small.

New features help you organize your packages and bundles

Last week our trusty corps of engineers deployed a few new features to the Elastic Server platform. Before we dive into the details, let's take advantage of that back-to-school spirit and quickly review a few terms specific to the way we name things around here.

• Package: At the basic level, a package is the smallest component that we support for installation of applications onto an Elastic Server. This could be a single file or a set of files archived together (e.g. A Red Hat RPM or a Debian DEB file are both packages).
  
  
• Bundle: Since most people will want to have a set of packages rather than a single one, we use the term bundle to describe a collection of packages grouped together to form a single set that can be added to Elastic Server Sites and assembled into Elastic Servers. Also, bundles can be grabbed ala carte using the Bundle Explorer for assembly into an Elastic Server.
  
  
• BYO: "Bring Your Own" (BYO) allows users to upload their desired component package and bundle it in the Elastic Server Component Library for inclusion in Elastic Servers.

The latest release includes the following features:

• The ability to group versions in bundle explorer and package bundles by component. This allows for easier selection of packages and bundles because all the versions are grouped together.
  
  
• Packages are now visible in vm details. You can now see exactly which packages went into your server at a glance.
  
  
• Initial revision of tagging on BYO screen. Organize your package workspace by tagging packages in groups.

Looking to build some servers and deploy them to the cloud or a virtual machine, like now? Get started at Elastic Server.

Build on, server gurus!

Cloud Monoculture or Balanced VM Portfolio?

I know. Quite a mixed metaphor in the title of this post. That said, both economic and genetic metaphors apply in how Enterprises or Cloud Providers might react to the VMware "August 12th surprise". To those who may not have heard - the latest versions of VMware's ESX hypervisor started shutting down as the hypervisor clock hit the date of August 12th. This was due to what amounts to a hardcoded shutdown being left in the server from its evaluation days.

Clearly if you are an enterprise dutifully "up to patch" this would have put a big hurt on your operation, IF virtualization was more ubiquitous in the production data center. The fact is enterprise data centers don't have a lot of mission critical virtual machines in production - yet!

I am not kicking VMware - these things happen. But what if that had been a large-scale Cloud Provider? By definition, virtualization is 100% ubiquitous in virtualization-based clouds.

We know it is a heterogeneous world, and customers are in charge, which is why we are busily connecting our Elastic Server platform to some of the newly announced clouds. We want our users have a choice of deployment locations. And we want cloud users to have access to dynamically assembled virtual servers, instead of using quickly-stale templates. Given the early stage of this industry, each of these clouds is currently "monocultural." They use a specific version of a specific hypervisor - and require a virtual machine in that format (plus "fiddly bits", a frequently used technical term in our office). For example, Amazon EC2 takes an open source Xen image + Amazon fiddly bits. We are working with other clouds that take VMware + Fiddly Bits and Virtual Iron + Fiddly Bits.

Some clouds like Google App Engine and Heroku are "language module" clouds where the deployment vehicle is a package of code for Python/Django or Ruby on Rails and may have less of an issue in this instance. But, the clouds that take x86 containers as their deployment package don't really have to be monoculture clouds in the longer run. We could let customers decide if they want to provide virtual machines formatted for Parallels, or open source Xen, or Citrix Xen, or VMware, etc.. The cloud vendor would need a layer of traditional datacenter automation software to handle booting up physical hardware with the appropriate hypervisors to meet virtual machine demand. If customers are collectively driving single hypervisor behavior - offer discounts for other VM types to create a portfolio of hypervisors and VM types in the cloud.

Creating VM templates for customers to use in one VM format is painful enough. Supporting more hypervisors for more templates is even worse. Because of this and our belief that "like it or not, there will always be more of everything" - we built the Elastic Server platform to support all forms of hypervisors, OS's, middleware, and management environments; making it a great way for clouds and cloud users to be able to "re-manufacture" their virtual computers quickly for deployment to different formats and different clouds.

The reality is - just like with operating systems - no enterprise will have just one hypervisor type. As soon as you migrate everything to Hypervisor X, your company will buy a company that uses Hypervisor Y, or you will be bought by a company using Hypervisor Z. Should clouds, in the long run, do any less?

In the short run - this begs the need for x-cloud virtual machine assembly, x-cloud deployment tools, and x-cloud base level management tools, as well as x-cloud security frameworks so you can diversify your computing portfolio by running your virtual server clusters across multiple clouds.

Meanwhile, fingers crossed my pet Cheetah doesn't catch a cold.

Every which way but loosely coupled

One of the most appealing aspects of self-service 'retail' style clouds such as Amazon EC2 and Flexiscale, is that they simplify the process of deploying 'software as a service' applications and web applications generally. The Amazon guys frequently cite Animoto as a case study - without any capital investment and without paying consultants, the tiny Seattle-based Animoto team were able to launch, and grow to a substantial paying user base, in a very short time.

By the opposite token, IBM have quite recently announced more cloud initiatives. More precisely they have announced some data center outsourcing plans and consulting services offerings, and labelled them 'cloud'. Take a look.

This is very carefully worded press release. Look at how many times 'cloud' is mentioned in this press release without saying that there actually is a cloud. Here are some examples:

1. "cloud computing capabilities" - ie. it is capable of being a cloud but may not be one
   
2. "cloud-like computing mode" - cloud-like but not a cloud
3. "capable of supporting cloud environments" - but is not actually a cloud
   
4. "cloud computing center in Tokyo, Japan will provide large enterprise customers, universities and government agencies immediate access to experts who can help them deploy cloud computing environments" - buy expertise, i.e. time and materials, then buy more people who install some software
   
5. "Cloud computing gives organizations the opportunity to remotely access a vast network of computers" - a general statement
   
6. "cloud center will be linked to the new Raleigh center and IBM's seven other cloud centers throughout the world, to help clients pilot cloud infrastructures" - pilot but don't use
7. "IBM offers a number of solutions to help clients deliver cloud-enabled services to their customers -- an initiative dubbed Blue Cloud" - not sure who is selling what to who here but it sounds like consultants are involved
   

And so on and so forth. Now I realise that IBM have good reason to embrace 'cloud' by extending their data center outsourcing and global services businesses. And, I fully appreciate that IBM might like their enterprise customers to feel that piloting cloud-like deployments in safe IBM data centers, some time in 2009, is the way to reduce risk. After all, IBM are all about reducing risk, right?

I also applaud IBM's stance on development of geographies possibly not yet so well addressed by cloud, hosting, data center management, and outsourcing services. And similarly I am impressed with statements about energy reduction and cost efficiency, and I look forward to one day seeing their green API. Because the more green tape there is, the more attractive it will be to use a certified carbon neutral data center, rather than build your own.

But what I don't understand is why they keep talking about the future, when self-service clouds exist today that do not require "a set of hardware, software and services that allows IBM clients to offer personal and business services from remote, centralized servers". And more are appearing.

Yes, by all means create a market for 'solutions' around cloud vs non-cloud vs private cloud deployments. Yes, go ahead and sell professional services for migrating applications into service-oriented, distributed, and virtualized, infrastructure.

But blue as it may be, in what way is this 'cloud'? It's not 'on demand' if I cannot do it myself. Surely the whole point of the cloud is disintermediation - the Animoto on EC2 use case did not require the interposition of experts, risk managers, hardware sales, or software installation. Large enterprise customers will of course have more complicated needs than Animoto, but enterprises still want the fundamental benefits of cloud - pay for what you need, and reduce resource when you do not need it. Less is more. Loosen up.

Win Win for Independent Software Vendors

Hi, I’m Chris Purrington. Not so long ago I was with Borland where I spent 5 years as UK Managing Director. Borland has a great heritage and a history of great products, you may know it in it’s current guise as the “Open ALM” company.

However, I saw it then and I see it now, regardless of whose tools are being used or how good they are, many customers are still frustrated that end-to-end the Software Development Life Cycle (SDLC) is still like an assault course, and very difficult for organisations to traverse. Communication barriers between roles throughout the lifecycle are still an issue today despite many ISVs looking to ease this pain.

So what? Well, I am very excited by CohesiveFT’s Elastic Server because I can see it changing the way organisations tackle the traditional challenges of the SDLC. Fitting in alongside many other ALM tools working within existing processes, Elastic Server will deliver significant speed, quality, and cost benefits across all roles throughout the SDLC, acting as the glue in the hand-offs between functions. And - add to this many positive Elastic Server by-products: better reuse of code components and patterns, reduction of operational risk, improved knowledge retention, higher staff morale, etc, etc

BTW you can start using Elastic Server today and unlike it’s imitators it’s free!

More details will come in future postings on SDLC (or drop me an email if you can’t wait), but today I want to focus on added value for Independent Software Vendors (ISVs).

For ISVs there’s a Double Win

ISVs come in all shapes and sizes, and all can benefit from Elastic Sever. I think the 'wins' are not just in Product Delivery and Data Centre Operations but also in the "sales cycle". ISVs can transform their whole pre-sales solution validation or Proof of Concept process, accelerating their sales success.

Wider, Shorter, Larger and more efficient!

That’s the sort of sales pipeline I like. Elastic Server allows you to widen your pipeline funnel, shorten your sales cycle and close more deals.Your pipeline can go ELASTIC SEVER increases awareness, and makes solutions intuitive

Ideally, enterprises customers would come to you after they know how to make best use of your product. But enterprise solutions have many capabilities, resulting in many use cases. Showing off all the relevant capabilities on offer to the appropriate people, can be a real challenge. Elastic Server makes it easy to create your own ”component portals”, each displaying representative use cases; use cases the customer can assemble and deploy at the click of a button.

Elastic Server allows you to easily create, save and make available (through your own micro portals) tailored instances of your solution. These are saved as templates and reused to create Elastic Sever versions of your solution whenever they are required. These Elastic Servers are custom application stacks, built from your solutions components, virtualization-ready, which means: ready to download or deploy to a cloud. So you can make as many instances as you need tailored or not, available on demand.

Your templates can be vanilla, or industry solution specific, or tailored to individual prospects. They can be easily reused, displayed, demoed and evaluated. Within your portals you can easily add your own branding, diagrams, and notes, effectively ‘white-labelling’ them, making your tailored micro portal more relevant to your prospect, more accessible and easier to follow.

Take a look at our example industry portal Universal Bank.


Of course you also have the option to make your portals public through the CohesiveFT Community site, sharing your solutions with our community (see the Mule Source case study below)

Struggling with lengthy Proof Of Concepts?

From my Borland days I recall often just doing a POC required long procurement cycles and getting executive sign-off. If your POCs need several days or weeks of your prospect’s architect, developer and data centre resources with a dedicated machine, then getting budget approval for a POC can be just as difficult as getting approval for a $50k, or $500k purchase.

With Elastic Server and clouds such as Amazon EC2 or Flexiscale you can shrink this whole process to just one day, and no machine resources are required! So your sponsor doesn’t need to go to the board or investment committee before they get a chance to prove the value of your solution. You can remove key barriers so your sales force can kick-off more POCs, faster.

A typical scenario of days or weeks to set up an enterprise POC, and having limited resource available can result in delays. In these situations it is easy for everything and everyone, to lose momentum. Imagine instead your pre-sales team selecting a template system that matches the prospects needs, then spending minutes personalising it for them, so within hours of agreeing to the POC you can email your prospect a link where they will find their trial system running. How impressive is that? Ease of implementation - score 100%. Efficiency: score 100%. However busy your sales force gets, your POC capacity can keep up. Your competition won't stand a chance ;-)

And if your prospects want to run the POC in-house on their machines then you have the option to rebuild to any major virtualisation format from your Elastic Server templates.

You also get more successful POCs and increased conversion rates.

OK – so you’re up and running quickly. Now let's make it business-relevant quickly, your prospects can have their very own private tailored POC micro portal. This lets the combined evaluation team collaborate, share, discuss, plan and improve. Everything the evaluation team needs to be successful is there: easy access to the tailored system, links and information e.g., evaluation criteria and score card, evaluation guides, FAQs, contact info, etc. all in one easy to access place. Blogging issues, solutions, ideas, feedback - the whole combined team can contribute and share. And for once your Account Managers are intimately involved at all key stages, monitoring activity and progress through to successful conclusion.

Check out the Mule Case Study. Our friends at MuleSource have built a public Elastic Sever Portal to show off their ESB solutions and allow prospects to test them in a real life environment.

You can access their portal at http://es.cohesiveft.com/site/mulesource, or follow links from the CohesiveFT.com community or the MuleForge.org sites.

The Mule Elastic Server gives you everything you need to test the Mule ESB and you’re offered additional components that you can test with it. From within their Elastic Server portal you can read about Mule ESB, download any additional capabilities you want to test, select the version you wish to try out, and also add components you might want to try out working with Mule ESB, such as RabbitMQ’s AMQP implementation.

This is an example of a public version of an ISV portal, creating special tailored POC micro portals that are specific and private to just one customer are just a few additional steps beyond this.

Here we are hosting MuleSource’s portal but hosting the portals within your own website is an option.

If you want to find out more please go ahead and try it out at www.elasticserver.com, remember it’s free to use, or email me at chris.purrington-at-cohesiveft.com