Arguably SDN may mean a lot of different things to a lot of different people. If you ask the like of Facebook, Google and academic researchers they will probably tell you that SDN is all about gaining full visibility (and . . . → Read More: VMware wants to be the VMware of Networking]]> There have been a lot of discussions lately about SDN (Software Defined Networking).

Arguably SDN may mean a lot of different things to a lot of different people. If you ask the like of Facebook, Google and academic researchers they will probably tell you that SDN is all about gaining full visibility (and control) on how packets flow on the network.

People and organizations that are closer to the commercial world may tell you that SDN is all about creating an abstraction layer (virtualization anyone?) in the network – from layer 2 all the way to layer 7. That abstraction will allow you to become more agile and flexible in how you define the network and security characteristics for the applications you are deploying. In fact (compute) virtualization can reduce the time to deploy an application from weeks down to minutes. However the network and security attributes of those applications may still require days if not weeks to be provisioned, effectively minimizing the advantage of (compute) virtualization.

I’d like to focus on the latter definition of SDN. And so would the large majority of my readers (as I don’t think I have tons of Google and Facebook engineers reading my blog).

A few weeks ago Cisco’s Lauren Cooney asked a question on twitter on the line of “how would you define SDN?”. I answered that question (half) joking that my definition of SDN is found in the ESX 2.0 manual at page 18. For your convenience this is what I am talking about:

Look at the picture. Read the text. Note ESX 2.0 is a 2006 (circa) product. I still find amazing how this 6 year old thing maps nicely many of the current SDN discussions: separate software defined layer 2 networks connected with virtual firewall instances. How does this sound in the context of VXLAN, vShield Edge and adjacent technologies we are discussing today?

SDN purists may very well argue that this PDF was not including important aspects of SDN such as self-service capabilities and a proper API to access these functionalities. Fair enough. However this was 6 years ago and yet VMware had the foundation of SDN laid out in my humble opinion.

I also hear a lot of discussions about VMware missing credibility in the networking space. While I could say there are some brains in that space with a VMware badge today, I would agree VMware is not a known player there. Similarly a lot of vendors that have a strong networking credibility are missing virtualization credentials.

What I am saying is that, in my opinion, this is a complete new segment of the market and there are two paths to become a known SDN (aka “networking virtualization“) leader. Either you are coming from a networking background or you are coming from a virtualization background.

In other words there are multiple approaches you can use to improve the network experience for customers. Networking vendors can take the concepts VMware implemented for server virtualization and apply them to their domain. Or VMware takes the concepts it has implemented in its domain and apply them to the networking domain. I don’t think that, by the books, the former is the proper way to do things whereas the latter is VMware “invading” another domain.

In conclusion, I don’t know whether VMware is going to be successful in becoming a leader of this new segment of the market that is taking shape as we speak… but I have this strong feeling that VMware wants to be the VMware of networking.

Massimo.

Some of these customers and partners have decided to deploy . . . → Read More: vCloud Director 1.5 Multisite Cloud Considerations]]> In the last few months, among other things, I have been working on the document in subject. Being able to deploy vCloud Director 1.5 across different sites is something our customers and service provider partners have been asking us a lot.

Some of these customers and partners have decided to deploy independent vCloud Director instances in different “sites”, others wanted to get more clarity on how far they could stretch a single vCloud Director instance across multiple “sites”. Of course both approaches present advantages and disadvantages.

In a nutshell, throughout the document, we have tried to clarify and classify different MAN and WAN scenarios based on network connectivity characteristics (namely latency). We have determined, in our vCD parlance, what would constitute a single site deployment (over a MAN) and what would constitute a multisite deployment (over WAN). We have determined 20 ms of latency to be “our” threshold between what we can support and what we cannot support with this specific vCloud Director 1.5 release.

The document gets into a lot more details and scenarios but the two major takeaway are:

• It is not possible to stretch the provider workloads that is the software modules that comprise your VMware vCloud (e.g. vCD cells, vCD database, the NFS share, etc).
• It is possible to have Provider vDCs that are located up to 20 ms (RTT) from the provider workloads.

This picture summarizes one of the supported scenarios:

In the doc we call out and describe more precisely other supported scenarios (such as stretched clusters) and various caveats associated. The following are the scenarios we are taking into account:

