VMWorld 2015: Sessions, Swag, and a Broken Promise

When Satya Nadella took charge of Microsoft and said they were going “cloud first” I had a hard time believing him – given the previous CEO’s tendency for hyperbole and marketing double-speak. But they proved me wrong. Their continuous delivery of new features and services in Azure and Office365 over the last year has been impressive. It’s changed the way many IT departments approach service delivery.

At last year’s VMWorld, VMWare made the same promises. “We’re making the shift. We’re going cloud first with all of our products.”

A year later, I’m at VMWorld again and am unsure if they didn’t know what they were committing to or just changed their minds.

Tied to the point release

I love a lot of what VMWare is doing right now, especially in the end-user compute space. They’ve enabled some really interesting opportunities with all the integration work that’s been done from NSX in the datacenter down to the device with Airwatch and Horizon – things that are going to make security and device management a lot easier.

They’ve been a good partner to work with and they have a clear, unique vision of where they want to go with EUC and hybrid cloud, which is exciting.

But for a company that committed to “cloud first”, they sure talk a lot about “the next release”.

“You can already do this in the on-prem product. It’ll be coming to the hosted service later this year.”

“We’re planning at least three releases for our hybrid cloud next year.”

“All the features you’re asking for will be available in the next release.”

That’s not cloud first. That’s not continuous delivery or devops (ideas that VMWare has been speaking to heavily). It’s waterfall development with a focus on boxed product. It’s shoehorning on-premise into the cloud.

It’s a strategy that isn’t going to work if VMWare really wants to appeal to anyone outside of their most traditional enterprise customers. It’s certainly not going to get them out of playing catch-up to Microsoft and AWS.

Culture clash

There seem to be lots of people at VMWare who see the problem, but they are butting up against the internal politics and culture of “Don’t make our legacy customers uncomfortable or my division may lose sales and I won’t get my boat.”

The same battle is happening at all of the vendors making the shift to cloud. Bring up Meraki to someone in Cisco route/switch internal sales and watch their face melt. Everywhere you look you’ll see the old guard fighting a losing battle for relevance.

Maybe it takes a dictatorial leader to resolve that. “Shut up. This is what we’re doing. Get on board or get out.” I’m not sure I’d want to work for that person though.

I do know that shifting from point releases to continuous delivery takes a massive shift in mindset across the entire business that isn’t easy, but it’s not unprecedented. Microsoft and IBM are doing it and they’ve got much bigger ships to steer.

They’re leading with cloud and carving out boxed products for the customers that lag behind – prioritizing the future over the past. I’m not sure there is a “right” way to pull this stuff off, but what they’re doing sure looks “right”.

Promising progressive customers “cloud first” and then not executing is certainly the wrong approach. Unless your goal is to alienate them and get them looking for solutions elsewhere.

Image Credit: VMWare PR

Accelerating Change: Adapt or be eaten

I was fascinated with animals when I was a kid. Whenever there was an animal documentary on PBS, I was glued to it.

My favorites were the predator and prey hunts – big savannah cats sneaking up on gazelles, chameleons popping out of camouflage to grab insects with their tongues – that sort of thing.

Mimicking the animals, my friends and I would play hide and seek in the woods – hunting each other with pellet guns (I’m really not sure how none of us ended up blind.).

Between reading, watching those shows, and getting pelted with lead, one thing stuck with me:

When you get comfortable and stop paying attention to what’s going on around you, you get eaten.

Or at least hit in the back of the head with a pellet.

Unable to adapt

Humans are terrible at anticipating change. It’s hard for us to get out of our day-to-day and our local scene. We’re busy, we’re distracted, we’re worried about surviving office warfare for the next 8 hours.

But we live in an age of rapidly-accelerating, Kurzweilian change. To keep one’s head down and assume everything is going to be a.) OK and b.) the same, is a form of intellectual and career suicide.

You know those people. You see them in the hall at work. You pass them on the highway.

They say things like “We’ll never do that…” and “It’ll be at least ten years until…” and “I’ll worry about that later.”

When it comes to technology they make the mistake of thinking that the next five years will resemble the last five. They look at continuous delivery, or BYO, or containerization and think “That’s fancy, but I’ll never have to deal with it.”

It is one thing to disagree about the nature of a change – this is healthy and necessary, but another to claim that something will not change.

Keep moving

We’re living through a major technological transition driven by pervasive compute and connectivity. It’s a big enough step that not everyone is going to make it – especially those who can’t or choose not to re-tool. Many people are going to find themselves pushed into lesser-paying roles or different careers.

