Straddling the firewall: cloud from 2010 to 2020 (& what to do next)

I gave the ten year anniversary talk at the CloudAustin meetup. Ten years ago, I gave the first talk. Here’s a bit of the essay I wrote out as I was working on the presentation.

I want to go over the last ten years of cloud, since I gave the first talk at this meetup, back in August 2010. At the time, I was wrapping up my stint at RedMonk, though I didn’t know that until a year later. I went to work at Dell in corporate strategy, helping build the software and cloud strategies and businesses. I went back to being an analyst at 451 Research where I ran to software infrastructure team, and then thanks to my friend, Andrew Shafer, ended up where I am now, at Pivotal, now VMware. I also have three kids. And a dog. And live in Amsterdam.

Staying grounded.

Beware, I still have to pay my bills

Pic: Kadumago, Nov 2019.

You should know that I have biases. I have experiences, ideas, “facts” even that come from that bias. I work at VMware, “VMware Tanzu” to be specific which is VMware’s focus on developers and the enterprise software they write. I’ve always worked on that kind of thing, and often in the interests of “on-premises” IT.

Indeed, at the end, I’m going to tell you that developers are what’s important – in fact, that Tanzu stuff is well positioned for the future I think should exist.

So, you know…whatever. As I used to say at RedMonk: “disclaimer.”

Computers from an outlet

Back in 2013, when I was at Dell, I went on an analyst tour in New England. Matt Baker and I visited IDC, Gartner, Forrester, and some smaller shops in hotel lobbies and fancy restaurants. These kind of analyst meetings are a bit dog and pony, but they give you a survey of what’s going on and a chance to tell analysts what you think reality looks like.

Anyhow, we walked into the Forrester office, a building that was all brand new and optimistic. Some high-level person there way into guitars and, I don’t know, 70’s rock. Along with Forrester branded ballpoint pens, they gave us The Allman Brothers’s at Fillmore East CDs as thank you gifts. For real. (Seriously.) Conferences room names were all rock-and-roll. They had an electric guitar in the lobby. Forrester: not the golden buttoned boating jackets of Gartner, or the short-sleeved button-up white shirts of Yankee-frugal IDC.

Being at Dell, we were interested in knowing one thing: when, and even if, and at what rate, will the on-premises market succumb to public cloud. That’s all any existing vendor wanted to know in the past decade. That’s what that decade was all about: exploring the theory that public cloud would take over on-premises IT.

The Forrester people obliged. The room was full of about 8 or 10 analysts, and the Forrester sales rep. When a big accoiunt like Dell comes to call, you bring a big posse. Almost before Matt could finish saying the word “cloud,” a great debated emerged between two sides of analysts. There were raised voices, gesticulating, and listing back and forth in $800 springy, office chairs. All while Matt and I sort of just sat there listening like a call-center operator who uses long waits for people to pick up the phone as a moment of silence and calm.

All IT will be like this outlet here, just a utility, one analyst kept insisting. No, it’ll be more balanced, both on-premises and in cloud over time, another said. I’d never encountered an analyst so adamant about public cloud, esp. in 2013. It seemed like they were about to spring across the table and throttle their analyst opponent. I’m sure time ran out before anyone had a chance to whiteboard a good argument. Matt and I, entertained, exchanged cards, shook hands, and left with our new Allman Brother’s album.

Public cloud has been slower to gobble up on-premises IT than fanatics thought it would be, even in the late 2000’s. The on-premises vendors deployed an endless amount of FUD-chaff against moving to public cloud. That fear of the new and unknown slowed things down, to be sure.

But I think more practical matters are what keeps on-premises IT alive, even useful. We used to talk about “data gravity” as the thing holding migrations to public cloud back. All that existing data can’t be easily moved to the cloud, and new apps will just be throwing off tons of new data, so that’ll just pull you down more. (I always though, you know, that you could just go to CostCo and buy a few hard-drives, run an xcopy command overnight, and then FedEx the drives to The Cloud. I’m sure there’s some CAP theorem problem there – maybe an Oracle EULA violation?) But as I’ll get to, I think there’s just tech debt gravity – probably a 5 to 10 million applications[1] that run the world that just can’t crawl out of on-premises datacenters. These apps are just hard to migrate, and sometimes they work well enough at good enough cost, that there’s no business case to move them.

Public cloud grows and grows

But, back to public cloud. If we look at it by revenue, it’s clear that cloud has been successful and is used a lot.

[Being respectful of analyst’s work, the reader is asked to open up Gartner’s Nov 13th press release, entitled “Gartner Forecasts Worldwide Public Cloud Revenue to Grow 17% in 2020” and look at the table there. You can find charts as well. Be sure to add up the SaaS-y categories into just one.]

As with all such charts, this is more a fanciful illustration of our instincts. Charts are a way to turn hunches into numbers, transform the qualitative into the quantitative. You can use an even older forecast (also, see the chart…and be sure to take out “advertising,” obviously) to go all the way back to 2010. As such, don’t get hung up on the exact numbers here.

