Recently, I wrote an article on PaaS for IT BusinessEdge entitled the road PaaS, understanding your post IaaS options. Here’s an excerpt.
The Road to PaaS
PaaS is an enticing proposition that has generated a lot of market buzz.
But PaaS forces tradeoffs and it shouldn’t be seen as a one-size-fits-all proposition.
To understand, I like to draw the distinction between what I call “Silicon Valley PaaS” and “Enterprise PaaS.” The majority of the discussion in the market today revolves around the Silicon Valley PaaS pattern, which is a truly abstracted “black box” approach to software platforms.
This form of PaaS exposes a set of standardized services to which you write your applications, completely sheltering developers from the underlying complexity below the PaaS abstraction.
It makes a lot of sense for brand-apps built with modern frameworks like Python and Ruby in greenfield development environments that are highly standardized.
The basic premise of the post is that PaaS for an enterprise is VERY different from PaaS for a Silicon Valley start up. And nowhere is it more different than in the network requirements.
The PaaS customer is a developer who will code an application, use the underlying services offered by the PaaS stack, such a database, storage, queueing, etc. The developer deploys the code, selects a few options and code is live.
So what’s going on with the network? Well, the PaaS layer will need to auto-scale, fail-over and deliver performance at some level. It may need it’s own domain as well. That PaaS layer will need to talk to underlying network services such as firewalls, switches, etc. That PaaS really needs access to infrastructure models that deliver network containers to whatever PaaS abstraction the PaaS layer has.
Hard enough to do when all the containers are the same, as it would be in a Silicon Valley PaaS offering.
It doesn’t work with the existing enterprise platforms. This is a big opportunity for innovation
Tags: Cisco Intelligent Automation for Cloud, cloud, Cloud Management, intelligent automation, orchestration, paas, Service Orchestration, unified management
Continuing on our theme of virtual network overlays and programmable networks, today we’ll look at how to increase workload mobility over more data center and cloud resources. If server virtualization increases resource utilization and reduces costs, and data center consolidation is a good thing, then it follows that the larger the resource pool that your virtual workloads can migrate over, the more cost effective your IT operation can be. And if your mobility diameter spans multiple sites, you can obviously improve your fault tolerance as well. We call this increasing your mobility diameter, and we’ll complement what we’ve already learned about VXLAN and virtual overlays with some new technologies to seamlessly scale your diameter up. (Sounds like some sort of bizarre reverse Weight Watchers program, doesn’t it?).
As we noted in our VXLAN overview, VXLANs enable private virtual overlays over layer 3 boundaries via their MAC in UDP encapsulation and the cool way they filter MAC address broadcasts to only the right subnets. However, when you are doing full on application migration over a layer 3 boundary, VXLAN alone isn’t going to do it alone. In order to extend virtual workload mobility beyond layer 2 boundaries, Cisco came up with Overlay Transport Virtualization (OTV) that can work in conjunction with VXLAN to extend application mobility to any point the VXLAN virtual overlay can reach. And not surprisingly, the media wizards over at TechWise TV have a great video that takes all the complexity of OTV and makes it cartoonishly simple.
But wait, there’s more… Read More »
Tags: Nexus 1000v, OTV, Overlay Transport Virtualization, virtual network overlays, VXLAN
For me, even though I am mostly a hardware geek, one of the coolest parts of the Cisco ONE launch at CiscoLive was the introduction of onePK. We see onePK as an core enabling technology that will have some cool stuff down the road.
So, one of the more common questions I get is about the relationship between onePK and other technologies related to network programmability such as OpenFlow (OF). Many folks mistakenly view this as an either/or choice. To be honest, when I first heard about onePK, I thought it was OpenFlow on steroids too; however, I had some fine folks from NOSTG educate me on the difference between the two. They are, in fact, complementary and for many customer scenarios, we expect them to be used in concert. Take a look at the pic below, which shows how these technologies map against the multi-layer model we introduced with Cisco ONE:
As you can see, onePK gives developers comprehensive, granular programmatic access to Cisco infrastructure through a broad set of APIs. One the other hand, protocols such as OpenFlow concern themselves with communications and control amongst the different layers—in OpenFlow’s case, between the control plane and the forwarding plane. Some folks have referred to onePK as a “northbound” interface and protocols such as OpenFlow as “southbound” interfaces. While that might be helpful to understand the difference between the two technologies, I don’t think that this is a strictly accurate description. For one thing, developers can use onePK to directly interact with the hardware. Second, our support for other protocols such as OpenFlow is delivered through agents that are built using onePK.
That last part, about the agent support is actually pretty cool. We can create agents to provide support for whatever new protocols come down the pike by building them upon onePK. This allows flexibility and future-proofing while still maintaining a common underlying infrastructure for consistency and coherency.
For instance, we are delivering our experimental OF support by building it atop the onePK infrastructure. For customers this is a key point, they are not locked into a single approach—they can concurrently use native onePK access, protocol-based access, or traditional access (aka run in hybrid mode) as their needs dictate. Because we are building agents atop onePK, you don’t have to forgo any of the sophistication of the underlying infrastructure. For example, with the forthcoming agent for the ASR9K, we expect to have industry leading performance because of the level of integration between the OF agents and the underlying hardware made possible by onePK.
In closing, you can see how extensible our programmatic support is with the ability to use onePK natively or to support technologies and protocols as they are developed and released. This gives customers a remarkable level of flexibility, extensibility and risk mitigation.
Tags: ASIC, asr9k, ciscolive, netconf, onePK, OpenFlow, SDN
If I have said it once, I have said it at least a thousand times. No figure of speech here, completely one hundred percent literal. What have I said? “If you can do it in UCS Manager GUI, you can do it in UCS Manager API!” Whatever “it” is.
When do I say this? Whenever I talk about the UCS Manager to customers or coworkers, there is almost always the question, “Can this be done via the API?” To which I always reply “If you can do it in the GUI you can do it in the API.” Not sure if that is grammatically correct, but my point is made. That is the power and the ease of the UCS XML API.
The UCS Manager graphical interface is built on the XML API. When developing a script and you’re not sure how to do the action, what the call is, what the correct parameters are, etc… Just look at how the UCS Manager does it and you’re good. How do you look at how UCS Manager does it? Use Wireshark or some other packet capture tool and see what’s going on, what is getting passed from the UCS Manager client to UCS Manager. Done, no secrets, no convolution, no obfuscation.
Read More »
Tags: automation, PowerShell, PowerTool, UCS
Wow, there’s been a lot of news in the SDN and virtual networking space in the last week or so! VMware acquiring Nicira, and Oracle acquiring Xsigo are testimony to how important virtual overlay networks and virtual switching infrastructure has become for data center vendors, and how integral they are to each company’s strategy. Speaking of our own Nexus 1000V-based virtual networks, last week I provided an overview and some new resources on Virtual Extensible LANs (VXLAN) for Nexus 1000V virtual switches. That turned out to be quite a popular post, so I’m following up this week on another fundamental component of Nexus 1000V-based virtual networks, vPath, the secret sauce that allows us to deploy virtual network services in the data center.
What is vPath? Well, if VXLANs can set up secure tunnels over a shared, multi-tenant virtual network, vPath is a feature of the Nexus 1000V virtual switch that can redirect traffic to virtual application services before the switch sends the packets down into the virtual machine. Very important stuff, but how does it do that? I find that my blog posts are more popular the less I type, and the more I embed cool TechWiseTV videos that illustrate the concept, so I’m dusting off this classic from the TWTV team on just how vPath does that with our Virtual Security Gateway (VSG). Take it away Robb…
But wait, there’s more… Read More »
Tags: ACE, ASA, ASA 1000V, CIAC, Intelligent Automation for Cloud, Nexus 1000v, Nexus 1010, OpenStack, SDN, TechWiseTV, Virtual Security Gateway, vPath, vsg, vWAAS, VXLAN