Whatever you want to call it, “legacy” software is a problem. In one of our recent surveys, 76% of executives said they are too invested in legacy applications to change how they do software. It can seem hard, but fixing that blocker is possible. As with all things in software, there is no quick fix, it just takes discipline, work, and time. In this episode, Coté talks with VMware Tanzu’s Rohit Kelapure who’s been working in application modernization for years. He goes over the initial portfolio analysis and thinking that the Pivotal Labs application modernization teams walk customers through.
James, Karthik, Bill, and Ernest are all now at Verica, a chaos engineering startup founded by Casey Rosenthal and Aaron Rinehart.
Original source: Chaos In The Time Of Covid
I consider how much we depend on useless, arbitrary tasks to prove ourselves. I consider how much we depend on these tasks so we can say, at the very end, we succeeded.
Original source: Fuck the Bread. The Bread Is Over.
So okay, I can pick up a tripod of some sort from Amazon for not too much money — but speaking of money, here’s the big Achilles’ heel: while the free version of the app is fairly functional, upgrading to Pro costs €41.47. That’s nearly fifty bucks! Sure, I’d like to be able to use all my cameras; in free mode the app shows me the Wide 1x camera and the front selfie camera, but is it worth that much to use the Telephoto 2x or the Ultrawide 0.5x? Pro unlocks higher resolutions, and there are also a bunch of options to control focus, lighting, flash, zoom, and so on, which I would definitely have bought for a fiver or so — but not for this much. I already have a decent webcam at home (a Razer Kiyo), so I’d be using Camo only away from home, and I’d have to acquire and carry a separate piece of kit to do so.
Original source: Whammo, Camo
The company is updating its New Relic One platform with simplified pricing, interface, portfolio, and a free tier for engineers to try and use the software, which instruments IT environments and applications. CEO Lew Cirne said the move is designed to make New Relic easier to consume and address the convergence of logs, infrastructure, and APM. Simplified pricing from 11 paid products down to three, moving to per-user pricing and a perpetual free license will make doing business with New Relic easier, he said.
Pricing is mysterious, critical, and this fascinating to watch.
Jana Werner and Barry O’Reilly have a great case study and commentary of transformation at a couple organizations, primarily a bank. I was lucky enough to get Jana on for an interview on Software Defined Talk, talking about the case, information theory, and Nietzche. It should be in the podcast feed next week.
Here’s some of my highlights:
- “In one Financial Services organization we’ve been able to implement an increase to contactless card payment limits in days where the previous increase took months. We stood up a work from home solution for call centre staff, automated processes and relieved pressure on teams having to manually capture customer data over the phone in 3.5 weeks—a record for service delivery and a credit to the teams and individuals who made this possible.”
- Focus on the outcome, not following the process, or working a lot: “The subtle yet powerful shift to outcome-based measures of success — reducing and resolving customer issues — over traditional output-based deliverables of being on time, budget and scope had a pronounced impact on productivity and employee satisfaction.”
- When the meeting (the bureaucracy) becomes the product: “Slide decks, paper proposals and steering group sessions all take a significant investment to prepare, avoiding “difficult” conversations by socializing and re-socializing in advance of exec meetings, deferring decisions, requesting a raft of meeting minutes to document, correcting, amending and signing them off—the majority of which few people read.”
- This effects how the entire organization runs, and, indeed the pace of delivery: “The speed of these cycles determines the heartbeat of the organization.”
- Management starts asking different questions: “Responses can now shift post-release from ‘How could you have got this wrong?’ to ‘What is our next best action?’ Seeing how shipping smaller slices allows us to iterate, also means leaders can set direction and monitor metrics over setting targets and failing anything but perfect results.”
- Often, management has failed to build a system (vision, strategy, norms, “culture,” etc.) that makes staff’s job clear. That’s a problem! “Test your strategy cascade methods to maintain the clear purpose, problems and outcomes teams are working towards. Ask teams if there’s a clear line of sight between the objectives, and how their work contributes to achieve your shared success. If they can’t see it, fix it. Maximising both organizational alignment and autonomy can be the biggest accelerant for sustainable pace, employee engagement and amazing customers experiences.”
- And: “The biggest hurdle to change is people not believing it’s possible.”
There’s a lot good in there. Check out the case study.
What is the point of a Google Cloud that is losing its iconoclastic approach and turning into a me-too amalgam of AWS.
Original source: Can Brian Hall Fix What Ails Google Cloud?
Some 3 million new users downloaded the Starbucks App and signed up for the Rewards loyalty program since April, up 17% on the first three months of the year before the COVID crisis hit home in the US. Over the same period, 90% of sales were executed via a combination of drive-thru and mobile order-and-pay, with mobile order usage alone now accounting for 22% of total transactions.
The best time to plant a digital transformation tree is ten years ago. Barring that, today is great.
Theory: in a world of SaaS/public cloud, “open source,” is an implemented standard, instructions for plumbing, not the actual product sold.
The actually product (the thing sold, paid for) includes running the commercial software, storing the data, managing how the software is used. It can also include doing the unseen, tedious Morlockian work of making it “enterprise grade,” even “cloud grade.”
Giving away the open source stuff lets the commercial company (the SaaS) define and control its 3rd party dependencies – here, how New Relic’s data is collected and modeled. That is the blood and oxygen of a monitoring company: no monitoring data, no company.
As a strategic bonus: open sourcing things allows the SaaS to kill off (perhaps “limit,” to be less hyperbolic) areas of the market that rivals could own, differentiate, and monetize.
Kubernetes does this (IaaS becomes low value, table stakes, undifferentiated), not sure about Linux. Linux is something different: it is the product, not the standard.
There is a major flaw in my reasoning, viz. Kubernetes: all of the code to make it actually work below and around kubernetes can be proprietary, usually. The software defined networking (despite years of trying to open source this awhile back, it remains, largely, inaccessible alchemy), the security integration, the PaaS layer (though, actually, here, another instructive confounder to my present theory), etc.
But, perhaps, this illustrates my theory: those parts of the market have been defined as the place that competition can occur.
You would then expect rivals to open source those things to damage (pardon, again: “limit”) their rival’s competitive advantage, while keeping their own stuff closed. (“Closed,” of course can also – usually in public cloud – mean “only available as a running service in one of the big three clouds or a the SaaS in question.”)
Of course, all of the rivals can agree to give up monetizing parts of the market and all open source that part, all giving up on making money off it. This is usually done somewhat by accident, or with one large competitor reluctantly throwing in the towel and giving up after a long fight, as with HTML, RIA’s (Flash vs. HTML5 vs. Androind/iOS – not only open source here, but very much industry de facto standards),
Docker, and, of course, kubernetes. OpenStack was a failed instance of this theory: the public cloud companies would not see one of their core assets open sourced and made non-differentiating. Also, the whispers are that the OpenStack community has its own problems, not least of which the inability (and the lack of will) for its primaries to spend billions on building their own Datacenters and global networks out.
Build tools are an odd river in this terrain that I don’t know well: has Jenkins being open source really limited the commercial opportunity of commercial build tools and CI/CD?
And security – always security: somehow impossible to fully open source as in drive out all the closed source and monetizing possibilities.
(Also, Hyperic tried this open sourcing the systems management stuff. Perhaps too early for it to be successful, perhaps getting acquired just halted the corporate enthusiasm needed to pursue that course. That was too long ago to remember, recount, and reminisce. [Nagios was that deafening dull-thumb of the GPL death-cult, where “life” is a vendor’s ability to make closed source profit margins and scale top-line revenue to billions.])
That means being able to change or add applications and services at near the speed of the start-ups. Hughes gives as an example a Fintech company that was failing to hire the talent it required to develop a new mobile app, so instead used the OutSystems platform to develop it, in seven weeks, using the existing developer team. The effort resulted in an increase in customer onboarding conversion of 30%.
New article of mine:
The IT outcomes of Kubernetes are clear: 95% of businesses report clear benefits from adopting Kubernetes, with more efficient resource utilization and shorter software development cycles amongst the top benefits cited. The benefits don’t stop with the IT team, though. In an era where IT mostly determines competition and growth, the more agile the technology at the heart of a business, the greater the agility of the business overall.So, the business case for Kubernetes is clear. To those of us in IT at least.It makes sense that empowering development teams to do more in less time has clear benefits for businesses on paper. But given the inherent complexity of Kubernetes, the way in which these benefits actually manifest may not be so clear for those outside the IT department, particularly in the early stages of implementing the technology.Here, we look at why the tangible outcomes Kubernetes can provide across a business are worth overcoming initial challenges it may present, and what it means in the context of global events many organisations have been faced with in 2020 so far.
Read the rest!
One of the organizations we studied was the business-to-business sales department of a large company in the Netherlands. They used a relatively simple rule-based AI to predict whether a client would need a new product or whether a client should be contacted because a product they used was out of date. Normally a sales manager would call the client, and because the sales manager has come to know her clients personally, she would also ask personal questions: How are you doing? How is your family? In theory, the AI system was much better at predicting the best moment to contact a client, so the organization fired most of its salespeople and the AI system was introduced. Soon, however, the organization discovered that the personal contact between the salespeople and the clients was far more important in selling their products than anybody had realized. The AI system couldn't make this personal contact, and therefore performed much worse than the sales managers did.
The article also notes that you often need to hire new, additional people to be the "AI translators": staff doesn't know how to interpret what predictive AIs do very well.
Original source: The Impact of AI on Organizations
As he and many others point out, transience is built into Dutch still life. You often have paintings of flowers that are starting to wilt, or a glass that has a chip or a crack into it. There are all these intimations of decline and decay, even as the objects are so beautifully rendered. That ties in with Simon Schama’s argument about the fundamental ambivalence of the Dutch who, even as they experienced this incredible economic prosperity and abundance, had a lot of guilt about it tied in with Calvinist religious beliefs, with the sense that they were constantly beset and imperilled on all sides by enemy forces.
Original source: The Best Books on The Dutch Masters
irregardless: a word that distinguishes people who do not care much about English usage from those who care terribly—and want the world to know it.
Original source: The shadowlands of language
By 1970, many of these covers had a uniform appearance, predominantly painted illustrations on black backgrounds with the titles set in Roberta, one of the Art Nouveau-styled typefaces of the occult revival. All the Alessandrini covers date from the late 70s and early 80s, and show an evolution of the imprint’s style, with the same black livery but a different typeface that I can’t identify (Coliseum is the closest digital equivalent), together with artwork that’s more of a design rather than an illustration of the book’s contents.
As a kid, I spent hours at used bookstores and combing through the books at charity shops. The books themselves were good, but the covers were their own quest and reward. There were so many paperbacks and designs over the decades that stocked those shelves.
Original source: Jean Alessandrini book covers
Instead of charging a small team with developing the best product and then letting the operation grow with the product’s evolution, GE set up a huge organization that wasn’t quite needed yet.
Original source: The Dimming of GE’s Bold Digital Dreams
The continued adding of solutions and services to the hybrid cloud services seems to be paying off, according to both companies. They said this week that there has been a 2.5 times increase in the number of hosts between June 2019 and June 2020 and a 3.5 times jump in the number of VMs running, and VMware Cloud on AWS is running 17 AWS regions around the world and offers more than 300 third-party solutions from technology partners.
And, VMware’s kubernetes strategy, by capabilities:
This gives our customers the ability to have a single environment where they can deploy, manage and run both VMs as well as containers and Kubernetes clusters and because it’s enabled on top of VMC and AWS, it also inherits all the elasticity of the AWS public cloud for containerized workloads and also gives them a consistent operating environment for hybrid cloud environments where they might be running those same services on top of vSphere environments on-prem.
Original source: The Growing Dependence Of VMware On AWS
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.
Beware, I still have to pay my bills
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 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:
- 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.
- 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.
- 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…
- 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:
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. 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.
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…
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.
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.
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:
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
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.
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. 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.
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). 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:
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.
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.
 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.)
 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.
 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.)
 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.
 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?)
 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.