The vast majority of CIOs expect to deploy new technology stacks in the next 12 months. Most CIOs said they are already using or are planning to deploy microservices (88%), containers (86%), serverless computing (85%), PaaS (89%), SaaS (94%), IaaS (91%) and private cloud (95%) in the next 12 months.
CIO responses captured in the 2019 research indicate that lost revenue (49%) and reputational damage (52%) are among the biggest concerns as businesses transform into software businesses and move to the cloud.
“When we moved to the cloud the first time, we cut down the lead time for an environment from 100 days to 85 days. This is self-inflicted lead time… processes that are keeping you from moving faster,” he said.
“We also had 30 people involved in a classic delivery, and we figured the cost was around €40,000 to provision an environment, in work time, handovers and meetings and what not.”
Here’s a recording of one of my talks. It’s on what the operations team does when running in a platform, DevOps-y, whatever style:
Developers don’t need “services” from ops, they need products: continuously innovated platforms that evolve weekly. Once ops toil is removed, ops can focus on their customers’ – development – needs. Using stories & tactics from the real-world, this talk helps launch a platform-as-a-product strategy.
Most ops groups can’t give developers what they need. Ops is limited by traditional service delivery mindset and tools. Stability & reliability are now table-stakes when you’re releasing software daily. What developers need now from ops is innovation. Operations has rarely takes this innovation-driven, product approach to providing services, & instead focuses on delivering to specification & limiting SLAs. As with development, ops creates value with continuous operations, product managing their platforms and releasing frequently.
This talk covers how ops groups are transforming from a service delivery mindset a platform-as-a-product approach. With examples from Discover Financial Services, Rabobank, the US Air Force, & others the talk covers the concept, technologies & tools commonly used, & ops tactics needed to kick-off a platform-as-a-product strategy.
Owen covers CF Summit Basel:
“The users we spoke with didn’t just see it as a PaaS – it was the underlying philosophy of application delivery and management upon which future developments would be based. The Foundation claims Cloud Foundry saves, on average, 10 weeks of development time and $100,000 per app development cycle. In fact, in its own survey, 92% of users cite cross-platform flexibility as important. If these panelists are gaining such benefits, it’s easy to understand why they are so enamored with it.”
Original source: Cloud Foundry Cult
With DockerCon this week, there’s no end of Docker quotables and items. Here’s my collection
Once landed in an account, Docker usage grows their CEO says:
There has also been expansion within customers, with organizations that start with Docker expanding their usage on average by five times within six months
Way back in 2015, the (now annual?) DataDog study of Docker usage among their customers said that 2/3 of companies that try Docker adopt it. Which is all to say: once it gets in, it spreads.
A toolkit for putting together docker stacks:
In essence, Moby is the build system that creates Docker Community Edition, which is akin to Fedora, and Docker Enterprise is derived from Moby and is akin to Red Hat Enterprise Linux. Link
People got all freaked out. I’d even say “freaked the fuck out.” Competitors, of course, gloated, if only in silence. Criticism of handling the announcement aside (ideally, you wouldn’t like to kick up a stink), I feel like it was more like a tempest in a teapot.
Docker momentum/penetration and types of applications/workloads
Global 2000 customers have somewhere on the order of thousands to tens of thousands of applications, and across these major firms, less than 5 percent of the applications have been containerized so far. While somewhere between 5 percent and 10 percent of the applications that are being containerized are net-new, microservices-style applications that everyone is talking about all the time, the other 90 percent to 95 percent are just lifting and shifting legacy applications from bare metal or virtual machines to containers. Link
VMware threat…or just legacy gobbling?
Docker bounces back and forth between “replacement for VMware” and “a different thing, so don’t worry about VMware.” In this round of Docker news, there’s been some strong pull towards the “replacement for VMware” camp. To be fair, it’s more like doing both:
In general, says Johnston, customers who move from bare metal or VMs to Docker containers can provision, scale, and deploy applications up to 75 percent faster, and those moving from bare metal to containers can save 50 percent on compute and those who are moving from VMs will save around 25 percent. Link
This might also come from the obvious move to start gobbling up legacy (more accurately “existing”) applications. Here, Docker had two customer reference:
Northern Trust, a leading international financial services company, experienced deployment times that were 4X faster and noted a 2X improvement in infrastructure utilization
And, Microsoft IT:
Microsoft is not only a partner in this program; their IT organization is also a beta customer. Microsoft IT increased app density 4X with zero impact to performance and were able to reduce their infrastructure costs by a third.
There was also a story of Visa using Docker:
Kocherlakota said Visa is aiming to move as many workloads at it can to the container model to help improve overall efficiency.
Other tech companies are often cautious about working with Docker. They’re not really certain about how it helps or threatens their position in the IT stack and, therefore, their ability to sell higher profit margin products and services. No one wants to become the x86 manufacturer of the cloud (read: low margin, commodity).
I’ve noticed this cautiousness slightly melting as more and more vendors are at least putting their stuff in Docker images and, on the public cloud front, supporting the use of Docker. My company, Pivotal, ingests Docker images.
A brief whack at why Microsoft cares, from Christopher Tozzi:
Although there remains work to do to get Docker on Windows ready for prime time, the platform will be important in helping Windows Server stay as nimble as Linux environments in hosting the workloads of the future…. Microsoft’s interest in Docker may seem strange. Microsoft already offers traditional virtual machine products, most notably Hyper-V. In some respects, Docker containers compete with virtual machine platforms…. But that’s not necessarily the case. Depending on how they’re used, containers can complement virtual machines, rather than replace them. If you use virtual machines to host the environment in which Docker runs, your Docker environment becomes more scalable and portable than it would be if it ran on bare metal. That’s likely the type of use case Microsoft envisions for containers on Windows.
More from Nick Martin on Microsoft and Docker.
Oracle becomes the latest enterprise IT vendor to jump on the Docker container bandwagon as it seeks to expand its reach in the public cloud market. Among the container-based application, middleware and development tools made available on the container platform are Oracle’s MySQL database and its WebLogic server. Those tools are in addition to the more than 100 images of Oracle products already available on Docker Hub, its cloud-based image registry.
So, what’s going on here? Staking a claim on The New Stack
I’m often asked to explain all the various cloud stacks, to help Pivotal buyers sort out what CaaS, PaaS, cloud-native, and “cloud strategy” means. They’re trying to figure out their planning for building out new IT, for “doing DevOps.” It’s a mess out there w/r/t to figuring all this out if you’re not a vendor or analyst who’s steeped in this shoggoth every day.
In all the Docker, container, and cloud-native wars, the revenue battle for vendors is mostly about two things:
- The pool of money in simply migrating the VMware workload to a new, more efficient layer, hence the ongoing attention to “the VMware threat” that Docker poses). I’m not sure how big this market is because, as a disruptive shift (cf. Linux vs. UNIX vs. Windows vs. z) part of it is reducing the overall spend through lower prices and more efficient usage. But, the existing virtualization market is best described as “fucking huge.”
- Fighting over who “owns” (and therefore collects the most profit from) the stack that companies are using to build and run their software. By my estimate, this is something like around a $20-25bn market in the future. You can see a Spanish Civil War like precursor going on in the Java application server market; it’s spreading to a “World War” with respect to all custom software stacks.
On that second point, here’s my latest attempt to describe how things are shaking out category/definition wise:
Of all the SPI cloud categories, PaaS is the most problematic place as all us vendors hate the PaaS term and are trying to re-define what it means. I would break PaaS into two categories currently: (1.) container orchestration, and, (2.) cloud platform.
Container orchestration takes an IaaS and manages the installation and configuration of container images on your new cloud. By “images” here, I mean that you’ve chosen to put your software (probably custom written software, not packaged software) into containers (or the delegated way we do it with buildpacks in CF), specified how all the different nodes are wired together with all the ACLs and configuration, and then given it over to the orchestration software to deploy those containers, set the configuration, and do the ongoing health-checks/remediation.
Ideally, the orchestration platform should also have “day 2” tools to help you monitor and manager (“fix”) problems that happen in production. I assume things like kubernetes, the Docker/Moby constellation of things, Mesosphere, etc. fit here.
People are obsessed with container orchestration now and it’s pretty much all anyone talks about. I think all this is what’s becoming known as “CaaS” – Containers as a Service.
(On this next section, I’m extremely monetarily biased, of course:) A cloud platform either has or depends on an orchestration layer, but adds in integrated middle-ware, ALM tools (from basics like “cf push”, and an overall programming and deployment model with all the tools and enforcements. Heroku is the classic example here in public cloud, and now Cloud Foundry (CF) has taken over this model in public and private cloud, the second (it seems) where most of the usage and money is, at least in the enterprise space. I’d argue, that CF is the enterprise market-leader (by revenue at least, but increasingly penetration in the F500 – while Pivotal has impressive numbers, throw in the other CF distros and it’s even larger, no doubt); at the very least, “the highest growth and in enterprise production usage.” That all depends how you slice it, and of course my slicing favors me.
A cloud platform “pulls together” everything into a fully working “cloud” that deploy and provisions the servers, builds/maintains/deploys the containers, takes care of your networking configuration and concerns (inc. firewalls, etc.), and configs/manages all the middleware needed (e.g. “I want a database” means you just ask for it, instead of having to configure it and make container images of it and specify how it all works together).
The end goal of a cloud platform is the original end-goal of a PaaS: developers don’t have to “setup” any of the infrastructure or, really, middleware (databases, queues, etc.) that they use: they just write the “business logic” of their applications.
All this standardization is technically “restrictive” (developers can’t just install anything they download off the Internet, it has to be integrated into the platform). This is why we often call this model “opinionated,” but it follows the same contract/promises model that Google SREs follow: we promise we can support your applications in production if you use only the things we support, otherwise it’s all on you.
However, the benefit of such opinions is a huge jump in productivity as we see at all our customers: one Pivotal customer manages 1,000+ applications (all angles toward very frequent, DevOps-style releases for fast feedback loops and all that small batch stuff) with just 4 PCF operations staff, etc.
Our DIY white paper makes the case that snow-flaking this all out is a bad idea. At the very least, if you build your own platform, you should try to just have one used organization wide.
In comparing CaaS and cloud platform, the key distinction to me is that a cloud platform bundles and integrates together all your middleware and “services” frameworks. For example, if you want to do microservices with all the bulk-heads and such, that functionality should be built into the cloud platform – you should have to go read-up how to set most of that up. PCF, of course, has Spring Cloud and more for that. All of the systems management tools (thing used in production to detect and fix problems) should also be built in, or the cloud platform should be instrumented so deeply that third party tools can do the managing as well.
Now, these two categories are likely to converge, and then the discussion will just be which cloud platforms are more featureful and better. It’ll be like battling Java application servers.
I haven’t made one of my own “burger” stacks of all this in a long time, but I think (again, highly biased) the ones we use for PCF are pretty good:
- A simple, cartoon one.
- More detailed stack, emphasizing “the value line,” i.e., “all things below this line have no differentiating business value and you should therefore buy instead of build them.”
- A pretty good, fancy-pants one.
- Some general analysis of Docker being used for mixed workloads and “hybrid cloud,” from Rhett Dillingham at Moor Insights & Strategy.
- As a reminder, 451’s container market-sizing: Container market to be $2.7B by 2020, from $762m in 2016.
- And, Microsoft’s purchase of Deis recently is another good example of stuff going on in this space.
In case you don’t know, working at Pivotal, I obviously have a stake in how all this turns out, so I’m biased on multiple angles of the above whether I want to be or not.
A round-up of the news and some context around Microsoft burrowing down further into Kubernetes-land by acquiring Deis:
The deal & market
- Microsoft: “Deis gives developers the means to vastly improve application agility, efficiency and reliability through their Kubernetes container management technologies…. We expect Deis’ technology to make it even easier for customers to work with our existing container portfolio including Linux and Windows Server Containers, Hyper-V Containers and Azure Container Service, no matter what tools they choose to use.”
- Deis: “We look forward to making Azure the best place to run containerized workloads.”
- Deis is/was part of EngineYard, right? – Notable that EngineYard (on April 10th, 2017, day of announcement) doesn’t mention it on their blog, or press release list. And that Deis and Microsoft don’t really either. See 451’s Jay Lyman’s coverage of that deal in 2015.
- No deal-size was disclosed, of course, but Deis was small and I’m guessing it didn’t fit into EngineYard’s overall strategy, or what (little?) cash they got was a nice to have versus synergies of keeping Deis.
- Containers are rising in usage, as 451’s Donnie said: “Our latest data says production use of containers has doubled from 10.2% to 22.5% of orgs between Q1 and Q3 2015. Amazing.”
- 451’s January 2016 container market TAMs and forecast:
The technology: not so much PaaS anymore, but Kubernetes management
- Jan 2016 diagram of the Deis stack, above – so, pretty much a “cloud platform” competitor. Compare to Pivotal’s most recent snazzy-burger.
- “Creator at CTO at Deis”: “Best to think of Deis as a Kubernetes company. We are much more than the PaaS solution many folks know us for.”
- CNCF exec director: “their Workflow product (also open source), is basically the smallest piece of software that lets you run Heroku buildpacks on top of Kubernetes. So, you can get a 12-factor PaaS workflow, and still have the full Kubernetes API underneath if and when you need it.”
Microsoft likes Kubernetes
- Seems like Microsoft has gone all k8-crazy. So this is adding k8 support and some cloud-native services/middleware (package mgmt, routing, etc.) to Azure?
- Back in July of 2016, Microsoft hired a k8 big-wheel (and other, “small wheels,” I’d assume), so they’re obviously into the thing…or at least the thinking behind the think. This leave, once again, Amazon as the last major cloud hold-out on k8.
- That said, I think Microsoft’s new thing is to like everything that layers on-top, below, or around them. As long as you’re in every deal, you make a lot of money even if you’re not all of every deal. It’s pretty hard, now, of course, to compete with the big clouds.
- Or, put another way: “Satya is like the Pope Francis of software,” says Alex Polvi, founder and CEO of CoreOS, a company that plays in the same area as Deis. “He took this old institution and made it cool again.”
We’ve seen a goodly spate of news in the container space recently which we cover in the episode. In the second half, we talk with Kevin Hoffman about the .NET world, Steel Toe, and his book, Beyond the Twelve-Factor App. A recent survey from the Cloud Foundry Foundation is widening the framing around container management, adding in the use of Platform-as-a-Service into the usual container orchestration mix. The survey also shows some interesting results around adoption, e.g., managing containers in production ends up being more difficult than people predict during evaluations. Also since our last episode, DockerCon brought a bevy of announcements in the container ecosystem which we cover briefly. And highly relevant to our guest, Kevin Hoffman, .NET Core 1.0 was officially released, as open source. In the second half we talk about the recent history of .NET and how it’s being used to create microservices. We also talk about the three extra “factors” Kevin’s book adds to the 12 factor app and typical experiences when migrating to 12 factor apps.
Full show notes: pivotal.io/podcast
Figuring out the market for PaaS has always been difficult. At the moment, I tend to estimate it at $20-25bn sometime in the future (5-10 years from now?) based on the model of converting the existing middleware and application development market. Sizing this market has been something of an annual bug-bear for me across my time at Dell doing cloud strategy, at 451 Research covering cloud, and now at Pivotal.
A bias against private PaaS
This number is contrast to numbers you usually see in the single digit billions from analysts. Most analysts think of PaaS only as public PaaS, tracking just Force.com, Heroku, and parts of AWS, Azure, and Google. This is mostly due, I think, to historical reasons: several years ago “private cloud” was seen as goofy and made-up, and I’ve found that many analysts still view it as such. Thus, their models started off being just public PaaS and have largely remained as so.
I was once a “public cloud bigot” myself, but having worked more closely with large organizations over the past five years, I now see that much of the spending on PaaS is on private PaaS. Indeed, if you look at the history of Pivotal Cloud Foundry, we didn’t start making major money until we gave customers what they wanted to buy: a private PaaS platform. The current product/market fit, then, PaaS for large organizations seems to be private PaaS
(Of course, I’d suggest a wording change: when you end-up running your own PaaS you actually end-up running your own cloud and, thus, end up with a cloud platform.)
How much do you have budgeted?
With this premise – that people want private PaaS – I then look at existing middleware and application development market-sizes. Recently, I’ve collected some figures for that:
- IDC’s Application Development forecast puts the application development market (which includes ALM tools and platforms) at $24bn in 2015, growing to $30bn in 2019. The commentary notes that the influence of PaaS will drive much growth here.
- Recently from Ovum: “Ovum forecasts the global spend on middleware software is expected to grow at a compound annual growth rate (CAGR) of 8.8 percent between 2014 and 2019, amounting to $US22.8 billion by end of 2019.”
- And there’s my old pull from a Goldman Sachs report that pulled from Gartner, where middleware is $24bn in 2015 (that’s from a Dec 2014 forecast).
When dealing with large numbers like this and so much speculation, I prefer ranges. Thus, the PaaS TAM I tent to use now-a-days is something like “it’s going after a $20-25bn market, you know, over the next 5 to 10 years.” That is, the pot of current money PaaS is looking to convert is somewhere in that range. That’s the amount of money organizations are currently willing to spend on this type of thing (middleware and application development) so it’s a good estimate of how much they’ll spend on a new type of this thing (PaaS) to help solve the same problems.
Things get slightly dicey depending on including databases, ALM tools, and the underlying virtualization and infrastructure software: some PaaSes include some, none, or all of these in their products. Databases are a huge market (~$40bn), as is virtualization (~$4.5bn). The other ancillary buckets are pretty small, relatively. I don’t think “PaaS” eats too much database, but probably some “virtualization.”
So, if you accept that PaaS is both public and private PaaS and that it’s going after the middleware and appdev market, it’s a lot more than a few billion dollars.
(Ironic-clipart from my favorite source, geralt.)
There’s a new release of Pivotal Cloud Foundry out this week. We’ve been seeing great pick-up from customers, and the nature of conversations I’ve been seeing while visiting them has been changing from operations, IaaS-driven topics to discussions about improving application development and delivery. This release also reflects that shift “up the stack.” Here’s my brief take on how things are going for Pivotal Cloud Foundry.
The most typical path to using Pivotal Cloud Foundry
First, this is how I see most customers arriving at Pivotal Cloud Foundry:
Who does Pivotal see as their toughest competition? According to Watters, that distinction belongs to AWS. Cloud customers often believe that AWS itself is enough. [James] Watters says that there wouldn’t even be the concept of cloud-native apps without Amazon, but “people need more than just Amazon to be successful.” Watters believes that some of Pivotal’s best customers are those who first tried to creates platforms themselves, but then asked “what’s the right thing to do for my organization?”
The rest of the piece is a good, brief overview of the new feature in Pivotal Cloud Foundry 1.6.
What I see in this release is a movement “up the stack” to address application architecture and development concerns. You can see this in the incorporation of Spring Cloud (which supports, among many other things, a microservices approach), support for .Net (almost every large organization wants and needs this for the way they develop applications), and the numerous integrations with ALM tools (like Cloudbees, GitLabs, etc.).
For many years – and still! – the focus of “cloud” has been on the infrastructure layer: setting up the “operating system” for the cloud, your big datacenter, and everything that results in that magical blinking cursor:
I think of this as the “blinking cursor” problem. You know that softly pulsing cursor: it’s the result of millions —if not billions! — of dollars spent on cloud projects. These “private cloud” projects see companies redoing how their IT department provides infrastructure. They move from physical to virtual management; move from manual ticket processing to self-service, automated provisioning; and after efforts that must have seemed like building all of the furniture for a new IKEA store with just a pocket knife, they might end up with their own cloud. And then, after all of this, they’ve gotten the blinking cursor up! The servers are ready to use! Now the hard work of designing, developing, deploying, and managing the applications that run the business starts. There is little wonder that 95% of folks in [a poll asking “what went wrong with your private cloud project?”] were not completely satisfied with their private cloud projects.
I still see much of the conversation centering around getting the blinking curser up, and too little on how to create and manage good applications. So, obviously I like our new positioning “up the stack,” not only providing application-centric services, cloud-ified middleware, and the operations capabilities needed keep those application up and running.
In addition to the actual product, you can see this reflected on the team (the evangelist/advocate/community team) I’m on where we’ve added people who focus on explaining how to do better software development, in addition to the more operations-centric people we started with.
Momentum: customer and ecosystem growth and character
Momentum wise, I measure Pivotal Cloud Foundry based on customers and the overall Cloud Foundry ecosystem.
Customer wise, we’ve gone from about $40m in bookings in 2014 to a $100m annual bookings run-rate this year. Those are two, slightly different type numbers, but you can get a feel for the amount of business we’ve been doing, and more important, the high growth and fast traction we’re getting. What I like about out customer base is that they’re everyday, big brands and companies. This not only means I can better explain what I do to my non-tech friends and relatives, but also means we have a sustainable customer base: these Global 2,000 customers aren’t going away anytime soon, esp. if they keep up the strategy that brought them to Pivotal Cloud Foundry: transforming to a software defined business.
There’s a Cloud Foundry Summit this week in Berlin and it evidenced the ecosystem momentum around Cloud Foundry, the open source project that Pivotal Cloud Foundry is based on. There’s now just north of 50 members. When you look at those logos notice how many non-tech companies are on there: it’s still mostly tech companies who want to use or extend Cloud Foundry, but there’s a delightful number of non-tech companies who want to support the platform that’s supporting their business. And, of course, the work with Microsoft to support .Net brings that whole ecosystem very close as well. As I mentioned above, many of the every organization I talk with really wants .Net support. Another interesting thing to watch is growth in use of Azure; that’s an option that I hear companies exploring a lot now-a-days, and, indeed, as Microsoft said in the press around this release, “[t]he demand for Azure was so high that we already have Fortune 100 customers building their next-generation applications with Pivotal Cloud Foundry on Azure.”
Obviously, working at Pivotal I’m highly biased on all this. Still, I think there’s good evidence that things are panning out. My main hope, as always, is that we can help improve the state of software, globally, and, thus, improve how organizations are operating.
More on Pivotal Cloud Foundry 1.6:
- An overview of what’s in Pivotal Cloud Foundry 1.6
- Details on Spring Cloud – “SCS 1.0 operationalizes components from Spring Cloud, making them available as managed services within the Pivotal Cloud Foundry marketplace, including a configuration server, service registry, and circuit breaker dashboard service. SCS fully automates the installation, configuration, deployment, and management of these infrastructure components.”
- Press release covering 1.6
- There’s a 1.6 overview webinar on Nov 19th if you’d like to hear more.
I’ve been working on a series of blog posts on “the cloud native journey.” I put that in quotes because it’s admittedly a cheesy marketing phrase. The point of it is: if you’re looking to start using all these new cloud-based ideas for improving how your company does custom software development, what’s that look like. You know, what’s the “journey.”
All four parts are now up:
- The introduction to the series
- The Purity & Tyranny Of A Blank Screen: The Greenfield Journey – see also a recording of my webinar on this section, also the slides.
- Dealing With The Stuff That Makes All The Money: The Legacy Journey – check the recording of the webinar on this section, too. Also, the slides.
- The Cloud Native Journey: Enterprise Transformation – check out the recording of the webinar on this part. Also, the slides.
There’s also a PDF of the whole thing if you prefer that format.
Tell me what you think of it!
Fun with market sizing
I’ve spent a lot of time over the years working with cloud market-sizings, and occasioanlly on them. They’re always a bit whackadoodle and can be difficult to pull apart. But, so long as they’re consistent year of year, they do give a good intedication of momentum and a comparision to other markets. This is what you should be using emerging technology marketsizing for: just indications of which way the wind is blowing and how strong that wind is relative to other breezes.
All too often, strategy and M&A people (and other “MBA” types who’re doing valuations and finances, plus all the hangers on in the chattering classes) get obsssed with market-sizing as if they’re “real” and start to do things like include them as fundamental parts of their business plan, e.g., “we’re going to capture 1% of the cloud market this year!” The implication there is that if they don’t, they’ve failed…but when you realize how corny the market-sizing are, you realize that basing your yearly plan on an Excel macro is a poor use of time.
With that disclaiming context established, I love finding market sizing numbers. They’re fun once you get enough of them and can start figuring out the relative size of markets. Which is to say: how much money is being spent each year across the world on various types of technology.
Platform-as-a-Service is one of the more tricky markets to size and has spun all sorts of directions over the years. It’s always the smallest of the three aaS’s, but the highest growth. Even worse, most PaaS market-sizing you see is for only public PaaS. I’ve heard that Gartner has consternated much about this over the years: if you insert a simple “r” into it, they have an on-premises category called CrEAP that sizes what, I think, is “private PaaS,” and I believe they’re fixing it up further.
However, the problem with sizing the PaaS market is asking what you’re sizing. There’s “PaaS from SaaS” offerings like Force.com and then so called “first generation” PaaSes like Heroku (also at Salesforce) and EngineYeard. Then there’s hosted development tools (all the CI services otu there) that, for some reason, show up in PaaS market-sizing. But now there’s all the private PaaS offerings that happen to also run as public PaaS (it turns out the enterprise market really likes private cloud as well as public). And then there’s trouble-makers like us at Pivotal who bristle at the notion of being called (just) a PaaS. Layer Docker, Mesos, kubernetes and all those folks in there…and you’re head should be spinning.
The composition of this market has changed dramatically over the years. My theory is that it’s not well “shaken out” (defined) yet and it’ll change more. So, when I get asked for PaaS market-sizing, I sigh a bit inside.
Getting to a helpful PaaS market-sizing
I think the best process is to thinking through a what PaaS is used for and then try to figure out how much money is spent on solving that problem, not the exact technologies used to solve it. To me, that gets to some indication (whether it’s a ceiling, floor, or mid-point, I don’t know) of how much money there is up to grabs if you’re selling PaaS.
As you can infer from my over contextualizing above, I think most PaaS market-sizing is bunk, but this chart a good way of thinking through getting to answer. It compares traditional packaged software and on-premises hardware spend to IaaS and PaaS to show how it starts to erode into “non-cloud” IT. I’m not sure if IaaS and PaaS and public cloud only (it probaly is, which is problematic).
When using this chart, the voice over is something like “tracking this market is difficult at this moment, as any analyst will tell you. I like to use something like this chart as a guide for thinking about it. With PaaS, what you’re interested in is how much traditional IT teams writing cloud-native applications are taking over, and this is one swag at it. Notice that the growth rates are drastically different too: there’s little to no growth in traditional.
The other thing (since most analysts don’t track private PaaS) this suggests is that all the traditional middleware money switches over to all PaaS (public and private) at some point…at least all the “new” money, the growth. Or, at least, that it’s a rough heuristic. It could be less (prices go down with cloud, right? ;>) or it could be more (software eating the world X IT – SaaS = what? == more customer software development at companies leading to more spend on the application development category).
So, if you add up the traditional markets of Appdev and middleare, you get something like a $35-40bn market in 2018 or so, depending how exuberant or dower you want to be, for pubic and private PaaS. Again, that wet-finger-in-the-winding is “bunk,” but it tells you type of money you should think about. Assume that over the next 10 years most “appdev and middleware” spend converts to “PaaS” and then you’ve got something that looks less shitty than the PaaS market-sizing analysts do now-a-days…and more real, I think.
If you’re really interested in PaaS, come to the Cloud Foundry Summit next month, May 11th and 12th, and see how this market is evolving. You’ll hear how companies are using Cloud Foundry to create software defined businesses and get the latest technical details on Cloud Foundry. Register with the code COTE to get 25% off!
I’m often asked for my perspective on the PaaS market, since I used to cover that as an analyst. For reference, here’s a brief overview. Of course I think Cloud Foundry and Pivotal play a big role in it, otherwise, why would I be here? ;>