The direction and general sizing in these lines is what matters. SaaS is estimated at $176 billion in 2020, PaaS $39.7 billion, IaaS at $50b.

So. Lots of revenue there. There are a few things to draw from this chart – again, hunches that we can gussy up into charts:

  1. The categorization of SaaS, PaaS, and IaaS stuck. This was finalized in some NIST work, and if you can believe it, categorizing things like this drove a lot of discussion. I participated in at least three of those exercises, at RedMonk, Dell, and then at 451 Research. Probably more! There was a lot of talk about “bursting” and “hybrid cloud.” Traditional IT, versus private cloud. Is it “on-prem” or “on-premises” – and what does it say of your moral character is you incorrectly use the first? Whatever. We returned to the simplicity of apps, devs, and ops.
  2. SaaS is sort of “forgotten” now as a cloud thing. It looms so large that we can’t even see it when we narrow our focus on the other two parts of cloud. Us in the dev and ops crowds just think of SaaS as normal now, not part of this wild, new category of “cloud.” Everyday, maybe even every hour we all use SaaS – the same is true for enterprises. Salesforce’s revenue went from $1.3bn in 2010 to $17.1bn in 2020. We now debate Office 365 vs. GMail, never Exchange. SaaS is the huge winner. Though it’s sort of not in my interests, when people talk about cloud and digital transformation, I tell them that the most useful thing they should probably focus on is just going all SaaS. You see this with all the remote working stuff now – all those firewalls and SharePoints on intranets are annoying, and supporting your entire company working from home requires the performance and scaling of a big time SaaS company. SaaS is what’s normal, so we don’t even think about it anymore.
  3. Below that, is PaaS. The strange, much maligned layer over the decade. We’re always optimistic about PaaS, as you can see in the newer forecast. It doesn’t seem to deliver on that optimism, at least in the mainstream. I certainly hope it will, and think it should. We’ll see this time. I’ve lived through enough phases of PaaS optimism and re-invention (well, all of them, I suppose) that I’m cautious. To be cynical to be optimistic, as I like to quip: it’s only stupid until it works. I’ll return to the glorious future PaaS in a bit. But first…
  4. Below that, we have IaaS – what us tech people think of mostly as cloud. This is just a big pool of hardware and networking. Maybe some systems management and security services if you consider that “infrastructure.” I don’t know. Pretty boring. However, if you’re not buying PaaS, this is the core of what you’re buying: just a new datacenter, managed by someone else. “Just” is insulting. That managed by someone else is everything for public cloud. You take this raw infrastructure, and you put your stuff on it. Forklift your applications, they say, deploy new applications. This is your “datacenter” in the cloud and the way most people think about “cloud” now-a-days: long rows of blinking lights in dark warehouses sometimes with rainbow colored pipes.

IT can’t matter fast enough

Let’s get back to the central question of the past decade: when will public cloud eclipse on-premises IT?

First, let’s set aside the nuance of “private cloud” versus “traditional IT” and just think of it all as “on-premises.” This matters a lot because the nature of the vendors and the nature of the work that IT does changes if you build and manage IT on your own, inside the firewall. The technology matters, but the responsibility and costs for running and maintaining it year after year, decade after decade turns into the biggest, er, headache. It’s that debate from Forrester people: when will IT become that wall outlet that Nicholas Carr predicted long ago? When will IT become a fungible resource that people can shed when all those blinking lights start holding back their business ambitions?

What we were hunting for in the past ten years was a sudden switch over like this, the complete domination of mobile over PCs:

The Dediu Cliff.  Source: “The rise and fall of personal computing,” Jan 2012, Horace Dediu.

This is one of the most brilliant and useful strategy charts you’ll ever see. It shows how you need to look at technology changes, market share changes. Markets are changed by a new entrant that’s solving the same problems for customers, the jobs to be done, but in a different way that’s ignored by the incumbents.[2] This is sort of big “D,” Disruption theory, but more inclusive. Apple isn’t an ankle biter slowly scaling up the legs of Microsoft, they’re a seasoned, monied incumbent, just “re-defining” the market.[3]

Anyhow, what we want is a chart like this for cloud so that we can find when on-premises crests and we need to start focusing on public cloud. Rather, a few years before that so we have plenty of time to invest and shift.  When I did strategy at Dell, Seth Feder kept up this chart for us. He did great work – he was always talking about how good the “R squared” was – I still don’t know what that means, but he seemed happy with it. I wish I could share his charts, but they’re lost to Dell NDAs and shredders. Thankfully, IDC has a good enough proxy, hardware spend on both sides of the firewall:

[The reader is asked to open IDC’s April 2nd, 2020 press release titled “Cloud IT Infrastructure Spending Grew 12.4% in the Fourth Quarter, Bringing Total 2019 Growth into Positive Territory, According to IDC” and contemplate the third chart therein.]

You can’t use this as a perfect guide – it’s just hardware, and, really can you tell when hardware is used for “private cloud” versus “traditional IT”? And, beyond IaaS, we’d like to see this for the other two aaS’s: applications and developers. If only we had Seth still toiling away on his charts for the past decade.