It is important to understand that, when we talk about a distributed vCloud environment, we are not necessarily referring to DR of the end-user workloads. This is really about how a Service Provider can allow an end user to spin up workloads in a distributed environment. This doesn’t, necessarily, mean that the SP is responsible for failing over those workloads in the other data centers. If you want to know more about how to build a resilient vCloud architecture you should read this link.

Towards the end of the document we have summarized the supportability statements associated to distributing compute resources in a vCloud setup. In the current version of the doc the summary looks like this:

If you are evaluating a multisite vCloud Director 1.5 deployment you may want to give this document a read. Note that it isn’t published externally on vmware.com but it is available through your VMware representative.

Any question, comment, feedback you may have I’d be interested to hear.

Massimo.

Yes, I do have (strong) opinions about the thing but, regardless, I believe it will happen anyway. . . . → Read More: The Frankencloud]]> For a change, last week on twitter there was a discussion about multi hypervisor deployments. Knowing that, after food and family, multihypervisor is my biggest interest, I was taken and thrown into that discussion. Again. Unfortunately.

Yes, I do have (strong) opinions about the thing but, regardless, I believe it will happen anyway. Read on.

The best way to clarify my position is to distinguish between use cases and scenarios: the typical Private and Public cloud implementations.

Private Cloud Implementations

Let me quote a few customers I have met lately (all true stories, I swear).

• “I will deploy Hyper-V because I was told Microsoft SQL runs faster”

• “I am deploying XenServer because I am using Citrix XenDesktop and I feel more comfortable with an end-to-end stack”

• “I need KVM because I am moving a 32-way Unix partition running SAP and vSphere 4.1 doesn’t support that many” (note: 5.0 does but they haven’t upgraded yet)

• “I need to deploy OracleVM because Oracle won’t support their software on VMware vSphere”

• “We don’t go to central IT, we have our own farm and we have chosen to use a different hypervisor”

• “My strategy is to create different hardware and software silos (this includes hypervisors) for extreme tuning and vertical optimization” (by the way: this reminded me of my AS/400 days).

• “I want to use another hypervisor so that I can put more pressure on VMware at the next ELA renewal”

We can stay here days discussing these things. Except the last one. He was the most candid of all, the least convoluted and, frankly, the only one that REALLY got it. And because he gets it, it doesn’t mean that he’s going to split evenly his production workloads between two hypervisors if you know what I mean. Typical purchase office guerrilla tactics I would say.

Is the world going to be multihypervisor? Well… see above. I would say so. It would be like trying to stop a running train with a finger. I bought this. There are a few things, however, I am not buying into.

What I can’t really buy into is that there is a magic that allows you to assemble those different platforms as if it was one (cloud). Someone tried a similar experiment before and it didn’t work out well. See picture below.

I call this the Frankencloud. I have already touched on this concept in my The ABC of Lock-in post (make sure you read the comments).

What I can’t really buy into is that you do this for efficiency. You are essentially creating distinct, separate, incompatible buckets of compute, storage and network resources. This is either under the management of a single entity (IT) or, as Vanessa Alvarez experienced first hand talking to a customer, by a separate independent business unit:

Imagine the cost associated to replicating every single aspect of the ecosystem that needs to exist around every hypervisor deployment. Take backup for example. Find a single tool that is able to backup homogenously all of your hypervisors of choice, including ESXi, Hyper-V, Xen and KVM. Most likely you will end up with having to deploy (and master!), if not 4, at least 3 tools to accomplish the result.

In the final analysis I can’t really buy that what you are selling me here is… cloud. Sorry about that. Cloud is about simplification by removing overlaps and complexity. What we are doing here, at best, is replicating the technology sprawl that was typical of the eighties and nineties and that led to insane levels of inefficiencies.

As usual, Steve Chambers shared a few words of wisdom on the topic that I captured in a tweet:

Will multihypervisor deployments happen? Yes they will, at the cost of additional complexity, fragmentation and inefficiency. Will vendors continue to sell the illusion of being able to manage multiple hypervisors as if it was one? Of course they will, it is a great check-box to have for RFIs / RFPs! There are a lot of customers out there that want to be “open” but don’t really appreciate what that means (yet). See again my The ABC of Lock-in post.

