In the real world, there are the seven George Carlin words that if said will make people uncomfortable, especially if used with the wrong audience or in the wrong context. In the IT world, those words are CHANGE, VALUE-ADD, COMMODITY and AGILITY (in no particular order). Use those words and somebody in the room is going to cringe, or potentially ask you to leave. They are the words that draw the dividing live between vendors, since we mistakenly believe that IT is a zero-sum and there are only “winners” and “losers” and the new will always vanquish the old. You do worship at the altar of The Innovators Dilemma, don’t you?
They are the words that make IT operators sweat, thinking about the 2 a.m. pager notice they’ll get because the new system, which requires new skills, is operating less than optimally and somebody wants it fixed…now!!
Up until a few years ago, they were words that both the IT sellers and IT buyers knew how to balance to keep the ecosystem fairly healthy and constantly evolving. But a few significant changes have come along – namely “cloud computing” and “open-source” – and opened up new options that are disrupting the balance that previously existed. The previous two IT options of Build-it-Yourself or Outsource, both of which used similar technologies and skills, now had a third option – various Public Cloud options (IaaS, PaaS, SaaS, *aaS).
And these new options are forcing the IT conversation to distinctly change from one centered around new technologies to one that’s centered around the pace of change of either IT economics or IT skills/process, and sometimes both.
Let’s just look at a few recent articles:
- 25% Tech, 75% Culture: Build a Window in the Wall (Puppet Labs)
- “…a Telling Glimpse of the Future of PaaS” (Ben Kepes, @benkepes)
Both of these articles center around the idea of either building “abstractions” to layers that are deemed “less valuable” (see: don’t VALUE-ADD), or focused on a less valuable group changing (see: CHANGE) otherwise they become irrelevant – oh wait, maybe they could be “strategic”, as long as they quickly learn skills that they never needed before, and fast!! Continued »
Earlier this week, GigaOm wrote a post discussing the possibilities that the largest web companies would begin designing their own chips (CPUs, etc.). This was following up on the trend of companies like Facebook, Google, and Amazon designing their own servers and networking equipment, or efforts like Open Compute Project open-sourcing designs that could be delivered by ODMs.
While articles like this are interesting for getting a peek into the 0.01% of companies where this is feasible (and needed), since they are running 21st century bit-factories, the question that seemed to emerge was, “how will this effect the companies that sell hardware for a living?“. I’ve written before about how hardware has been rapidly evolving, especially for cloud computing.
When I read articles like this, I tend to think that this is a macro-level trend that is inevitable. The components within hardware are evolving rapidly, and the net-value of the hardware (by itself) is decreasing vs. the associated (or decoupled) software which is increasing. You can have valid arguments about the timeline over which this evolution will occur, but believe most rationale people will generally agree that the trend in value is shifting towards software and away from hardware. System integration of the two still has it’s place, but even where that occurs (in the supply chain) is changing as well.
The more interesting question to me is how the hardware companies will respond to this. Of course they will claim that hardware still matter, especially for performance. They may also claim that visibility is needed at both a hardware and software layer. Fine, that’s to be expected. But will we see any actual changes in how they do business, or how they go to market?
The reason I ask is this question is because I’m constantly looking to the manufacturing sector to give me clues on the future of IT, since they are running on parallel tracks, albeit that IT is 10-15 years behind.
When Pivotal Labs publicly launched, there was an interesting discussion between Paul Maritz (CEO, Pivotal) and Bill Rue (VP Global Software, GE). They were talking about how the airlines (directly or via Boeing/Airbus) were now buying engines. The discussion centered around the idea that engines were no longer purchased as capital assets, but rather they were now being paid for based on usage. One of the initiatives by GE was to do a much better job of collecting real-time data about the engines to better manage downtime and associated maintenance costs (all things that would effect GE’s ability to collect revenue for the engine’s usage).
This got me thinking – will we begin to see the hardware vendors begin to take a clue from manufacturing and charge usage-based pricing for their equipment rather than just capital assets (paid directly or via lease)? Will we see them begin to add capabilities to better track how their systems are being used, in near real-time?
The challenge of capital (CAPEX) purchases and long depreciation cycles is one of the biggest barriers to companies being able to successful deploy “Private Cloud”, as they don’t have the ability to create “agile, dynamically scalable” resource pools when they can’t budget and buy in that manner.
Will the lack of overall success with Private Cloud deployments, plus the specter of lower-margin hardware sales eventually force the hardware-centric vendors to change their selling models in the future? Do they actually expect to fight Moore’s Law without trying to reinvent the business model at the same time?
According to this piece in the NY Times, I’m old. I’m not yet an average/median worker in America, but apparently I’d be “Grandpa Gracely” amongst the hipster tech world.
And when you’re “old”, especially in the technology industry, the expectation is that you’re looking for stability, not change. A nice paycheck, generous benefits and maybe a set of responsibilities that are challenging but won’t have you working late nights and weekends. Squeezing in meetings between checking the status of your 401(k).
But I’ve also worked at some of the larger companies mentioned in the article, and the days of never ending meetings and delayed decision-making had me frequently thinking about leaving behind the bigger brands and making my mark with something smaller. About seven months ago, I made the leap. I joined a small company, backed by venture-capital funding, that was somewhere between maturing start-up and early-stage growth company. For a number of my colleagues, the reaction was “are you sure about that?” or “shouldn’t you have done that years ago?“. Maybe, but this was the right time for me to do this. It’s been an interesting ride so far. I get asked about it all the time, especially from people trying to make next-step decisions in their careers, so I thought I’d share some of my learnings.
Jack of Many Trades – In general, the smaller the company, the more it will be expected that you can play multiple roles and leverage multiple skills. That’s definitely the case for me. I was hired to drive Solutions and Technical Marketing, but that quickly evolved to include running Product Management, managing Strategic Partner relationships, helping to shape future strategy and being able to do day-to-day Field Enablement. If you like wearing many hats, smaller companies can be a great place to stay challenged and to grow. It can also mean that at times you have overlapping priorities and you may be asked to lead something that it beyond your comfort zone.
Long Days and Long Nights – Smaller companies have less resources. Smaller companies have less brand-awareness. Smaller companies don’t have the luxury of outsourcing the tasks that larger companies take for granted. This means the work is on you. This means the hours will be long. Know what you’re signing up for. This is where self-motivation comes into play, because you’ll have to make some personal sacrifices.
Always Be Closing (ABC) – Whether you like it or not, everyone at a small company is part of the selling process. You may not directly carry a quota, but you’ll mostly likely be interacting with your customers on nearly a daily basis. With a smaller company, those customers are constantly testing anyone they can to see if you’re really able to deliver what you say you can. So while you might not be directly selling the product or service, you’re definitely selling “confidence” and “trust” and “commitment”, the intangible things that customers of smaller companies are evaluating above and beyond the technology. Continued »
The past 4-5 years have forced IT organizations to go through some significant changes as the pace of technology has accelerated greater than ever before. Virtualized resources, converged infrastructures, advanced automation tools, new development frameworks and business users that are smarter and willing to consider new consumption models.
But as the pace of business need have increased, the common thinking is that more and more IT tasks need to be automated in order to keep up. And hence begins the challenge for IT organizations. For years, the device-specific GUI was the interface of choice for many IT professionals (or CLI for the networking crowd), often augmented by various types of scripts. GUIs worked fine, aside from browser headaches, but they limited the ability to scale operations. Scripts increased the pace, slightly, but script maintenance often became a full-time job. Far too often, IT organizations collected a mountain of GUI + Script debt as they added various products to their environments, each with a different preferred operations model.
Modern IT operations tools, Git / Razor / Chef / Puppet / Ansible / Jenkins / Vagrant / Nagios – are now built around modern programing languages and assume that users will have more advanced skills in programing the tools to drive advanced levels of automation. They replace the traditional GUI with a set of APIs (typically based on REST). And herein begins the challenges for IT organizations: Continued »
This past week, at the Structure 2013 conference, I had the opportunity to be part of a panel with Ben Kepes (@benkepes) and Rodney Rogers (@rjrogers87) entitled “Mission Possible: Moving Business-Critical Apps to the Cloud”. The focus of the discussion was real-life examples of Enterprise companies that had migrated their mission-critical applications (eg. ERP, CRM, HCM, SQL Databases, Unified Communications) to public clouds.
One of the topics that we covered, based on a question from the audience, was about the bifurcation of existing applications and new applications, specifically in migration scenarios. The question was “Will this lead to faster adoption of ‘DevOps’?”
While I’m a believer that DevOps and have discussed it quite a few times on the podcast (here, here, here, here), I thought it was important to highlight that there is a non-technical element that is critical to the success of migrating business-critical applications. DevOps is a fundamental operational requirement for anyone building modern, scale-out web applications, but those applications are typically very different than existing (legacy) applications. And in most cases, those existing applications make up 80%+ of the IT portfolio in terms of resource usage and on-going costs.
Just as DevOps is ultimately about providing greater transparency between Developers and Operations, I believe that application migration is ultimately about something I call “BizOps“. Far too often, Cloud Providers talk about the simplicity of migrating applications to their Cloud, focusing primarily on the transition of a VM from on-premise to off-premise. But where problems arise is when that off-premise cloud is fundamentally a black-box to the business (or existing IT staff). Unless a business is migrating to a SaaS application or completely outsourcing the business-critical application, it can’t be overstated how important it is to maintain a level of transparency between the Cloud Provider, the Business and IT. This is “BizOps”. Continued »
A few weeks ago, Dell acquired Enstratius. They make excellent software for managing and governing multiple cloud environments (via the APIs), and we’ve had their leadership team on the podcast a few times (here, here). They primarily delivered their software as a SaaS application, although it could also be run on-premise. Since the acquisition, Dell has shifted their Public Cloud strategy and now Enstratius products are the core of a plan to let customers leverage resources from multiple cloud platforms. And I believe the fact that it can be delivered as a SaaS application was key to making that shift. It made it much simpler for customers to begin the process of consuming cloud resources, instead of having to setup tons of equipment (hardware/software/security) on-premise.
Last week, a friend that works quite a bit with VMware environments sent me this “BOM” (Bill of Materials) for a reasonable sized setup to create the full vCloud Suite (vCenter, vCloud Director, vChargeback, vCAC, vCNS, vCO). What jumped out at me was the breadth of things that had to be in place to get a Cloud environment up and running. Windows, Linux, Web Servers, multiple Databases. This isn’t uncommon for any Cloud Management Platform (CMP) – OpenStack, CloudStack, etc. – and would typically require teams with a variety of skills to coordinate putting getting this configured properly.
- 20 Management servers: 2x vCenter, 2x DB servers for vCenter/vCloud/vChargeback, 2x vCloud Cells, 2x vCNS Manager, 2x DB for vCAC, 2x WebServers for vCAC, 2x vCAC DEM Orchestrators, 2x vCAC DEM Workers, 2x vCAC Agent Machines, 1x vChargeback server, 1x vCO
- 8 Databases: 2x vCenter Update Service, 2x vCenter, 1 vCloud, 1 vCAC, 1 vChargeback, 1x vCO
- 7 Management Interfaces: 2x vCenter, vCloud, vCNS, vChargeback, vCAC, vCO
And again last week, Gartner analyst Alessandro Perilli (@a_perilli) tweeted:
Cloud management platform vendors should seriously consider a SaaS delivery model. Today’s solutions too complex to deploy, scale, expand.
— Alessandro Perilli (@a_perilli) June 3, 2013
Perilli is one of many people at Gartner that covers the Cloud Management Platform space, so he gets to see the breadth of offerings in the market from many vendors.
So this ultimately begs the question, “Should Cloud Management be delivered as a SaaS application?” Continued »
Remember “Cloud in a Box”? It has come in various iterations over the past 4-5 years:
- “Pre-Defined” or “Pre-Validated” all-in-one racks of equipment
- Hardware Reference Architectures
- Hardware + Software Reference Architectures
- Software-Only Design Docs that are “hardware agnostic”
Lots of vendors or systems integrators have promised to deliver a cloud to their customers in a pre-defined package, but it is typically missing one critical component – OPERATIONS. And when you think about it, the operational model is cloud computing, so it begs the question – are cloud operations transferable?
Recently GigaOm wrote about the latest round of Cloud Providers trying to bring their version of cloud to a new set of customers. Others have tried this or are currently using a similar strategy for both IaaS or PaaS platforms, including Apprenda, Joyent, Rackspace, Virtustream, and VMware (both CloudFoundry and vCloud).
While operations does include elements of technology, the vast majority is driven by people skills and company specific processes. This is why you’ll see cloud pioneers like Netflix open-source many of their internal tools, or Rackspace give up leadership in OpenStack to the OpenStack Community, because their expertise and learning-curve advantages are in the operations of their cloud environments. The AWS APIs are open (documented), but they don’t expose much of their internal operations.
But what makes the operations so difficult to transfer? Continued »
An interesting discussion took place on Twitter yesterday, spurred by one of my favorite industry analysts (Simon Wardley, @swardley). I’ve written about his ideas, analysis and outstanding blog before.
While it was an excellent discussion and did surface a few fringe industries that might fall into this category (undertaker, local hair-salon, etc.), the general consensus was that every business today is essentially a tech business. While it’s fairly easy to highlight this with companies where technology is their core product (eg. Netflix, Facebook, etc.), it’s also not difficult to see how technology is core to businesses that don’t make technology-centric products (eg. tractors or farm equipment).
For example, if you’re John Deere (just an example, don’t have insider information on their operations), you obviously have a complex supply-chain in place to be able to pull together all the elements that make up a tractor. They also need sophisticated analytics systems to be able to forecast sales, costs of raw materials, currency exchanges and other macro-level things that could be effected by the economy, government policy, etc. Then within the tractors, there is an ecosystem building around tools and applications that can help farmers better manage their fields. Somewhere all the data being collected could be creating new “big data” knowledge that could be improving crop yields, fuel efficiency of tractors, etc.
When I think about “transforming IT”, I tend to think about the adoption of new technologies, reducing costs and improving worker productivity.
When I think about “transforming the product/ecosystem”, I tend to think about making data accessible to open APIs, or expanding areas where value can be added to a product (customization, etc.).
When I think about “transforming the business”, I tend to think about using technology to eliminate an element of the existing supply chain. Netflix is a great example of this (remove the need to obtain physical media at a store or kiosk). iTunes is another great example (remember record stores??). Sports has been going through this for the last 10-15 years. But it’s harder to think of examples of these types of transformations where the business isn’t entirely based around technology. It does create some blurred likes, such as how Bechtel is using technology to enhance how they manage contractor relationships and project management.
So this is one of those areas where definitions might actually be more of a hinderance than a structure to help companies understand how to plan for transitions or transformations. Regardless of what definitions people use, I’d suggest that there are a few areas that need serious consideration:
- Do you understand your supply chain and have you gone back and examined it lately with an eye towards how technology (or technology partners) might be able to help reduce links? Have you looked at how new technology could enhance the existing portfolio? [Example: With airlines struggling so much, why haven’t any of them leveraged their footprint at major airports + telepresence technologies to create augmentations for the output of a large percentage of travel – business meetings?]
- Do you understand the potential ecosystem that could be created around your business, your product or (most importantly) your data? We explored the data element on the podcast. This is actually another variant of the supply-chain discussion, but it involves thinking about the value-chain for the business and considering the opening of new doors and some loss of control of the outcome.
- Can you build a better mousetrap? Most people thought Apple was crazy to begin building physical stores when the Internet had proven that brick & mortar business was dead. But they just did retail better than everyone else on the planet. They drew a direct line from the customer’s experience (which involved convenience, repair, physical touch/feel) and aligned it to their goals (don’t sell as massive discounts). Zappos took a similar approach with low-margin shoes – focus on the experience and inconvenience of the past and leverage technology to solve those customer pain points.
- Can you measure every element of the business, not just the things that are reported on the financial reports? Do you understand the things that influence the direct results or the buying process or satisfaction levels? Given that every aspect of our lives is now recorded digitally, there is an extremely good chance that the information is available (directly or through external services).
- The underlying technology is obviously important, but as we’ve seen time and time again, it’s the process and people that need to embrace the change more than the technology. Technology change/transformation is a given. It might take 5yrs or 10yrs, but it’ll happen. Process and business model change doesn’t have EoL dates, it has Chapter 11.
So as usual, Simon Wardley is right about this. But the question becomes, are you transforming technology or transforming how the business leverages technology. They aren’t the same, no matter how many times companies tell you the CIO deserves a table with the decision makers in the company.
I’ve written before that I’m not entirely convinced that the “Build Your Own Cloud” movement is going to be entirely successful, especially if the goal is to enable IT as a Service instead of just virtualizing applications (or the network, or storage, or whatever is the newest Software-Defined *). The amount of change needed to get to the operational state of IT as a Service is just massive, and the majority of it has very little to do with new technology. It breaks ITIL. It breaks existing technology silos in IT. It breaks the current IT budgeting models. And it involves the intersection of change and people, which we all know an have a few challenges.
But as a good disciple of Cloud Computing, I went and read Gene Kim’s excellent book on DevOps, The Phoenix Project. We also had him on the podcast. Travel permitting, I attend the excellent sessions at the Triangle DevOps meetups, run by a bunch of people that do DevOps stuff everyday (operationally or developing products like Chef, Ansible, etc.). When possible, we grab some of them for the podcast as well.
So here’s where I keep seeing the disconnect. For a while, the discussion about Enterprise Cloud was always focused around Private Cloud, which often times meant something using VMware vSphere (and maybe vCloud Director). But when I listen to all the people doing DevOps today, it’s rarely on VMware (or even VM-based) environments, it’s almost entirely using various Linux-based tools and packages. and it’s primarily for web-based or web-facing applications. Not the things you’d typically associate with IT-supplied applications. We explored this a while ago, but I don’t know if it’s changed much, even with things like Windows support being added to tools like Puppet. Continued »
Back in 2007-2008, when the concept of “Private Cloud” began to emerge as a DIY model for evolving IT, there was concern that companies would be locked into a Public-Only or Private-Only decision. Given the maturity of the technologies and IT skills at the time, this created a strategic problem. But then, like a double rainbow made of Skittles and fruity drinks, the concept of “Hybrid Cloud” magically appeared as the unicorn that would provide “the best of both worlds” for long-term IT strategy.
- “Own the Base and Rent the Spike”
- “Application migration”
- “Application Portability”
- “Avoid Lock-in’
Pick your favorite slogan, they were all there. Throw in the ability to dynamically migrate workloads between physical locations and there was a frenzy of excitement over the possibilities of a Hybrid environment.
And then reality set in and people began to realize that the limitations far outweighed the possibilities. Limited Bandwidth. Security Concerns. Ownership Issues. Consistency of Operations. Early offerings such as Amazon AWS could provide a VPC (Virtual Private Cloud), but it had limitations (or “wish-lists“). CloudSwitch did some cool things (since acquired by Verizon/Terremark), but it was cloaked in a security story and hence didn’t get as much visibility as it could have from “Cloud Architects” at the time.
It also led to an explosion of definitions of Hybrid Cloud, mostly to match the needs of a vendor selling their HW/SW, or an Enterprise Architect trying to justify their design to their CIO. Either way, it’s evolved to where Hybrid Cloud can mean any mix of offerings or architectures where the resources and applications are both on-premise and off-premise. And if I squint my eyes just right, my borrowed concept of “Cloud Concierge” might even fit one of these definitions.
Fast forward to 2013 and we’re beginning to see a new set of Hybrid Cloud offerings emerge that are backed by both evolving technology and vendors large and small. They tend to fall into these categories: Continued »