But, once again, a chart illustrates our hunch: cloud is Hemingway’s bankruptcy thing, slowly racing towards a Dediu Cliff. We still don’t know when on-premises compute will suddenly drop, but we should expect it…any year now…

…or decade…

…I guess.  

¯\_(ツ)_/¯

Pre-cliff jumpers

Competition in cloud was fierce. Again, I’m leaving out SaaS – not my area, don’t have time or data. But let’s look at infrastructure, IaaS.

[The reader is asked to open up the 2010 IaaS MQ and the 2020 IaaS MQ.]

It’s worth putting these charts side-by-side. They’re Gartner Magic Quadrants, of course. As with all charts, you can hopefully predict me saying, they illustrate our intuitions. What’s magical (yes!) about the MQ’s is that they show a mixture of sentiment, understanding, and actual feature set. You can see that in play here as we figured out what cloud was.

Infamously, the first IaaS MQ in 2010 has Amazon in the lower right, and a bunch of “enterprise grade” IaaS people up and to the right. Most of us snickered at and were confused by this. But, that 2010 list and ranking reflected how people, esp. big corporate buyers were thinking about what they wanted cloud to be. They wanted it to be like what they knew and were certain they needed, but run by someone else with that capex-to-opex pixie dust people used to obsesses so much about.

Over the next ten years, everyone figured out what public cloud actually was: something different, more or less. Cloud was untethered from those “enterprise grade” expectations. In fact, most companies don’t want “enterprise grade” anymore, it’s not good enough. They want “cloud grade.” Everyone wants to “run like Google,” do DevOps and SRE. Enterprise buyers are no longer focused on continuing with what they have: they want something different.

All those missing dots are the vendors who lost out. There were many, many reasons. The most common initial was, well, “server hugging.” Just a biased belief in on-premises IT because that’s where all the vendor’s money had always came from. People don’t change much after their initial few decades, enterprises even less.[4]

The most interesting sidebars here are Microsoft and Rackspace. Microsoft shed it’s Windows focus and embraced the Linux and open source stack of cloud. Rackspace tried a pre-kubernetes Kubernetes you kids may not remember, OpenStack. I’m hoping one day there’s a real raucous oral account of OpenStack. There’s an amazing history in there that we in the industry could learn from.

But, the real reason for this winnowing is money, pure and simple.

Disruptors need not apply

You have to be large to be a public cloud. You have to spend billions of dollars, every year, for a long time. Charles Fitzgerald has illustrated this over the years:

It costs a lot to save you so much. Source: “Follow the CAPEX: Cloud Table Stakes 2018 Edition,” Charles Fitzgerald, February 2019.

Most of the orange dots from 2010 just didn’t want to do this: spend billions of dollars. I talked with many of them over the past ten years. They just couldn’t wrap their head around it. We didn’t even know it cost that much, really. Instead, those orange dots fell back on what they knew, tying to differentiate with those “enterprise grade” features. Even if they wanted to and did triy, they didn’t have the billions in cash that Amazon, Microsoft, and Google had. Disruption is nice, but an endless cash-gun is better.

I mean, for example, what was Dotcloud going to do in the face of this? IBM tried several times, had all sorts of stuff in its portfolio, even acquiring its way in with SoftLayer – but I think they got distracted by “Watson” and “Smart Cities.” Was Rackspace ever going to have access to that much money? (No. And in fact, they went private for four years to re-work themselves back into a managed service provider, but all “multi-cloud” now.)

There are three public clouds. The rest of us just sell software into that. That’s, more less, exactly what all the incumbents feared as they kept stacking servers in enterprise datacenters: being at the whim of a handful of cloud providers, just selling adornments.

$80bn in adornments

Source: “Investing City” on Seeking Alpha, originally from Pivotal IPO investor presentation.

While the window for grabbing public cloud profits might have closed, there’s still what you do with all that IaaS, how you migrate your decades of IT to and fro, and what you do with all the “left overs.” There’s plenty of mainframe-like, Microfocus-y and Computer Associates type of revenue to eek out of on-premises, forever.

Let’s look at “developers,” though. That word – developers – means a lot of things to people. What I mean, here, is people writing all those applications that organizations (mostly large ones) write and run on their own. When I talk about “developers,” I more mean whatever people are in charge of writing and running an enterprises (to use that word very purposefully) custom-written software.

Back when Pivotal filed to IPO in March of 2018, we estimated that the market for all of that would be $80.4bn, across PaaS and on-premises.

This brings us back to PaaS. No one says “PaaS” anymore, and the phrase is a bit too narrow. I want to suggest, sort of, that we stop obsessing over that narrow definition, and instead focus on enterprise developers and in-house software. That’s the stuff that will be installed on, running on, and taking advantage of cloud over the next ten years. With that wider scope, an $80bn market doesn’t seem too far fetched.

And it’s real: organizations desperately want to get good at software. They’ve said this for many years, first fearing robot dogs – Google, Amazon. AirBnB, Tesla…whatever. After years of robot dog FUD, they’ve gotten wiser. Sure, they need to be competitive, but really modernizing their software is just table stakes now to stay alive and grow.