If you are conscious about the fact that you are going to stand up 2, 3 or 4 separate silos (aka clouds) and you see value in doing that… then I believe you should do it. Go for it. For whatever reason  you have in mind.

If, on the other hand, you still believe in the Frankencloud… then I wish you good luck.

Public Cloud Implementations

The Public Cloud use case is a totally different story.

If you are an Enterprise you are in control. If you are an Enterprise you craft your own strategy. If you are an Enterprise you don’t need to relate your strategy to anything that goes beyond what you actually need as a self-contained organization.

But if you are a Service Provider, your strategy is a function of the strategy of your customers (or prospects). This obviously assumes you believe in hybrid cloud and it also assumes that the market is not going to be 100% VMware.

This isn’t to say that hybrid cloud is the best of all options we have. Pragmatically, this is to say that..

1. if the world was only private then public clouds wouldn’t exist.

2. similarly and obviously an all-public-cloud world isn’t an option (for this century at least).

So what’s left? A mix of both. Hybrid, right.

The only thing I keep hearing from the big SPs is this:

• “I need to have different hypervisors and stacks that will allow me to sell to all flavors of customers out there, regardless of which hypervisor they have chosen”.

Fair enough.

If you are a big name you probably don’t want to limit yourself and you probably want to open your infrastructure regardless of the choice that customers made. In other words I think that customers should standardize on a single hypervisor but this doesn’t mean all customers are going to choose the same hypervisor. Of course there are some SPs that can afford to focus on a single platform because that is possibly going to generate enough business for them and for their model. Especially if that platform is being used by the majority of the Enterprises that could federate with the public cloud offerings. These SPs will trade off the richness of their offering with simplicity of operations.

The net of this, if you are a (big) Service Provider that wants, possibly, to federate with all of customers out there, you have to have a multi-hypervisor strategy. That isn’t an option. Easy.

The discussion then becomes… what do you do with those platforms? Do you make them look like a Frankencloud or do you treat them as separate silos? I’d tend to say the latter but perhaps I should expand more in a future blog post.

Massimo.

In all seriousness it is . . . → Read More: The Cloud Magic Rectangle ™]]> This isn’t the counter argument to Gartner’s Magic Quadrant (I think). Oh, and notice I am not even going into the “this is cloud, this is not cloud” type of discussions. How boring? World peace folks, everything is cloud, even my bike (according to the NIST definition anyway).

In all seriousness it is becoming pretty obvious that the classification we have been using so far isn’t cutting it. IaaS, PaaS and SaaS are obviously required to describe the type of services a given cloud provides but only one dimension won’t cut it. I have seen lately attempts to create this second dimension where analysts introduced the notion of “Enterprise” and “Next Generation” clouds. I am purposely avoiding the abused marketing word “Open” (although many are using it, solely for marketing messages purposes).

I came to the conclusion, after two years of customers meetings, partners engagements, and twitter / blog battles that there are really three buckets that relate to this second dimension. We will, of course, also continue to use the first dimension to create the Magic Rectangle(tm).

I’ll try to be as neutral as possible and I’ll call these buckets: Orchestrated Clouds, Policy-Based Clouds and Design for Fail Clouds.

I am listing three distinct tables that aim at describing the characteristics of these different type of clouds from different perspective. I will say upfront that if I was to write these characteristics again they would very likely be different. As usual, try to depict the forest , don’t look at the individual trees.

Value Proposition and Positioning:

How You (Provider) Build These Clouds:

What You (Consumer) Get with These Clouds:

You can’t bother reading those tables? They don’t make any sense to you? No worries, you are not alone. Pictures are the only thing that (really) explain these stuff:

All this reminds me of a blog post I wrote back in November 2010 where I said (I love to quote myself):

“In conclusion I believe that all this discussion can be summarized in the following (bold) statement: We used to design infrastructures that support applications. We are now developing new applications that support the cloud platforms and these new services contracts and paradigms.”

That is exactly what’s happening. And this is how I see the IT world twisting (admittedly in the very long run):

