About a month ago, I had the opportunity to sit in on a presentation discussing Cisco’s MetaPod product. As a fan of Platform9’s OpenStack-as-a-Service approach, I was curious to see Cisco’s approach.

Stuff-as-a-Service

I like stuff as a service, especially when the stuff is hard to do yourself. The value add for a company to do Stuff-as-a-Service is their extensive knowledge about the stuff. They can automate it, make it self-healing (from at least a service perspective, but maybe even from a technology standpoint too) and do really specific monitoring (which requires all that expertise to figure out in the first place). It also means the provider can make educated decisions on release lag, upgrade procedure and installation process.

The MetaPod product comes from the MetaCloud acquisition in 2014, a then 3 year old company, and is a tool to build private OpenStack clouds on top of Cisco UCS gear. It’s a public cloud experience behind your firewall, as Cisco puts it.

The first thing that catches my attention: it is yet another ‘hosted’ OpenStack provider. Like Platform9 (and others), MetaPod puts a service wrap around complex technology while still leveraging physical a company’s ‘own’ hardware (either in own datacenters or remote co-location facilities).

Enterprisy approach

screen-shot-2016-10-23-at-13-31-26

Cisco’s MetaPod takes a enterprisy approach, though. It’s not SaaS, i.e. it’s not hosted by Cisco. What is it, is a complete solution (hardware + software) deployed on-prem. The included hardware is for the management plane only.

The management plane is covered by an SLA (basically 99,99% for the OpenStack APIs and dashboards), and only if all of the environment is specced the way Cisco likes it (via the prescriptive design), does the SLA apply.
Although you can bring your own compute, networking and storage, customers are severely limited in deployment options and architecture decisions due to the strict SLA requirements.

Metapod release cycles are about 1 year behind regular OpenStack release cycles. For a managed service company, I think 1 year is pretty long. If I’m buying it as a service, I don’t want all the traditional enterprise downsides like n-1 versioning, rigid ITIL change management processes, etc.Didn’t I outsource it for just these reasons?

Key Architecture Points

In the prescriptive design there’s a couple of interesting points.
Most importantly: lots of Cisco gear. I don’t like this forced architecture for financial reasons. There’s a ‘provider network’ option (bring-your-own network when deploying, removing the network and storage from the SLA.

screen-shot-2016-10-23-at-14-03-36

Control plane is a 3-node HA setup for running the OpenStack services running on UCS C-220 blades.
Networking uses standard ASR 1000 and Nexus 9000 components.
Storage external SAN arrays are optional. Standard storage is provided by CEPH. Ain’t that cool?

Editions

As far as scalability goes, there’s three sizes available: Starter, General Purpose, High Performance. Mind you, these are aimed at the control cluster, not the compute or storage nodes.

screen-shot-2016-10-23-at-14-15-27

Making sense of this SaaS

So, MetaPod is like the vBlock for OpenStack solutions. Totally enterprisy, CFO’s like to buy this. Matches ITIL mindset, has an SLA and integrates easily into all things enterprises find important: compliance, security, data governance, ownership, control.
It’s highly available on-prem OpenStack, as a Service.

As @jpwarren put it: It’s broken and wrong, but it’ll sell, and I agree. It’s a fantastically positioned solution for enterprises that struggle with deploying OpenStack because their developers need it (because why else would you need OpenStack).