What’s exciting, is that organizations actually believe this now and understand software enough to understand that they need to be good at it.

Source: “Improving Customer Experience And Revenue Starts With The App Portfolio,” Forrester Consulting, commissioned by VMware, March, 2020.

We in IT might finally get what we want sometime soon: people actually asking us to help them. Maybe even valuing what we can deliver when we do software well.

Beyond the blinking cursor

Obsessing over that Dediu Cliff for cloud is important, but no matter when it happens, we’ll still have to actually do something with all those servers, in the public cloud or our own datacenters. We’ve gotten really good at building blinking cursor boxes over the past ten years. Blinking cursor boxes

IT people things: developers write code, operations people put together systems. They also have shaky budgets – most organizations are not eager to spend money on IT. This often means IT people are willingly forced to tinker with building their own software and systems rather than purchasing and reusing others.[5] They love building blinking cursor boxes instead of focusing on moving pixels on the screen.

A blinking cursor box is yet another iteration of the basic infrastructure needed to run applications. Applications are, of course, the software that actually moves pixels around the screen: the apps people use to order groceries, approve loan applications, and other thrilling adventures in computing. Applications are the things that actually, like, are useful…that we should focus. But, instead, we’re hypnotized by that pulsing line on a blank screen.

Us vendors don’t help the situation. We compete and sell blinking cursor boxes! So we each try to make one, constantly. Often a team of people makes one blinking cursor box, gets upset at the company they work for, grabs a bunch of VC money, and then goes and makes another blinking cursor box. So many blinking cursors. The public clouds are, of course, big blinking cursor boxes. There was a strange time when Eucalyptus tried fight this trend and to do a sort of Turing Test on the Amazon’s blinking cursor. That didn’t go well for the smaller company. Despite that, slowly, slowly us vendors have gotten closer to a blinking cursor layer of abstraction. We’re kind of controlling our predilections here. It seems to be going well.

Month 13: now, the real work can begin.

Over the past ten years, we’ve seen many blinking cursor boxes come and go: OpenStack, Docker, “The Datacenter of the Future,” and now (hopefully not going) Kubernetes. (There was also still virtualization, Windows, Linux, and mainframes. Probably some AS/400s if we dig around deep enough.) Each of these new blinking cursor boxes had fine intentions to improve on the previous blinking cursor boxes. These boxes are also open source, meaning that theoretically IT people in organizations could download the code, build and configure their own blinking cursor boxes, all without having to pay vendors. This sometimes works, but more often than not what I hear of are 12 month or more projects to stand up the blinking cursor box du jour…that don’t even manage to get the cursor blinking. The screen is just blank.

In larger organizations, there are usually multiple blinking cursor box programs in place, doubling, even tripling that time and money burn. These efforts often fail, costing both time and millions in staff compensation. An almost worse effect is when one or more of the efforts succeeds, kicking off another year of in-fighting between competing sub-organizations about which blinking cursor box should be the new corporate standard. People seem to accept such large-scale, absurdly wasteful corporate hijinks – they probably have more important things to focus on like global plagues, supply chain issues, or, like, the color palette of their new logo.

As an industry, we have to get over this desire to build new blinking cursor boxes every five or so years, both at vendors and enterprises. At the very least we should collaborate more: that seems to be the case with Kubernetes, finally.

Even in a world where vendors finally standardize on a blinking cursor box, the much more harmful problem is enterprises building and running their own blinking cursor boxes. Think, again, of how many large organizations there are in the world, F500, G2,000 – whatever index you want to use. And think of all the time and effort put in for a year to get a blinking cursor box (now, probably Kubernetes) installed from scratch. Then think of the need in three months to update to a new version; six months at the longest, or you’ll get trapped like people did in the OpenStack year and next thing you know it, running a blinking cursor box from the Victorian era. Then think of the effect to add in new databases and developer frameworks (then new versions of those!), security, and integrations to other services. And so on. It’s a lot of work, duplicated at least 2,000 times, more when you include those organizations allow themselves to build competing blinking cursor boxes.

Obviously, working for a vendor that sells a blinking cursor box, I’m biased. At the very least, consider the costs over five to ten years of running your own cloud, essentially. Put in the opportunity cost as well: is that time and money you could instead be spending to do something more useful, like moving pixels around on your customer’s screen?

Once you free up resources from building another blinking cursor box, you can (finally) start focusing on modernizing how you do software. Next: one good place to start.

Best practices, do them

As I’ve looked into how organizations manage to improve how they do software over the years I’ve noticed something. It’ll sound uselessly simple when you read it. Organizations that are doing well follow best practices and use good tools. Organizations that are struggling don’t. This is probably why we call them best practices.

Survey after survey of agile development usage will show this, every year. Simple practices and tools like unit testing are widely followed, but adherence to other practices quickly falls off. How many times have you heard people mention a “sit down stand-up meeting,” or say something like “well, we don’t follow all the agile practices we learned in that five day course – we adapted them to fit us”?