If you have been in these discussions on twitter you may have noticed that pretty much (almost) everyone agrees on this.  Depending on how fast the world is moving for your organization, you may perceive that these are three parallel options (the world for you is still) or you may perceive a progression from left to right (the world for you is running furiously fast). If you are making a strategic investment in one of the first two columns and, after reading this post, you think that that is not the right thing to do strategically… think carefully. While there are organizations on the third column already (Design for Fail), there are many of them that will get there not sooner than 20 or 30 years. You may very well be one of them. No need to feel ashamed about it.

Note how the model in the middle is the gateway towards this new world (according to the way I see it at least, your mileage may vary).

And now for the Cloud Magic Rectangle(tm), this is how I think products and technologies map to this progression I have just discussed.

There are at least a couple of thousands way to misinterpret the picture above. Let me be clear one on of these: if a product is represented in a given position, it doesn’t assume it won’t move left, right, up or down over time. For example AWS is moving up (quickly), Azure is moving down (with the VM role).

I did put logos on the slides the way I honestly feel they should be placed. I didn’t put those logos where they are just to try to drive a point home. It’s interesting to notice that many of the logos that ended up on the third column represent online services and not software products. I am wondering if this means something and if there is a trend.

Also, looking at the picture I am kind of coming to the conclusion that IaaS may be a great choice to “cloudify legacy workloads”. It seems, from the picture, new workloads may be best positioned to be re-engineered on the PaaS “Design for Fail” layer rather than on the IaaS “Design for Fail” layer. Perhaps that is the reason why AWS is marching north so quickly.

You may assume I am saying this because I am biased as that’s how the VMware products line up on the picture. Fair enough. You can however also assume that VMware gets this right (which is, at least, my hope).

Discuss, if you want.

Massimo.

Multi-hypervisor is a discipline where you can apply the high level ranting below but you can really apply it to pretty much everything in IT.

I started this blog . . . → Read More: The ABC of Lock-In]]> There have been a lot of discussions lately about a topic I find extremely interesting: vendor lock-in.

Multi-hypervisor is a discipline where you can apply the high level ranting below but you can really apply it to pretty much everything in IT.

I started this blog post writing a couple of pages (as usual) and then I thought no one would care to read it (how can I blame you?). So I summarized it in a few pictures. A picture is worth a thousands words. Always.

So the story goes like… you (the customer) start with A and you build or buy an ecosystem of people, tools, knowledge, programs, scripts (yeah A has APIs) and a lot of other things you need to do to fully exploit the value of A.

You (the customer) are happy but then comes vendor C to your door and tells you that you are locked in into A. “It isn’t so easy to move away from it given all the investments you have done” he says. “Imagine if A was to apply a vTax at some point: God forbid!” C goes on. C tells you there is B now which is good and cheap and you can adopt both A and B so you are not locked in into either. “Let C manage them for you transparently” he says. And this is what happens (in theory):

Yeah, all of a sudden you (the customer) find out that (2 years and 2M$ of professional services later) you are… locked in into C. Imagine now if C was to apply a cTax…. God forbid! You would need to move to D which is cheaper and the story goes on and on. What’s your business? Bank transactions? Shoemaker? Doh I thought you wanted the infrastructure to disappear not become your core attention.

If you thought that this was the end of a sad story there is more. Actually it gets a lot worse than this. It turns out that (2 years and 2M$ of professional services later) you can actually only send “heterogenous” alerts (such as <the disk is full>) to operators in the middle of the night and perhaps present a web interface to a user to power on and off a VM on both platform A and B. Oh and did I mention that when A and B delivers a new version of their platforms you need to give C another good 2 years and 2M$ to “adapt it”? Ok now I told you.

You thought this was the end didn’t you? Well not quite, there is even more:

Since you can only send “the disk is full” type of alerts and provision a VM from a portal (which is neither multi-hypervisor management nor IaaS cloud by the way) you have to build another ecosystem for B similar to what you built for A, essentially doubling your past efforts (which is the reasons for which many people argue that a multi-hypervisor strategy is inefficient).

Can it get any worse than this? I can’t think how.. however if it can, it will. Be sure.

Tip1: I have seen these things. First hand. You have full rights to not trust me and think I am biased now though. That’s ok.

Tip2: In the interest of time (I’ve got work to do too) I exaggerated to make a point. Apply your common sense. Look at the forest and not at the tree in this post. I was also having some fun with some of you. You know who you are.