It’s heartbreaking talking to those folks, trying to convince them that what’s headed their way is real – that the future is coming and it will be radically different than the present, even though we might all be wrong about the details.

“If you would move literally two steps to the right I think you’ll be OK.”

“Nope, ain’t gonna do it. You’re wrong, dummy. YOU’LL NEVER TAKE ME TO THE CLOUD!”

But I’m going to keep trying because the world is in constant flux and the future is coming. In fact (in the words of William Gibson), it’s already here, it’s just not evenly distributed.

Image Credit: Shutter Fotos

SCCM for device management is a dead end

I have always done my best to avoid Microsoft System Center, especially Config Manager. I don’t hate the product (It’s fine, whatever.), but I loath the culture and business decisions that SCCM enables and in many ways represents – turn every knob, customize every widget, control ALL the things.

SCCM is the embodiment of big, ponderous IT driven by big, nonsensical bureaucracy. It’s not the tool’s fault, it’s just how everyone ended up using it.

“We built a task sequence to swap out all the standard Windows icons with ones the CEO likes better. Your CD drive icon is now a portrait of Grover Cleveland.”

“The auditors said we need to index all the .ini files on everyone’s laptop. Then they asked what an .ini was.”

“Oracle wants us to show them a software report so they can charge us more.”

SCCM made it easy for IT departments to do stupid, expensive things and create unsustainable processes. I have rarely come across a business, that after spending thousands (if not millions) of dollars implementing and customizing, didn’t view SCCM as a grotesque monster – especially when they were trying to find people to maintain it.

Goodbye, Mr. Dinosaur

The unwieldy IT that SCCM supported is dying. Businesses are shifting to lean, cloud-based IT with less customization and little, if any, on-site server infrastructure.

SCCM doesn’t fit that model. Cloud-based MDM does and Microsoft seems to realize this despite their messaging on the topic being confused and noncommittal.

“More SCCM features are coming to Intune.”

“More Intune features are coming to SCCM.”

“SCCM isn’t part of System Center 2016.”

Huh?

Rebooting device management

Starting with Windows 8, Microsoft began baking in a new management API that could be controlled independently of domain-based solutions like SCCM. Windows 10 includes enhancements to the API and adds a Linux-like package manager for software installs as well as runtime provisioning, removing the need for traditional imaging.

These are technologies for an MDM like Airwatch or Intune to plug into. It’s BYO and cloud-tech. Tech that lets businesses move fast and light. WMI and the standard SCCM tech is still there, but only as a bridging solution.

Given Microsoft’s focus on the cloud and enablement of technologies like Azure Active Directory (and being able to cloud-domain-join Windows 10 computers), I doubt they’ll continue investing in SCCM in its current form. If SCCM is your core skill set, I’d say you have 2-3 years of runway ahead of you.

My current money is on this scenario:

SCCM gets split and “goes away”. The device-focused tech gets rolled into the Intune platform and everything else gets shoved into the cloud-based Operations Management Suite, which is more server focused.

No more SCCM distribution points, no more impossible-to-find specialists, no more turning every dial. Oh, happy day.

Alternatively, SCCM winds up sitting in some weird middle ground where no one understands what it does or if they need it or not and Microsoft’s device management portfolio becomes an even more confusing mess than it currently is. This will incite an IT admin mob that chases SCCM through the village before cornering it and killing it with torches and pitchforks.

That, or the first thing. I’m fine with either.

Image Credit: Andee Duncan

When cloud isn’t cloud

“Your service is entirely cloud-based, right?”

“Yep. Absolutely.”

“So there’s no on-premise hardware? Nothing we have to build, deploy, or manage?”

“Well…”

I don’t know how many conversations I’ve had like this with OEMs and VARs selling cloud products that are only “cloud” in the loosest sense.  When they say “cloud” what they really mean is “hosted” or, in select instances – “hybrid”, either of which are OK, if that’s what you want.

Past the normal software connectors and API integrations you might expect in a cloud product, they have requirements for servers, internal network changes, and myriad other infrastructure items and config changes.

“You need to deploy this SSL certificate to every device.”

“You need to stand up 10 servers attached to your SAN.”

“You need to add these 35 records to your internal DNS.”

“Everyone needs to run IE 8 with Flash version 7 and JRE 2.”

“It only works on Windows… and Blackberry.”

Nope. Not gonna do it. You can take your product and go die in a fire.