I like to use CI/CD usage as a proxy for how closely people are following best practices.

One of the most important tools people have been struggling to use is continuous integration and continuous delivery (CI/CD[6]). The idea that you can automate the drudgery of building and testing software, continuous integration, is obviously good. The ability to deploy software to production every week, if not daily, is vital staying competitive with new features and getting fast feedback from users on your software’s usefulness.

Very early on, if you’re not doing CI/CD your strategy to improve how you’re doing software – to progress with your cloud strategy, even – is probably going to halt. It’s important! Despite this, for the past ten plus years, usage been poor:

Source: State of Agile Surveys, 3rd through 14th, VersionOne/CollabNet/digital.ai. CI/CD not tracked in 5th/2009. Over the years, definitions change, “delivery” and “deployment” are added; but, these numbers are close enough to other surveys to be useful. See more CI/CD surveys: Forrester survey (2019), DZone CD reports (2014, 2015, 2016, 2017, 2019).

Automating builds and tests with continuous integration is clearly easier (or seen as more valuable?) than continuous delivery. And there’s been an encouraging rise in CD use over the past ten years.

Still, these numbers are not good. Again, think of those thousands of large organizations across the world, and then that half of them are not doing CI, and then that 60% of them are not doing CD. This seems ludicrous. Or, you know, great opportunity for improvement…and all that.

Take a look at what you’re doing – or not doing! – in your organization. Then spend time to make sure you’re following best practices if you want to perform well.

Stagnant apps in new clouds

Over the past ten years, many discussions about cloud centered around technologies and private or public cloud. Was the cloud enterprise grade enough? Would it cost less to run on premises? What about all my data? Something-something-compliance. In recent years, I’ve heard less and less of those conversations. What people worry about now is what they already have: thousands and thousands of existing applications that they want to move to cloud stacks.

To start running their business with software, and start innovating how they do their businesses, they need to get much better at software: be like the “tech companies.” However, most organizations (“most all,” even!) are held back by their existing portfolio of software: they need to modernize those thousands and thousands of existing applications.

Modernizing software isn’t particularly attractive or adventurous. You’re not building something new, driving new business, or always working with new technologies. And when you’re done, it can seem like you’ve ended up with exactly the same thing from the outside. However, management is quickly realizing that maintaining the agility of their existing application portfolio is key if they want future business agility.

In one survey, 76% of senior IT leaders said they were too invested in legacy applications to change. This is an embarrassing situation to be in: no one sets off to be trapped by the successes of yesterday. And, indeed, many of these applications and programs were probably delivered on the promise of being agile and adaptable. And now, well, they’re not. They’re holding back improvement and killing off strategic optionality. Indeed, in another survey on Kubernetes usage, 49% of executives said integrating new and existing technology is the biggest impediment to developer productivity.[7]

After ten years…I think we’ve sort of decided on IaaS, on cloud. And once you’ve got your cloud setup, your biggest challenge to fame and glory is modernizing your applications. Otherwise, you’ll just be sucking up all the same, old, stagnating water into your shiny new cloud.


[1] This is not even an estimate, just a napkin figure. AirFrance-KLM told me they’re modernizing over 2,000 applications. Let’s take the so called Fortune 500, and multiply it out: 500 x 2,000 = 1,000,000. Now, AirFrance-KLM is a big company, but not the biggest by far. A company like JPMC has many more applications. Also, there are governments, militaries, and other large organizations out there beyond the F500. Or you could have started with the Global 2,000. So, let’s assume that there are “millions” of apps out there. (Footnote to footnote: what is an “app”? If you’re asking this, let’s call it a “workload” and see if that satisfies you enough to go back to the main text.)

[2] Yes, yes – this isn’t strictly true. Taking out costs can change markets because you’ve freed up so much cash-flow, lowered prices, etc. There’s “globalization.” Regulations can dramatically change things (AT&T, unbundling, abdicating moral responsibility in publishing, etc.). Unexpected, black swans can destroy fragile parts of the market, table-flipping everything. And more what have you’s &co.’s. Thank you for your feedback; we appreciate your business; this call will now disconnect.

[3] For more on how to use this kind of chart in the strategy world, see Rita McGrath’s books, most recently, Seeing Around Corners.

[4] Some years ago, it was popular to cite such studies as “at the current churn rate, about half of S&P 500 companies will be replaced over the next ten years.” I, dear reader, have been guilty of using such weird mental gymnastics, a sort of Sugar Rush grade, neon-track of logic. (Also, there’s private equity, M&A, the 2008 financial collapse, globalism, cranky CEOs, and all manner of other things that change that list regardless of the, well, business acumen of the victims – pouring gasoline onto the scales of the fires of creative destruction.)

[5] Public cloud has been an interesting inroad against this: you have to pay for public cloud, there’s no way around it. Still, people seem to like it more than paying larger, upfront software licensing fees. In public cloud, the initial process is often much more pleasant than a traditional acquisition process. The sales process of signing up without talking to a person, testing out the software, using it for real…all without having to setup servers, networking, install and upgrade software.