Discuss below if you want. I am running out of time.

Massimo.

Update: reading the comments below I am starting to realize there is a chance this post gets misread and misunderstood. I genuinelly believe there is a difference between “being able to use both A + B as loosely coupled platforms” and “using C to avoid lock-in and managing multiple platforms as one”. This post was meant to say that the former is doable but can be inefficient, while the latter is just a unicorn thing.  More in the discussions underneath.

This topic is (rightly so) coming up a lot lately with the Service Providers (SPs) I am working with so I thought I’d share some high level . . . → Read More: vCD Custom Portals and Backend Integrations in a Service Provider Environment]]> This article was originally posted on the VMware vCloud corporate blog. I am re-posting here for the convenience of the readers of my personal blog.

This topic is (rightly so) coming up a lot lately with the Service Providers (SPs) I am working with so I thought I’d share some high level ideas on how we are engineering those clouds. This short article is meant to share some guiding principles on how to engineering custom portals and backend integrations for SPs that are adopting vCloud Director. Please note that this is a very broad topic and if we were to get into all of the details and potential ramifications we would need a book and not a blog post to describe this.

So what does it make it so unique? SPs have been building portals and integrations forever. Why would a vCD based solution be any different? Well, let’s make a step back. There are two main reasons why Service Providers want to use vCloud Director:

• Avoid reinventing the wheel and use an out-of-the-box product that delivers the cloud backbone (RBAC, virtual data centers, security, multitenancy etc) on top of which they can create their own solution and value.

• Exposing the native vCloud APIs to enable federation with customers that are using VMware technologies (either vSphere or vCloud Director in so called “private cloud” deployments).

The next picture shows, at the very high level, the vCD architecture. A more detailed description can be found here if you are interested.

APIs. APIs. APIs. If there is anything that matters in the cloud that is the APIs. In other words a programmable infrastructure. If you are a Service Provider interested in vCloud Director you are probably interested in the vCloud APIs because that means that, as we mentioned above, you can reach out to a vast amount of VMware customers allowing them to connect to an “on line compatible infrastructure”. You can read more of this hybrid cloud opportunity here and this is a high level representation of this concept:

Browser based access to the cloud is a no brainer. You can read more here about how to use vCC (vCloud Connector) to connect to a public cloud. You can read more here if you are interested in connecting your vCO (vCenter Orchestrator) instance to a VMware cloud. These are just two examples that describe how the end-user can leverage a vCD based public cloud. VMware, and the ecosystem as a whole, is coming out with a number of tools that interact with the vCloud APIs natively. VMware vFabric AppDirector is another good example of these tools consuming these programmable interfaces. I encourage you to have a look at the brief demo video available here.

If it isn’t clear yet, this is the reason for which developing a ton of logic right above the vCloud APIs isn’t a good strategy if SPs want to offer a VMware compatible cloud service. You want the vCloud APIs to be widely available and well exposed. Not obscured by “a ton of scripts and workflows”. That is to say that building something that look like the following picture may not be a good idea if you want to be part of what I call the vCloud bus:

Do not do that. Please.

Having this said, let’s dig into what the SPs need and what their requirements are. An oversimplification of what they would like to achieve can be summarized as follows:

• They want to have a customized portal where they can keep their own traditional look and feel and potentially expose additional services.

• They need to integrate into their backend systems through a mix of business and technical orchestration tools.

So let’s try to take this apart and start with the first requirement. Ideally the SP would need to build a brand new portal (the out of the box vCloud Director web portal cannot be customized) or reuse an existing portal that they want to complement with the new vCloud Director based IaaS cloud services. As you can see this allows the SP to mesh vCD native services with other services that need to be exposed. These could be other VMware services that are not yet integrated into the vCloud API framework (VMware Chargeback or vShield App come to mind) or totally different services that the SP would like to make available to external customers.

There is only one principle that the SP needs to be conscious of when building this custom portal: the additional services exposed in the custom portal needs to be loosely coupled from the vCloud Director services. In other words the architect designing this needs to make sure that accessing vCD services through the native APIs doesn’t break the consistency. Basically the custom portal cannot inhibit users to access vCD through the out of the box UI or the native vCloud APIs if basic native functionalities is what the users need to access. Putting it in (yet) another way, accessing the cloud via the native vCloud APIs / UIs shouldn’t break the consistency of the whole solution but only limit the users in what they can do (as opposed to accessing a custom portal that has more advanced functionalities).

