“We don’t want VM’s anymore”

Had a very interesting meeting with a fast-moving customer about one of their critical software platform. The project lead was very clear off the top: “We don’t want VM’s anymore. First we try to find SaaS solutions so we just use the software. When we need something more custom and/or we’re writing code, we want PaaS. Only as a last recourse we’ll consider IaaS”.

First, I would describe this as a very mature cloud approach (as you can see the option of running anything in-house doesn’t even make the list…). In general, I think this approach makes a lot of sense.

Still, there are a few specific elements to keep in mind. For example, the main benefits from PaaS are that you don’t have to worry about the underlying infrastructure. For dev/test and rapid prototyping, that makes sense. However in many cases for larger scale deployments you *want* to worry about the underlying infrastructure. Many production environments rely on a significant number of customizations that are simply not available through the default platforms.

In addition, additional and critical elements such as CDN, load balancing and auto-scaling may not be sufficient to answer your needs may not be included in the platform (or only in very basic form).

As always, you should define your needs and requirements as much as possible, and then experiment with the deployment models to ensure your choice lines up with your business priorities.


Cloud vs. Cloud – the state of definitions in 2015

When I started in the cloud industry over three years ago, I was first surprised to see that many conference presentations started with a cloud definition. I guess the terms were reasonably new and it made sense for everyone to take a minute or two to validate expectations (by contrast, those who didn’t share a brief definition often proceeded to confirm that they had no idea what they were talking about!).

“Back in those days”, a number of thoughts leaders reverted back to the NIST “5-legged stool” definition (still available online today as a PDF). To be able to claim the term “cloud”, you needed to have five key characteristics:

  1. On-demand Self-Service
  2. Broad Network Access
  3. Resource Pooling
  4. Rapid Elasticity
  5. Measured Service

Move forward to 2015, and the issue is not so much that people don’t know what cloud is, but more that everyone thinks (and says) they have a cloud. So perhaps it’s time to update the five legs, for greater clarity.

Before we get into it, let’s put aside the SaaS models – although all vendors of hosted applications and/or storage now use the term “cloud”, at least everyone generally understands that we’re talking about software (gmail, salesforce.com, freshbooks, xero, basecamp are examples of popular tools to manage your business, all offered in pay-as-you-go models). [still, it continues to be frustrating to work with some of the leaders, such as salesforce.com, who now require one- to three-year agreements, removing any pay-for-what-you-need benefits…].

The confusing definitions (and claims) are much wilder on the infrastructure and hosting side, with everyone and their uncle claiming they now have a cloud – with various designations of “public”, “enterprise” and “secure” thrown in for good measure.

So here are the five redefined criteria – put them to the test as you select your next cloud vendor. For each category I list a few sample questions you can ask and/or warning signs.

Five essential characteristics of cloud, 2015:

  1. Self-Service
  2. Micro-allocation and billing
  3. API-driven
  4. Hypervisor-agnostic
  5. Multi-services

1. Self-Service

This element is as important today as it was in the original definition. Recent studies have shown that although cloud is sometimes explored first for cost-reduction reasons, business agility is the reason why organizations continue to move to cloud services. Agile teams from fast-moving and innovating groups, such as software development and marketing, need instant access to infrastructure resources to test, iterate, innovate and maximize business value while reducing the cost of development.

The first “acid test” is the good old server provisioning question: can a developer launch their own virtual instance (and services) in minutes?

Any solution that requires IT to control resource allocation is not worthy of the name. That doesn’t mean it needs to be a free-for-all. IT needs to redefine its role from “managing servers to managing services” – it can set templates, define service catalogs, set quotas, but self-service is a must.

2. Micro-allocation and billing

An other important difference between cloud and hosting is the level of granularity of the billing, along with your ability to stop and start using the service at any point.

In a cloud environment, you typically pay by the hour, with an ability to stop and start services as you need. Some examples are business specific (for example seasonal e-commerce sales or batch processing) but others are more universal – for example many software firms automatically turn off development, test and QA environments at night and on week-ends to save on costs.

Test: if you are billed in monthly increments of service, you are missing on a significant portion of the cloud value (of course, clouds will only “invoice” you monthly, but for the total of hourly-consumed services).