[6] There’s a lot of hair-splitting between “continuous delivery” versus “continuous deployment.” I don’t know. At a certain level of organizational management, the distinction becomes less useful than spending your mental effort on more pressing strategic and management riddles. I think it’s notable, that the jargon we use is “CI/CD” not “CI/CD/CD” (or maybe, more delightfully, CI/CD2?)

[7] I’m fond of citing this survey for another reason that shows how misaligned executive and developer believes can be: 29% of developers said that “Access to infrastructure is the biggest impediment to developer productivity”…but only 6% of executives agreed.

🗂 Link: VMware plan elevates Kubernetes to star enterprise status

A swag at how many new apps will be created to run on kubernetes cloud stuff. I assume this is actually existing, modernized apps and net-new ones despite the wording:

VMware says that from 2018 to 2023 – with new tools/platforms, more developers, agile methods, and lots of code reuse – 500 million new logical apps will be created serving the needs of many application types and spanning all types of environments.

Source: VMware plan elevates Kubernetes to star enterprise status

🗂 Link: Spending on Customer Experience Technologies Will Reach $641 Billion in 2022, According to New IDC Spending Guide

Worldwide spending on customer experience (CX) technologies will total $508 billion in 2019, an increase of 7.9% over 2018, according to the inaugural Worldwide Semiannual Customer Experience Spending Guide from International Data Corporation (IDC). As companies focus on meeting the expectations of customers and providing a differentiated customer experience, IDC expects CX spending to achieve a compound annual growth rate (CAGR) of 8.2% over the 2018-2022 forecast period, reaching $641 billion in 2022.

Source: Spending on Customer Experience Technologies Will Reach $641 Billion in 2022, According to New IDC Spending Guide

🗂 Link: Application Development Research Predicts Low-Code Tooling Takeover

“By 2024, three-quarters of large enterprises will be using at least four low-code development tools for both IT application development and citizen development initiatives,” the report said. “By 2024, low-code application development will be responsible for more than 65 percent of application development activity.”

Source: Application Development Research Predicts Low-Code Tooling Takeover

Link: Gartner: IT spending to hit $3.7 trillion thanks to record 6.2% growth in 2018

“This is the highest annual growth rate that Gartner has forecast since 2007 and would be a sign of a new cycle of IT growth,” said John-David Lovelock, a research vice president at Gartner. “However, spending on IT around the world is growing at expected levels and is in line with expected global economic growth. Through 2018 and 2019, the U.S. dollar is expected to trend stronger while enduring tremendous volatility due to the uncertain political environment, the North American Free Trade Agreement renegotiation and the potential for trade wars.”
Original source: Gartner: IT spending to hit $3.7 trillion thanks to record 6.2% growth in 2018

Link: Worldwide Spending on Security Solutions Forecast to Reach $91 Billion in 2018, According to a New IDC Spending Guide

“Worldwide spending on security-related hardware, software, and services is forecast to reach $91.4 billion in 2018, an increase of 10.2% over the amount spent in 2017.” Also, a breakdown of spending per industry and type of security product.
Original source: Worldwide Spending on Security Solutions Forecast to Reach $91 Billion in 2018, According to a New IDC Spending Guide

Link: Worldwide SMB IT Spending to Pass $600 Billion in 2018, Driven by Mid-Market Demand for Software and Services, According to IDC

For companies under 1,000 people, IDC “forecasts total IT spending by small and medium-size businesses (SMBs) to be nearly $602 billion in 2018, an increase of 4.9% over 2017. With a compound annual growth rate (CAGR) of 4.7% for the 2016-2021 forecast period, spending by businesses with fewer than 1,000 employees on IT hardware, software, and services, including business services, is expected to reach $684 billion on in 2021.”
Original source: Worldwide SMB IT Spending to Pass $600 Billion in 2018, Driven by Mid-Market Demand for Software and Services, According to IDC

Link: Ordering from voice tubes

“Purchases made through devices such as Google Home and Amazon’s Echo are projected to leap from $2 billion to $40 billion by 2022 as technology improves, U.S. consumers become more comfortable and the speakers become nearly as commonplace in homes as a flat-screen TV, according to a new study from OC&C Strategy Consultants.”

More:

“Shoppers are more apt to buy cheaper items, such as phone charger cables, via voice. The average online basket was $661 for online purchases of electronics, compared with $239 for voice orders, OC&C said. “
Original source: Ordering from voice tubes

Link: Largest insurers plan biggest IT budget increases

“Thirty-six percent of those reported premium over $1 billion per year; those companies also said they planned to increase IT budgets by about 11% on average. Carriers between $500 million and $1 billion in premium plan an average increase of 5%.”
Original source: Largest insurers plan biggest IT budget increases

Link: Worldwide Public Cloud Services Spending Forecast to Reach $160 Billion This Year, According to IDC

Includes an interesting chart that lists the types of services/features (like data management and appdev platforms) that compose vendor revenue. Plus geographic and vertical rankings. But, just a press release.
Original source: Worldwide Public Cloud Services Spending Forecast to Reach $160 Billion This Year, According to IDC