Hybrid-cloud – I can get behind. There are some technologies and use-cases that require an on-premise component for at least a portion of their functionality. The client side of things, though, is where most integrators, OEMs, and VARs seem to fall off the rails entirely.

A big part of cloud is providing access to any device, anywhere – without reliance on a very narrow infrastructure config. If your product only works with one browser, requires five plugins, and four internal DNS records – it’s not cloud, but it is terrible. Before you say your service is a cloud service, be sure you know what that means.

Caveat emptor

If you’re on the buying side, it’s important to dive in to product functionality as much as you can before buying, especially if you’re trying to move away from on-prem and toward cloud and/or BYOD.

You need to go past asking “Does your product do X?” and ask “How does your product do X and what does it require to do that?” so you can gain the full picture of what you’re in for.

I’m not cynical enough to think that everyone selling a non-cloud “Cloud” product is trying to pull one over on their customers. In most cases, I think they’re just playing catch-up.

It’s surprising how common it is to find companies selling non-cloud “cloud” products and also doing something silly like selling white-box PCs. They seem to misunderstand scale, commodity, and technology agnosticism across a broad spectrum.

As much as you want to pat their salespeople on the head and say “Awww…who’s a big boy? You’re a big boy!”, it’s better to walk the other way.

Don’t ruin your vendors, dummy.

You did it. You rejected the status quo and took a chance with a startup instead of the established safe bet. Now you’re working with that new company to gear their product toward what your company needs.

Be very careful what you ask for.

Growing up

Companies, like people, are always challenged by who they want to be when they grow up. You can see this in startups as well as established companies like Microsoft and Cisco. You can watch those same companies flop around like dying fish when they’re struggling to define that vision. (Look at Microsoft over the past decade.)

Even single product companies have a lot of trouble defining themselves.

“Do we push for feature parity with our competition?”

“Do we throw a wide net or focus on a niche? Which niche?”

“Do we focus on growth and expansion or stabilize and boost margins?”

So on and so on.

Your responsibility

When you’re working with a vendor that’s trying to find itself, it’s important to keep these things in mind, especially when you start sending them your wish-list items. There are a few reasons this is worthwhile.

  1. You picked them for a reason. You made your pick because you liked that the new solution was simpler, smarter, faster, cheaper, etc. There was something you liked about them that you didn’t like about the safe bet. When you provide a laundry list of requested features and make comments like “Well, the other guys have that functionality.”, you risk turning that special startup into the monster you were running from.
  2. Your processes suck. Everyone has crappy processes, some more than others. When you start making hyper-specific requests based on an existing process, be cautious. You may be propping up your vendor to enable you to keep doing something stupid. Before you ask for something in this vein, really consider what you’re trying to accomplish.
  3. Constraints can be valuable. See above. Having a well defined box to work within drives creativity and innovation. Pushing your vendor to create an infinite sandbox will bog you down in ambiguity and choice paralysis. (*cough* SAP *cough*). Don’t believe me? Turn to your significant other and ask them “We can go anywhere in town for dinner. Where do you want to go?”
  4. You want your vendor to stay in business. When their product becomes bloated with features and they lose direction on what they want it to be, their marketing will become muddled and they’ll have a hard time making sales. Your random requests may be killing your darling.
  5. You’re scattering their resources. Three years from now when you’re asking your self “Their support really sucks now. I wonder what happened?”, the answer might be “you”. Every one of your implemented requests has to be built, integrated, documented, and supported.

You may be thinking “Well, isn’t it the vendor’s job to define their product?” Yep, it is. But if you want them to be around and be the awesome partner you hired them to be, you need to help. Very few companies have leadership who can maintain the laser-like focus they’re going to need to successfully mature, especially when every customer is asking them for the world. (There are very few 37Signals.)

This doesn’t mean you shouldn’t ask for improvements or features, it just means you need to be thoughtful about what you ask for. Each feature request has consequences that (you, and) your vendor might not be considering in their eagerness to please you.

Think of all the stupid things you were willing to do when you were young and really wanted people to like you. The startup you picked is just like your younger self. Help them to not be stupid.

Image Credit: James Provost

Infrastructure People – Learn to code or GTFO

Although it’s not always apparent to those I’m mentoring (Asking me for answers should not be your first step.), I like teaching. I like helping people work through problems and figure out how different components fit together holistically.

Lately, there’s been a particular point I’ve been trying to hammer home in almost every conversation I have – with junior sysadmins, college kids entering the field, and anyone else who will listen.