This is, in essence, the reason for which we removed the “Orchestration / Logic” from the top of the vCloud APIs. Should the SP build the logic on top of those APIs they are essentially obscuring them. In fact, allowing a user to access obscured vCloud APIs would lead to bypassing the logic which in turns would make the whole solution inconsistent.

So what do we do to satisfy the SPs requirements of synchronizing the backend according to events that may occur at the vCloud Director level? The typical example SPs usually refer to is a scenario where an end-user deploys a new vApp and there must be some logic (somewhere) that intercepts this event to update a CMDB with the relevant information. Now, we can spend the remaining of this post discussing the value of capturing a self-service vApp deployment in the cloud into such CMDB but we will leave this discussion for another post. The question is: if we can’t put this logic between the user and the vCloud APIs to intercept this event, how can the SP know what happened to track it properly (the CMDB is just an example, it could be any backend system such as ticketing or anything really).

In vCD 1.5 VMware introduced a new feature called “vCloud Messages” also known as “notifications” or “call-outs”. Essentially vCloud Director 1.5 is able to track internal events and notify them via an AMQP message bus for an external module to consume these information. The picture below shows the flow where vCloud Director informs the AMQP bus that an event has occurred and the Orchestrator will take the proper action to update the backend systems:

In this example a vApp is deployed using the vCloud APIs, vCloud Director puts a message on the AMQP bus that the vApp has been created, the orchestrator module reads this message and it then updates the CMDB. Note that the module where the logic is implemented connects to basically all modules in the infrastructure since the notification may require actions that go beyond those of updating a back-end system.

It is also important to note that the diagram above is a logical representation. The “Additional Cloud Services” illustrated above can either be delivered via the Orchestration / Logic components or by totally different subsystems that are available in the Service Provider infrastructure. In other words there should also be a virtual link from the Custom Portal to the Orchestrator / Logic components. The very same principles discussed above apply here as well. Exposing additional services (made available by the orchestration layer) shouldn’t inhibit and limit end-users from accessing their resources via the native vCloud APIs (or UI for that matter).

Perhaps it is worth spending a minute to better characterize the Orchestration / Logic brick. In a complex organization like a Service Provider this may be comprised potentially of multiple modules and products. Usually there are at least a couple of components inside that brick and they are what I refer to as a Business Orchestrator and a Technical Orchestrator. The former is responsible for interacting with the back-end systems (it may even be considered part of the back-end systems) whereas the latter is responsible for interacting with the actual infrastructure components and modules. Graphically, it means this:

One of the reasons for this split is because the business orchestrator module plays a key role in the governance of the solution but doesn’t usually have the full range of adapters and connectors to talk to the infrastructure modules. Because of this it leverages a technical orchestrator module to deal with that part. In most situations the Service Provider already have such a business orchestrator in place. Most of the time though, based on my experience, what’s missing is a more technical orchestrator module that interacts with the lower level infrastructure components. This leads to lots of extra in-house development that is expensive, time consuming and hard to maintain.

This is where vCenter Orchestrator comes in. We have previously mentioned, at the beginning of this post, you can use vCO as a cloud end-user tool to consume the vCloud APIs but where vCO really shines is as a technical orchestrator acting in the back of the cloud to pull all the infrastructure pieces together.  There is also a nice article that talks about how to extend vCloud Director capabilities using vCenter Orchestrator (this ties back to the concept that additional cloud services exposed in the custom portal could be delivered by the orchestrator directly).

Note that what I have discussed here so far is the logical high level architecture of the solution. Different modules do not necessarily mean different products (although they often do). For example there may be situations where a single product could deliver both a portal and business orchestration modules. VMware Service Manager is an example of these products. As I said big Service Providers often have this part historically covered already anyway.

In conclusion, it is advisable (if not imperative) for Service Providers to be able to expose the native vCloud APIs to maximize market opportunities and value to existing VMware customers. In order to do so SPs need to follow proper design principles for backend integration and custom portals design. This brief blog post is only meant to be a starting point for outlining the criticalities associated.

Massimo.