OpenStack Continues to Grow Both Public and Private Cloud Deployments

Four years ago, in October 2013, 451 Research reported that OpenStack cloud revenues were approximately $600 million in 2013. In April 2016, 451 Research reported that 2015 OpenStack ecosystem revenues came in at $1.2 billion, with a forecast to grow to $3.37 billion by 2018.

Now in November 2017, 451 Research is out with it latest OpenStack market sizing report, estimating 2017 OpenStack ecosystem revenue at $2.6 billion. Looking forward, 451 Research is forecasting that OpenStack market revenues will reach $6.7 billion by 2021

Source: OpenStack Continues to Grow Both Public and Private Cloud Deployments

Spending from outside of the IT department

Corporate departments outside of the IT department, globally, are forecast to spend $609bn in 2017:

A new update to the Worldwide Semiannual IT Spending Guide: Line of Business from the International Data Corporation (IDC) forecasts worldwide corporate IT spending funded by non-IT business units will reach $609 billion in 2017, an increase of 5.9% over 2016. The Spending Guide, which quantifies the purchasing power of line of business (LoB) technology buyers by providing a detailed examination of where the funding for a variety of IT purchases originates, also forecasts LoB spending to achieve a compound annual growth rate (CAGR) of 5.9% over the 2015-2020 forecast period. In comparison, technology spending by IT buyers is forecast to have a five-year CAGR of 2.3%. By 2020, IDC expects LoB technology spending to be nearly equal to that of the IT organization.

Meanwhile, all in, global IT spend was estimated at $2.4tn in 2016, but that includes telco and consumer tech. And, this demographic breakdown for enterprise IT spend:

In terms of company size, more than 45% of all IT spending worldwide will come from very large businesses (more than 1,000 employees) while the small office category (the 70-plus million small businesses with 1-9 employees) will provide roughly one quarter of all IT spending throughout the forecast period. Medium (100-499 employees) and large (500-999 employees) business will see the fastest growth in IT spending, each with a CAGR of 4.4%.

Sources: Technology Purchases from Line of Business Budgets Forecast to Grow Faster Than Purchases Funded by the IT Organization, According to IDC, March 2017 and Worldwide IT Spending Forecast to Reach $2.7 Trillion in 2020 Led by Financial Services, Manufacturing, and Healthcare, According to IDC, Aug 2016.

Oracle acquiring Apiary, API design for the $660m (in 2020) API market

As for Oracle, the enterprise software vendor wants to use Apiary’s technology set to make its existing API Integration Cloud more robust. Oracle’s API product focuses primarily on services that help companies monetize and analyze APIs. Apiary provides more of a front-end platform for designing, creating and governing APIs. From Natalie Gagliordi f at ZDnet

From CrunchBase:

  • $8.55M in funding, over three rounds
  • Founded April, 2011.

Apigee was acquired, by Google, last year for $625m. Of course, they were public with (let’s hazard a guess) many, many more customers and revenue: $92.03m in FY2016, to be exact.

Back in September 2015, Carl Lehmann at 451 Research said they had 33 employees (up from 22 in Dec 2014) and estimated their revenue at $2-3m. Carl says, now, it’s “likely below $5m in annual revenue.”

What Apiary does

Apiary’s promise is to be quick and easy when it comes to managing the full life-cycle of API design. As their CEO, Jakub Nesetril, put it when I interviewed him in 2015:

It all starts with that first meeting when you’re thinking about building an API and you’re either kind of, you know, you’re inside meeting room ideating on a white board and then taking a photo of it and sending it to a co-worker, or summarizing it down into an email and sending it down to somebody else, saying hey, I just thought would could build something like this. That white board should be. And, if you do that it becomes, you know, we do a lot to try to make it super simple. We have a language that is like really, really simple for developers to write and we can write down a quick API in five minutes. It’s marked down, it’s like very organic, it’s very simple for developers.

What it creates for you, is creates this kind of common space, common language kind of when you talk about it that’s machine readable, human writable so it’s super simple but it’s also machine writable, and machine readable. The important aspect of it is that we take your white board, we take your … we build a language that we have API blue prints. It’s a… We take that API blueprint and we immediately create a API prototype, the moment you hit your first button. So, from day one when you’ve proposed your first API idea, your first resource you know, your first data structure. You have an API that’s sitting out there on the internet, somebody can query it and guess what, if they decide that the API is broken, that they would like to have a different resource, they would like to change the of a certain data structure, they would like add to it, whatever. They can go in, edit that out, click the save button and boom the API prototype is updated immediately.

Load in some enterprise governance and access controls, and you have something nice and useful. See him explaining more in this 2013 InfoQ interview.

Carl at 451 summarized the meat of what they do back in that 2015 report:

Apiary structures its API lifecycle management platform into five phases. The design phase includes the means to ensure API design consistency using a style guide, a collaborative editor and an approval process. The prototype phase includes productivity capabilities such as auto-generated code and a feedback loop for quality assurance. The implementation phase enables agile-inspired and test-driven development practices, helps deploy server code, and provides for framework integration. The delivery phase includes tools for automated documentation, offers code samples, guides the release of final client code, and offers SDKs. The feedback phase includes debugging, support and usage metrics.