Regardless of your infrastructure specialty – networking, servers, storage, whatever – you need to learn to code.

Or you need to consider another line of work.

Batch script wizard

Part of gaining expertise is learning the scope of what you don’t know. I remember feeling like a fancy wizard when I started my career in tech – that I knew sooooo much. I could build computers from junk parts and troubleshoot through any problem set in front of me.

Then I met systems and network admins who knew how to script. They could craft batch and bash magic to effect change across the network. The scale of the world they worked within was so much larger than mine.

Suddenly, I felt like a caveman (Not even a smart caveman. More like Flurp, the slow, butterfly-chasing caveman.), clumsily bashing rocks against every problem.

Even simple batch scripts to map printers and install software were game-changing. All of those manual configurations I had been so proud of started to feel silly. I still feel a little of that when I browse through projects on GitHub.

Knowledge of scripting rapidly became a dividing line between tech jobs that paid minimum wage and those with upward potential. Batch (more Powershell now) and bash (more Ruby/Python now) became the foundation to launch a career from.

Code literacy

There are cases where a simple Python script can obviate hundreds of hours of work. Hiring managers know this and this skill set is now expected rather than being a “nice-to-have”.

“Take this server. Now make 1,000 friends for it.”

New expectations are forming around the interaction between infrastructure & applications and general automation. Within a few years there will be very little room in the industry for infrastructure-focused people who are not, at the very least, code literate.

This doesn’t mean you need to be able to build a consumer-ready application from scratch (although that helps), but it does require an intermediate-to-advanced understanding of scripting languages and/or a basic understanding of compiled languages depending on your company’s dev stack.

DevOps is here

What use is a sys admin who just points at the apps team and says “your code sucks” without even being able to read the code? Or a sys admin who is charged with designing infrastructure for an app he or she has no understanding of?

That’s why DevOps (the merging of infrastructure operations and development) has become such a big deal. Companies need their sys admins and programmers to be able to work together and at least have an idea of what the other person is talking about.

“Line 38 appears to reference an individual database server we took offline last week instead of the load balanced DNS name and knowing that this loop is working through this array, I probably gave the app servers too little memory.”

And in situations where an app is being scaled horizontally, the infrastructure has to be there to meet it – automatically. Clicking buttons in the Windows Server GUI is probably not going to get you there. Knowing how to script against the server command line or the platform services an app is running on will carry you a long way.

Additionally, why would a company hire 10 network admins to maintain equipment configurations when they could hire 2 who knew how to script against an equipment API? Be in the second group. Automate your configs and show your value.

It’s up to you

If you have no plans to build your skills past manual configuration, you are destined to work in small, boring environments if you’ll be able to find a job at all.

If someone can hack together a few lines of code to replace you, that’s your fault, not the merciless-robot-who-is-taking-your-job’s fault.

If you think “I can’t code. My brain isn’t built that way.” Spend 30 minutes working through exercises on CodeAcademy or any of the countless other coding tutorials online and you will find out that you are wrong.

This isn’t the requirement for five years from now. DevOps is here today. If you want to stay in the infra niche and be happy and successful, it’s time to fire up your text editor and learn a programming language.

Image Credit: Michael Himbeault

Cisco Live: A river of dudes

It’s been a few weeks since Cisco Live, and I’ve had time to digest a lot of what I heard and saw there. There were some pleasant surprises: The DevNet area was awesome and highlighted some interesting things that Cisco is doing with Infrastructure as Code.

There were also disappointments: Intercloud remains a confused mess, some vendors went super-cheesy with their presentations, and the follow-up sales calls are relentless (Seriously, Puppet Labs, I didn’t need another 25 voicemails.).

But weeks later, the thing that stands out in my mind is the homogony of the attendees. Easily 99% of those present were male, and that stinks.

This happens everywhere

Diversity isn’t a tech industry problem – tech just happens to highlight the most egregious examples because of the current underrepresentation of women and minorities in math and science-heavy fields.

Across all industries, we make it hard for women to get their foot in the door – I’ve seen women turned down for jobs over concern for how others in the business would “cope” with them and a myriad of other silly reasons. I’ve seen women forced to prove themselves far past what’s required of male applicants with similar experience and credentials.

I’ve seen those that have gotten hired treated horribly – spoken down to, insulted, alienated.

Yeah, so…I’m gonna need you to answer the phone now

A few years ago my wife and I worked at the same company. When management fired the receptionist, they decided to split the phone duties among “the other women” in the office. Male peers, at the same employment level, were excluded – they had important work to do. My wife was managing HRIS, but because of her gender she was seen as “less than” the males working in entry-level roles a few offices away.