Application Programmers Interfaces (APIs) are calls you can make to a software application with specific instructions on what tasks to perform. Since cloud provides that layer of software on top of the infrastructure, it’s now possible to communicate with your infrastructure directly through an API call. For developers, this is a very natural way to work and communicate with systems – this now means they can interact with their infrastructure in a very comfortable and efficient way.

APIs can be used in many ways. Simple status updates can be obtained by querying the API. More advanced functions can include auto-scaling (the automatic provisioning of new services when certain metrics are met) and fault-protection (actions to take when certain events are triggered).

So ask the question: can I interact with my cloud services through an API?

4. Hypervisor-agnostic

It is generally understood that cloud is really about abstracting virtual services to another layer, to enable for automation and orchestration. This is the same phenomenon that happened over 10 years ago when virtualization was launched. Before virtualization, most software would run directly on bare metal servers. IBM, Dell and HP were key players in building your IT infrastructure, and making decent margins. Vmware, as one of the early leaders, enabled customers to run software on a virtual layer, abstracting the hardware. Effectively, you were now focusing on running your applications on Vmware, and the name on the box mattered a whole lot less (which enabled Vmware to capture great margins, while the pure hardware vendors saw a lot more commoditization and margin pressure).

The same thing is happening today. “cloud” is a software layer that abstracts the hypervisor to a higher level. What’s important for you is that you can launch Linux or Windows instances. As in the virtualization example, in the cloud era the cloud software becomes the key differentiator, and the hypervisor gets buried to a lower layer.

Test your vendor: if your vendor is naming a particular hypervisor in their offer (e.g. a “Vmware cloud”, a “Hyper-V” cloud) then you are still looking at some form of hosting, and are limiting any additional automation or orchestration from a cloud layer.

5. Multi-services

Last but not least, cloud is about a lot more than instances. For example, leading cloud provider has over 40 different service offerings, of which “virtual machines” is only one – Elastic Cloud Compute, or EC2. Other services include storage options such as object storage, database-as-a-service, and a number of scripting and automation platforms.

Ask the question: in addition to virtual instances, what other cloud services do you offer?

So here your have it – the new five criteria for cloud services, with key questions to have. Happy shopping.

The focus is on Agility at the AWS NYC Summit

Hundreds gathered at the Javits Convention Center for the New York stop of the AWS Summit Series. This series of 27 global events supplements the AWS Re:Invent annual conference in November. It’s worth noting distribution of events: of the 27, only three are in North America, while there are 10 stops in South America and seven in both Europe and Asia/Pacific.

Werner Vogels, CTO and chief technology officer and Vice President of Amazon.com, summarized the theme of the day in this quote: “Agility is the key word in all of this. Everything that was hardware is programmable. There is no hardware anymore.”

Of course, there is still hardware (and lots of it, given AWS’s lead in the market). But AWS continues to release new innovations to facilitate the development of new software. The company used to event to make the following announcements:

AWS API gateway: a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure REST APIs at scale.

AWS Device Farm: an AWS service which lets you test your application on a wide selection of FireOS and Android devices, all through a programmable AWS service. Developers can upload their code and run it against real devices and receive a report with errors and/or issues in minutes.

AWS Code Pipeline: Announced at the 2014 Re:Invent, Code Pipeline’s general availability was announced at the NYC Summit. Code Pipeline lets developers automate the building process and testing of their code every time there is a change, enabling continuous delivery.

AWS Code Commit: A Git-compatible code repository, provided as a fully-managed service. Also announced at the 2014 Re:Invent conference and now made generally available.

AWS Service Catalog: Perhaps on a slightly different theme than the other announcements, AWS Service Catalog is more targeted for the large enterprise. This market segment is experimenting with the cloud but is also looking for ways to have some level of governance on what is deployed in their AWS environments. Service Catalog helps IT groups list available services, and enables users to quickly deployed approved solutions.

The event also showcased customer success stories including Nordstrom, NYC Department of Transportation, Oscar Insurance.

Highlights of the summit as well as the full recording of the AWS NYC summit can be found on the AWS YouTube Channel.