The Money – grabbing part of the $3bn pie

Forrester threw out some API management market-sizing back in June of 2015 (there’s likely something more up-to-date behind their paywall):

We predict US companies alone will spend nearly $3 billion on API management over the next five years. Annual spend will quadruple by the end of the decade, from $140 million in 2014 to $660 million in 2020. International sales will take the global market over the billion dollar mark.

With Oracle’s foot-print in all of enterprise applications and IT (they own Java and share much of the JEE market with IBM), there’s likely some genuine synergies to be had. That is, Oracle could be in a position to boost Apiary sales way above what the tiny company could do on its own.

To be clear, as pointed out above, Apiary doesn’t do all that Apigee does. Apiary is just for the development/design time part of APIs, also providing documentation.

That’s helpful for sure, but I’d guess most of Forrester’s $3bn estimation is likely in actually running and managing APIs. And, in fact, it’s probably more realistic to put Apiary in the development tools/ALM TAM, which is probably in the low, single digit billions. That said, I’m guessing Forrester would put Apiary in their API management bucket; after all, it has “API” in it!

As more background, we talked about the API management market back back when the Apigee acquisition was announced both on Software Defined Talk and Pivotal Conversations.

Link

OpenStack-related business models to exceed $4bn by 2019, 451 Research

New OpenStack market-sizing and -forecast from old pals at 451:

  • Al & Jay say $1.8bn in 2016, going to $5.4bn in 2020.
  • Public cloud dominates now, but is expected to switch – “[public cloud providers are] 49% of total OpenStack revenue in 2015. However, we expect OpenStack private cloud service provider revenue to exceed public cloud providers by 2019.”

How they bucket-ize:

451 Research’s Market Monitor focuses on 56 vendors that provide direct OpenStack offerings, including products, services and turnkey offerings around OpenStack deployment and management, different distributions of OpenStack, service providers and training services. Although we do consider some vendors with integrated hardware, systems and software offerings based on OpenStack, our market-sizing estimate does not include hardware-centric revenue, nor does it include revenue from indirect third-party vendors, such as those in storage or software-defined networking.

Source: OpenStack-related business models to exceed $4bn by 2019

60% of enterprises using or planning to use public IaaS by the end of 2016, IDC

IDC’s IaaS forecast is out, tragically, I don’t have access to it. However, here’s some highlights from the press release:

  • Public IaaS is in wide use “A recent survey of over 6,000 IT organizations found that nearly two thirds of the respondents are either already using or planning to use public cloud IaaS by the end of 2016.”
  • Public IaaS is a large, fast growing market – the overall IaaS market is forecast to grow from $12.6bn in 2015 to $43.6bn in 2020, a CAGR of 28.2%.
  • Yup, fast growing – growth from 2014 to 2015 was 51%
  • People use more than one IaaS, and probably “cloud” – “[H]ybrid cloud infrastructure is already a common pattern at several large enterprises and IDC predicts that 80% of IT organizations will be committed to hybrid architectures by 2018″ – notice they say “large enterprises,” which suggests a cut of the data by company size: last I recall, IDC defined “large enterprise” as 2,500+ people, which may or may not be the case here.
  • A few cloud providers dominate – Amazon is still king, and there’s an fat-head of marketshare: “In 2015, 56% of the revenue and 59% of the absolute growth went to the top 10 IaaS vendors.”

Contrast that 60% IaaS usage with the 45% use in a recent Morgan Stanley CIO survey. I don’t think that’s a huge difference, but it does show the fiddliness of these kinds of surveys. To be fair, the Morgan Stanley survey has public IaaS usage at ~90% by 2019. I’d trust IDC a lot more, esp. with 6,000 surveyed vs. 100.

Also, while I can’t verify this: I’d assume this public IaaS is not to the exclusion of private cloud/on-premises. To be sure, some, or even much, of it must be public cloud gobbling up on-premises usage and revenue. However, I wouldn’t take it as a zero-sum game between the two.

Source: Enterprise Adoption Driving Strong Growth of Public Cloud Infrastructure as a Service, According to IDC – prUS41599716

Two very different estimates of cloud email usage and forecasts

A while back I posted a quick quote from recent Gartner prognosticating about cloud email. The up-shot was that right now, it’s just about 8% for all types of companies, globally (except India and China for some reason). Someone from SpiceWorks left a comment that arecent survey of theirs indicated something much different, at least across the more SMB focused demographics they asked (out of 539 respondents, 46% were in companies of 10-99 employees, 23% were from companies of 100-249). Gartner, no doubt, covers a broader market, perhaps even weighted to larger companies (I don’t have access to the report, so I can’t look up the demographics).

For your entertainment, here are the two charts:

Email Moving to Cloud Estimates

Email Moving to Cloud Estimates

(The SpiceWorks 2014 estimate is a bit of fuzz-work on my part based on people’s claims to migrate in six months. If that bothers you, just assume it’s flat and the fun still stands.)