I know plenty of smart, competent women who have strong interest in fields in which they are not working – tech, science, manufacturing, field ops. When I ask them why they didn’t follow their interests, the answer is almost universally “because I didn’t feel welcome”. They didn’t feel welcome in computer club, in biology class, in their MBA program – so they defaulted to something they didn’t love in order to survive.

That makes me furious

My wife and I have been talking about starting a family, and during those discussions my imagination runs wild. I imagine future children, teaching them things, showing them the world.

I imagine having a little girl who gets told by others that it’s more important to be pretty than smart. I imagine her applying for a job and getting turned down because of her gender. I imagine her getting treated poorly by a chauvinistic manager. I imagine her standing up for herself and being called a bitch and it makes my blood boil.

Changing culture

The status quo hurts everyone. A meeting room filled entirely with men lends itself to the pack-mentality groupthink that results in bad decisions and stagnation. It creates a toxic, locker-room culture in which it is OK to talk down to others and management is accomplished through intimidation. It leads to stale ideas pushed forward by literal yes-men.

My ideal hiring scenario, because I don’t trust my own subconscious biases, would be completely blind – if I was managing a team, I wouldn’t know if a new hire was male or female, I wouldn’t know their race or age, I wouldn’t know any of the unimportant things about them until they walked in the door the first day.

(This sounds impractical, but Google is actually pulling something off that is very similar.)

That’s really hard though, especially for companies that don’t have the resources to setup selection committees or do away with the concept of “hiring” managers. It’s not that hard to blind resumes for the first round of review though, so we can start there.

It’s also not that hard to treat your current coworkers like human beings.

Diversity is a hard problem to solve. There are no easy fixes – there never are when a problem is based in the way people behave, but we have to start making changes, if only to build momentum.

Down with the patriarchy. Long live basic human decency.

Give up control and stop managing devices

Managing end-user devices, simply put, sucks. It requires a significant amount of infrastructure and staff. It leeches time from your IT department and end users. And the more you try to wrap your arms around all the devices in your company, the more problems you have.

Trying to fully control and manage every device connected to the network results in unhappy users and broken IT staff, huddling in data closets, weeping – while the executives upstairs are piped a false sense of security.

So stop managing devices. Don’t join them to a domain, don’t lock them down. Give up control.

I promise you, it’s not as crazy as it sounds.

All the devices!

IT departments have been struggling for years to juggle trusted and non-trusted (BYOD) devices. We layered on tool after tool to try to stay in control, but it hasn’t really worked. It’s just made management more complex.

We built a taller wall around trusted devices and the network, and tried to extend control to all the new things that employees were bringing to work. We began to manage triple the devices with the same number of staff.

Users hated the new restrictions on their computers as we locked them down, and IT hated all the new infrastructure we had to install and maintain to keep any semblance of control. We kept piling on sandbags long after the levee broke.

It’s time to start over

Instead of trying to exert control, what if we went the opposite direction? What would happen if IT treated all end-user devices as non-trusted, employee andcompany owned?

  1. Security is simplified.  If we assume that all endpoints are insecure, we can drastically shrink the surface area we need to protect and focus on data and apps. Devices are separate from the data center and one another.
  2. App management is centralized. With a small number of exceptions, we can deliver apps via browsers, virtual desktops, or streaming – from the datacenter or the cloud.
  3. Data is tied to identity. Unstructured data moves to the cloud, with rights management or containerization in place depending on your compliance needs.
  4. Devices don’t matter. Remember, we’re relying on remote delivery of apps and data (Think of everything as a thin client.). A user is having a computer problem that takes more than 5 minutes to fix? Swap the device out with another from the pool.
  5. Overall management is simplified. But maybe we require a health check to keep things from getting too crazy. Don’t add machines to the domain, use an MDM. Passcode, A/V, and security updates seem like reasonable requirements to enforce, but stop there.

This isn’t a thought experiment. This model is being pulled off successfully (sometimes in pieces), not just in Silicon Valley, but in growing pockets around the country – within organizations that are aggressively embracing the future.

Vendors are building and have already built products and services to support this model. VMWare, Microsoft, Google, Amazon – almost every player who matters is on-board.

If you’re in an architecture or strategic role, this is the future you need to be planning for. The current model is untenable – within a few years, if your IT departments is still trying to manage devices the same way you do today, with half the budget, a quarter of the staff, twice the tools, and exponentially more devices – you will fail.

Photo: ep_jhu

It’s OK that the cloud doesn’t do everything

One thing you won’t hear when a vendor is pitching their cloud solutions to you is that the biggest success factor for your move to the cloud is a willingness to embrace constraints – being OK with the box you’re putting yourself in.

Constraints aren’t inherently bad – I use them all the time in photography. Knowing what my camera can and cannot do pushes me to approach shots differently, often resulting in a photo that is far better than what I would have achieved if I had attacked the problem head-on with all the camera equipment I wanted available to me.

When it comes to the cloud, constraints force you to re-examine what you’re doing. That helps on the technical front, but it is especially powerful when it comes to business processes. The last 60 years of on-premise open-sandbox tech has enabled people to build a lot of really dumb processes.

“So, I type in all the info from these paper tickets into this spreadsheet, then I print it out and fax it to Dorothy. Then she combines my report with the other sites’ reports, prints that out, scans it, then e-mails it to Richard so he can plug it into an Access database.”

If you’re moving off-prem, consider it an opportunity to reset and if you can manage it, forklift as little as possible when you make the transition.

Azure and AWS don’t support all the custom infrastructure hacks you’ve put in place over the last 30 years? Do yourself a favor and leave those hacks behind. Learn the platform and focus on what it can do.

The new SaaS vendor doesn’t support the process you built in your old, on-prem ERP?   Instead of trying to hack something together to get the new system to support your process exactly as-is, call the vendor, describe the problem you’re trying to solve (start with the problem, not your years’  old solution) and work with them to design something new.

Turns out, software companies like Google and Salesforce employ a lot of really smart people, and the best ones understand that as beautiful as their code is, it has to be used in the real world.

These are things I want to shout whenever I’m at an industry event. It never fails that at least one neck-bearded engineer in the room pops up with “I’ll never move to the cloud, it doesn’t do this, this, or this.”

Occasionally, they have one or two valid points out of the handful they toss out.

When pushed though, their reasoning is usually “because we have it now’, which is the perfect rationale to help the business drive itself off a cliff.

Photo credit: Perspecsys

Thoughts on the eve of Cisco Live

In less than 24 hours I will be boarding a plane headed to San Diego. It’s my first year to attend Cisco Live and I’m hopeful I’ll see something different than what I’ve seen from Cisco over the past few years.

That companies are migrating so quickly to op-ex, cloud services models seems to have surprised Cisco – they have been fumbling for a good while now, trying to find their way in the new world.

The Meraki acquisition was smart – it gave Cisco a robust-but-easy-to-deploy, low-overhead infrastructure solution that customers have been clamoring for, but from the outside it appears the legacy product teams are at odds with the Meraki team. The promise of a converged feature-set appears to have stalled out, with internal politics and concerns of sales cannibalization serving as roadblocks.

Last year, Cisco Intercloud was pitched to me as the solution to all my cloud integration problems. Intercloud was going to enable me to easily migrate VMs between cloud providers and extend the LAN across the multi-cloud WAN. Problem is, as a brand new product Intercloud is designed around a paradigm that’s rapidly fading.

Modern IT is not being built around individual VMs or extensible network segments, it’s all about workload. Being able to move VMs around is handy for the near-term in dealing with legacy applications, but workload containerization negates one of the biggest selling points of Intercloud. I don’t want to move VMs from AWS to Azure or On-Prem to Cloud, I want to kick off a Docker push of my app image and let the platform take care of the rest.

Intercloud seems to be targeted at where the puck was, and the game has shifted considerably. It will be very useful for many big businesses, but not for very long.

Even in the datacenter, startup SDN solution providers like Cumulus Networks seem to be getting better at the Cisco stuff faster than Cisco is getting better at rapid innovation.

I say all these things not to beat up on Cisco, but to nudge them towards where I think they should go, where I think they can remain relevant. Right now, Cisco seems to be focused on providing solutions for today, when other IT vendors are pulling their customers into the future.

The Cisco I hope to see at Cisco Live is one that is aware of where it is falling behind and is rapidly moving to correct. I want to hear more about DMVPN than OSPF & BGP. I want to hear more about APIs than integration licenses.

I don’t think Cisco is at any risk of going away (Existing enterprises and telecoms are going to continue rolling out Cisco equipment because that’s what they do by default.), but like any big tech company they are at continual risk of becoming irrelevant and technologically boring – and right now their ship seems to be changing course very slowly.

Photo credit: Andrew Hart