Canonical refocusing on IPO’ing, momentum in cloud-native – Highlights

Canonical Party

There’s a few stories out about Canonical, likely centered around some PR campaign that they’re seeking to IPO at some time, shifting the company around appropriately. Here’s some highlights from the recent spate of news around Canonical.

Testing the Red Hat Theory, competing for the cloud-native stack

Why care? Aside from Canonical just being interesting – they’ve been first and/or early to many cloud technologies and containers – there’d finally be another Red Hat if they were public.

Most of the open source thought-lords agree that “there can never be another Red Hat,” so, we’ll see if the Ubuntu folks can pull it off. Or, at the very least, how an pure open source company wangles it out otherwise.

That said, SUSE (part of HPE/Micro Focus) has built an interesting business around Linux, OpenStack, and related stuff. Ever since disentangling from Novell, SUSE has had impressive growth (usually something around 20 and 25% a year in revenue). All is which to, the Red Hat model actually is being used successfully by SUSE, which, arguably, just suffered from negative synergies (or, for those who don’t like big words, “shit the bed”) when it was owned by Novell.

As I’m perhaps too fond of contextualizing, it’s also good to remember that Red Hat is still “just” a $2.5bn company, by revenue. Revenue was $1.5bn in 2014, so, still, very impressive growth; but, that’s been a long, 24 year journey.

All these “Linux vendors,”like pretty much everyone else in the infrastructure software market, are battling for control over the new platform, that stack of cloud-y software that is defining “cloud-native,” using containers, and trying to enable the process/mindset/culture of DevOps. This is all in response to responding to enterprises’ growing desire to be more strategic with IT.

Canonical momentum

From Steven J. Vaughan-Nichols:

Shuttleworth said “in the last year, Ubuntu cloud growth had been 70 percent on the private cloud and 90 percent on the public cloud.” In particular, “Ubuntu has been gaining more customers on the big five public clouds.”

And:

Its OpenStack cloud division has been profitable, said Shuttleworth, since 2015

Al Sadowski has an extensive report on Canonical, mentioning:

[Canonical] now has more than 700 paying customers and sees a $1bn business for its OS, applications and IT operations software. Time will tell if this goal is realized.

And:

Canonical claims some 700 customers paying for its support services on top of Ubuntu and other offerings (double the 350 it had three years ago), and to have achieved more than $100m in bookings in its last financial year…. [Overall, it’s] not yet a profitable business (although its Ubuntu unit is). We estimate GAAP revenue of about $95m.

Strategy

On focusing the portfolio, shoring it up for better finances for an IPO:

we had to cut out those parts that couldn’t meet an investors’ needs. The immediate work is get all parts of the company profitable.

To that end, as Alexander J. Martin reports:

More than 80 workers at Ubuntu-maker Canonical are facing the chop as founder Mark Shuttleworth takes back the role of chief executive officer…. 31 or more staffers have already left the Linux distro biz ahead of Shuttleworth’s rise, with at least 26 others now on formal notice and uncertainty surrounding the remainder

Back to Al on the Job to Be done, building and supporting those new cloud-native platforms:

Rather than offering ways to support legacy applications, the company has placed bets on its Ubuntu operating system for cloud-native applications, OpenStack IaaS for infrastructure management, and Docker and Kubernetes container software.

And, it seems to be working:

Supporting public cloud providers has been a success story for Canonical – year-over-year revenue grew 91% in this area…. Per Canonical, 70% of the guest OS images on AWS and 80% of the Linux images on Microsoft Azure are Ubuntu. Its bare-metal offering, MaaS (Metal as a Service), is now used on 80,000 physical servers.

On OpenStack in particular:

Canonical claims to be building 4,000 OpenStack deployments a month at some 180 vendors…. It claims multiple seven-figure deals (through partners) for its BootStrap managed OpenStack-as-a-service offering, and that the average deal size for OpenStack is trending upward.

On IPO’ing

The Vaughan-Nichols piece outlines Shuttleworth’s IPO plans:

Still, there is “no timeline for the IPO.” First, Shuttleworth wants all parts of the slimmed down Canonical to be profitable. Then “we will take a round of investment.” After that, Canonical will go public.

However, Al’s report says:

It is not seeking additional funding at this time.

Probably both are true, and the answer as Shuttleworth says is “well, in a few years once we get the company to be profitable.

More

Banks are handling disruption well – Highlights

Thus far, it seems like the large banks are fending off digital disruption, perhaps embracing some of it on their own. The Economist takes a look:

  • “Peer-to-peer lending, for instance, has grown rapidly, but still amounted to just $19bn on America’s biggest platforms and £3.8bn in Britain last year”
  • “last year JPMorgan Chase spent over $9.5bn on technology, including $3bn on new initiatives”
  • From a similar piece in the NY Times: “The consulting firm McKinsey estimated in a report last month that digital disruption could put $90 billion, or 25 percent of bank profits, at risk over the next three years as services become more automated and more tellers are replaced by chatbots.”
  • But: “Much of this change, however, is now expected to come from the banks themselves as they absorb new ideas from the technology world and shrink their own operations, without necessarily losing significant numbers of customers to start-ups.”
  • Back to The Economist piece: “As well as economies of scale, they enjoy the advantage of incumbency in a heavily regulated industry. Entrants have to apply for banking licences, hire compliance staff and so forth, the costs of which weigh more heavily on smaller firms.”
  • Regulations and customer loyalty are less in China, resulting in more investment in new financial tech in Asia: 
  • As another article puts it: “China has four of the five most valuable financial technology start-ups in the world, according to CB Insights, with Ant Financial leading the way at $60 billion. And investments in financial technology rose 64 percent in China last year, while they were falling 29 percent in the United States, according to CB Insights.”
  • Why? “The obvious reason that financial start-ups have not achieved the same level of growth in the United States is that most Americans already have access to a relatively functional set of financial products, unlike in Africa and China.”
  • There’s some commentary on the speed of sharing blockchain updates can reduce multi-day bank transfers (and payments) to, I assume, minutes. Thus: ‘“Blockchain reduces the cost of trust,” says Mr Lubin of ConsenSys.’

Fixing legacy problems with new platforms, not easy

  • The idea of building banking platforms to clean up the decades of legacy integration problems.
  • Mainframes are a problem, as a Gartner report from last year puts it: “The challenge for many of today’s modernization projects is not simply a change in technology, but often a fundamental restructuring of application architectures and deployment models. Mainframe hardware and software architectures have defined the structure of applications built on this platform for the last 50 years. Tending toward large-scale, monolithic systems that are predominantly customized, they represent the ultimate in size, complexity, reliability and availability.”
  • But, unless/until there’s a crisis, changes won’t be funded: “Banks need to be able to justify the cost and risk of any modernization project. This can be difficult in the face of a well-proven, time-tested portfolio that has represented the needs of the banking system for decades.”
  • Sort of in the “but wasn’t that always the goal, but from that same article, Gartner suggests the vision for new fintech: ‘Gartner, Hype Cycle for Digital Banking Transformation, 2015, says, “To be truly digital, banks must pair an emphasis on customer-facing capabilities with investment in the technical, architectural, analytic and organizational foundations that enable participation in the financial services ecosystem.”’
  • BCG has a prescriptive piece for setting the strategy for all this, from Nov. 2015.

Case studies

  • A bit correlation-y, but still useful, from that BCG piece: “While past performance is no guarantee of future results, and even though all the company’s results cannot be entirely attributed to BBVA’s digital transformation plan, so far many signs are encouraging. The number of BBVA’s digital customers increased by 68% from 2011 to 2014, reaching 8.4 million in mid-2014, of which 3.6 million were active mobile users. Because of the increasing use of digital channels and efforts to reconfigure the bank’s branch network—creating smaller branches that emphasize customer self-service and larger branches that provide higher levels of personalized advice through a remote cross-selling support system—BBVA achieved a reduction in costs of 8% in 2014, or €340 million, in the core business in Spain. Meanwhile, the bank’s net profits increased by 26% in 2014, reaching €2.6 billion.”
  • And a more recent write-up of JPMC’s cloud-native programs, e.g.: ‘“We aren’t looking to decrease the amount of money the firm is spending on technology. We’re looking to change the mix between run-the-bank costs versus innovation investment,” he said. “We’ve got to continue to be really aggressive in reducing the run-the bank costs and do it in a very thoughtful way to maintain the existing technology base in the most efficient way possible.” …Dollars saved by using lower-cost cloud infrastructure and platforms will be reinvested in technology, he said.’ JPMC, of course, is a member of the Cloud Foundry Foundation which means, you know, they’re into that kind of thing.

Pivotal Conversations: Debunking Cloud Foundry Myths

Our podcast this week:

There’s a whole slurry of myths about Cloud Foundry. With the platform updating so quickly, many of the issues behind these myths have long been addressed, and many were just false from the get-go. Coté and Richard talk about a recent post dismissing common myths. We also discuss recent news from the infrastructure software world and go over a bunch of upcoming events that Pivotal will be at.

If you use something like Overcast, be sure to check out the overly-extensive chapters and links right inside the podcast.

You should subscribe to the podcast!

IT’s usefulness is improving, but there’s plenty of room to fix the meatware, Surveys – Highlights

It’s another survey about business/IT alignment. Who knows how accurate these leadgen PDFs are, but why not? This one is of “646 CIOs and other IT leaders and 200 line of business leaders.” Some summaries from Minda Zetlin:

When LOB leaders were asked about the role their companies’ CIOs play, 41 percent said the CIO is a strategic advisor who identifies business needs and opportunities and proposes technology to address them. Another 22 percent said the CIO is a consultant who provides advice about technology and service providers when asked.

But 10 percent said their CIO was a “roadblock” who raises so many obstacles and objections to new technology that projects are difficult to complete. And another 9 percent said the CIO was a “rogue player,” with IT making technology decisions on its own, and creating visibility and transparency challenges.

Meanwhile, 36 percent of LOB leaders and 31 percent of IT leaders believe other departments “see IT as an obstacle.” And 58 percent of IT leaders but only 13 percent of LOB leaders agreed with the statement, “IT gets scapegoated by other departments when they miss their own goals.”

This seems better than the usual (kind of out of date) scare chart I used use, from a multi-year Cutter survey:

There’s still, as ever, plenty of room to improve business/IT alignment.

Speaking of that, also in that IDG/CIO Magazine survey, there’s a weird mismatch between the perception of The Business and IT about what IT does:

What does The Business want anyway?

Meanwhile, Vinnie quotes a Gartner survey of 388 CEOs:

  • Almost twice as many CEOs are intent on building up in-house technology and digital capabilities as those plan on outsourcing it (57 percent and 29 percent, respectively).
  • Forty-seven percent of CEOs are directed by their board of directors to make rapid progress in digital business transformation, and 56 percent said that their digital improvements have already delivered profits.
  • 33 percent of CEOs measure digital revenue.

Point being: The Business wants IT to matter and be core to how their organizations evolve. They want programmable businesses. Here’s some examples from another summary of that Gartner survey:

Although a significant number of CEOs still mention eCommerce, more of them align new IT infrastructure investments to advanced commercial activities – such as digital product and service innovation, exploring the Internet of Things (IoT), or adopting digital platforms and associated supplier ecosystems.

According to the Gartner assessment, some CEOs have already advanced their digital business agenda – 20 percent of CEOs are now taking a digital-first approach to business development. “This might mean, for example, creating the first version of a new business process or in the form of a mobile app,” said Mr. Raskino.

Furthermore, 22 percent are applying digital business technologies to their traditional processes. That’s where the product, service and business models are being changed, and the new digital capabilities that support those are becoming core competencies.

There’s demand there, the final result of “the consumerization of enterprise IT,” as we used to crow about. IT needs to catch-up on its abilities to do more than “just keep the lights” on or there’ll be a donkey apocalypse out there.

You seem people like Comcast doing this catching-up, very rapidly. The good news is that the software and hardware is easy. It’s the meatware that’s the problem.

Link

Why Pivotal Serves Free Breakfast to All Employees

Free food, during a limited, half-hour window, both saves people some hassle and gets them to show up at the same time to kick off the workday.

To understand why this is so important, picture Pivotal without free breakfast. Let’s start with the obvious. Most developers would sleep late if it were up to them. They’d roll into the office around 10 or 11 AM. Which means they’d grab a coffee, maybe respond to a few emails, and then sync up with the team.

Before you know it, the morning is over and it’s time for lunch. But hey, that’s okay, we live in a digital world, and you can show up whenever, so long as you get your work done, right? Wrong. Pair programming only works when you have people to pair with. And that means you need to sync their schedules.

We ring a cowbell at 9:05 AM. (The Toronto office smacks a golden gong with a mallet.) It signals that breakfast is over and the office-wide meeting is about to start. After the five-minute standup, the teams have their own standup meetings, and then pairs break off to get rolling at their workstations.

While posed as a pair programming enabler, take out pairing from the above and it also gets the point of having people show-up on-time, not dick around, and do actual work.

If you’ve seen me talk you know the joke of “how a developer spends their day” which usually includes 1-2 hours of actual coding because of all the meetings, you know, those 30 minute sitdown-standup meetings, architectrual reviews, deciding where to go to lunch, the post-lunch-buffet comma, “researching on the Internet, etc…. it’s all just unsynchronized schedules and little not attention spent on actually managing your staff’s time.

Source: Why My Company Serves Free Breakfast to All Employees

The coming licensing hassles with Dockerized enterprise software

indiana-jones-snakes.jpg
“Licensing. Why’d it have to be licensing?”

Jon Hall, who always has good things to say about traditional IT Service Management butting up against Melinum IT, points out an all too common hassle with new ways of packaging and running IT: accounting for traditional licensing. Here, he points out a likely licensing counting problem with Docker-ized applications, e.g., with Oracle licensing when it comes to the recent, official Docker images with Oracle software in ’em:

But theres a serious gotcha here: as any Software Asset Manager could point out, these actions could have just cost the company a pretty staggering amount of money. How? By falling foul of Oracles notoriously complex licensing system.
Oracle licensing is bloody complex, and its entirely possible that a goalpost or two might have moved by the time you read this.
Oracle Parking.jpg

Red Hat OpenShift Momentum – Highlights

Brian Gracely of Red Hat (and formally an analyst who did some of the best “cloud-native”/cloud platform work early on) has a momentum post on Open Shift. Here’s my highlights:

Sizing up revenue and deal-size:
[Q3, FY 2017] Also of note, we closed our second OpenShift deal over $10 million and another OpenShift deal over $5 million. And significantly, we actually had over 50 OpenShift deals alone that were six or seven figures, so really strong traction. [Q4, FY 2017] with our largest deals in Q4 approximately one-third had an OpenShift container platform component.
Red Hat hasn’t yet been too clear on OpenShift revenue, so you have to tea-leave out these revenue spreads, which I haven’t really done. Earlier in April, Jeffrey Burt at The Next Platform had this to say:
During the final three months of last year, subscription revenue for Red Hat’s application development-related [JBoss, etc] and other emerging technologies – which includes OpenShift – hit $125 million, a 40 percent increase from the same period in 2015, and revenue for the group accounted for about 20 percent of Red Hat’s overall revenues for the fourth quarter.
Today, we also announced that Barclays Bank, the Government of British Columbias Office of the CIO, and Macquarie Bank are also using Red Hat OpenShift Container Platform to modernize application development…. airplane manufacturer Airbus about their DevOps journey, and digital travel platform Amadeus about their transformation of handling 2,000x the number of online transactions…. how Amsterdams Schipol Airport (AMS) is using OpenShift to redefine the in-terminal travel experience, how Miles & More GmbH is better managing rewards programs for travelers, and how ATPCO is rethinking how they publish fare-related data to the airline and travel industry.
Much of the write-up focuses on community momentum, true to Red Hat, open source form:

The OpenShift Commons community has 260+ member organizations….

Red Hat engineers lead or co-lead in 10 of the 24 Kubernetes SIG activities.
Finally, some commentary on their strategic shift to Kubernetes:
The huge architectural shift that we made a few years ago in adopting open standards for containers and the Kubernetes container scheduler has allowed us to delivered a unified platform to containerize existing applications and deliver agility and scalability for cloud-native applications and microservices. We call this combination Enterprise Kubernetes+, or Enterprise-Ready Kubernetes.
Red Hat’s OpenShift is, of course, a competitor to us over at Pivotal.

Cloud-native at Comcast, working with Pivotal – Highlights

I’m doing a podcast with Comcast in a few weeks, so I’ve been going over all their public talks on their cloud-native efforts. They’ve been working with Pivotal since around 2014 and are one of the more impressive customer cases with over a 1,000 applications now on Pivotal Cloud Foundry.
Here are some highlights from the talks I’ve been watching. As always, things I put in square brackets are my own comments, the rest are quotes or summaries of what people said:

August, 2016 – Empowering Devops with Cloud Foundry – Sergey Matochkin, Neville George; Comcast

  • Sergey Matochkin.
  • Slides.
  • (17:00) Every deployment to production took at least 6 weeks, but most commonly around 2 months end-to-end. Which also means you need to plan capacity much in advance.
  • We started to use virtualization and containerization “well, well before Docker existed… it was some success, we had some improvements, but those improvements were marginal.”
  • Traditionally, it’d take at least 4-6 months to setup your dev/test infrastructure. But, luckily, virtualization came along.
  • (9:20) Business drivers… Comcast phone service, set-top boxes get DVRs, VoD, etc. All of these require apps on the backend, so the portfolio of apps starts to grow, and with they way they were before it meant they had to build a new datacenter every six months. Virtualization helped here, of course.
  • Also, virtualization allowed us to put a service layer [think “platform”] on-top of the infrastructure.
  • It’d take 4-6 weeks for testing environment, but now it takes 10-15 minutes in a self-service portal.
  • Demo of using Pivotal Cloud Foundry for much of the automation needed to deploy and scale an application.
  • (~32:00) We used to have things like “order servers” and “make load-balancer changes” and somewhere in the bottom of the backlog was “write some code and do some testing.” [That is, they were focusing on items with low business value, below “the value line,” rather than customer features.]
  • “What Cloud Foundry essentially helped us with was to get all those unnecessary user stories out of our backlog so we can focus on the writing code, on testing, and deploying rather than managing infrastructure.”
  • (33:45) momentum/proof-points:
  • momemtum
  • 9 PCF instances; 900+ developers; 2,000+ active apps “most of which are in “the critical path of our customer experience”; 4,100 application instances; 2,000 requests per second.
  • Lots of Slack/ChatOps usage for monitoring and such.

August 3rd, 2016 – Transforming the monolith at 20M tph – Nick Beenham, Comcast

  • Slides.
  • Existing state:
    • 250m transaction per day.
    • Would take 3 months to get a server useful, from moment of purchasing to using.
    • “Over a 100 services run by development teams.”
    • In functional, silo roles.
  • (3:45) “We knew we had that large, rigid infrastructure. [Pivotal] Cloud Foundry and it’s adoption really enables us to change that to gain the agility, to gain the elasticity at scale.
  • Taking away roles to reduce finger-pointing and all the negative stuff, and unified team, of course.
  • (7:35) Anecdote of Nick going from “ops guy” to writing code and liking coding.
  • (12:18) ESP router that was a small router written in Go to translate SOAP requests as part of a strangler pattern. Decades old SOA layer that they wanted to modernize. But they couldn’t strip it out, would take so long. So, were going to duck-type as SOA, but do REST and micro services underneath. Strangler pattern, etc. This is what the ESP router does marshals and unmarshalls between microservices and SOAP stuff. But new things need to be done in new style.
  • Also, “de-mingling data,” moving off Oracle RAC/GoldenGate for multi-site. Some simpler CRUD services to front the data.
  • (~15:00) Used to take a week+ to deploy the entire stack, but with Pivotal Cloud Foundry it takes minutes. It gives us a great deal of velocity that we’ve never had before. “Sometimes we’ll deploy multiple times an hour.”
  • (17:00) From 1,000’s of lines of bash to deploy out to various WebLogic clusters, which has for the most part moved to Cloud Foundry.
  • Improving production updates: bringing new node up and shutting old node down slowly; canary updates, with a CI test suite, then switching over to a production install.

August 1st, 2016 – James Taylor – The Power of Partnership & Building a Cloud Native Tier-1 Platform

  • @jctbmwi8
  • “Sparrow, Service Activation Platform.”
  • “Helping someone put a smile on their face is one of the greatest gifts we can give each other.”
  • Their VP provides the feedback loop of things to focus on. Right now: reducing technical debt, reducing incidents, increasing velocity, experimentation.
  • (~6:30) “You can’t move forward – innovate – if you don’t have time to try new things.”
  • (~18:35) “If you’re spending time configuring a Docker container, that’s time you’re not spending coding or solving a problem.”
  • (13:51): “At the end of the day, [business] value is what puts money in everyone’s pocket. If our company, Comcast, can’t create something of value, no one’s gonna pay for us…if we can’t create value. So it’s important for us to understand ‘how can you create value?’”
  • (~22:02, starting epic rant!) “Who is our customer and what value do we bring to our customers…”
  • If you’re spending money on support, that’s cutting into your margins. A call coming in costs $8 right off the bat, then more as it takes longer. So you want to figure out preventing customer support problems… which points to understanding your customers more.
  • [A good overview of thinking about “value” in the context of a specific application, their customer activation center, Sparrow.] “If you have a [support] call rate of 30%, you’re probably cutting out all the value… So we try to figure out, how do we prevent calls?” [Very similar to IRS cloud-native story.]
  • “We’ve been holding technical workshops”: Internal training things every month with Pivotal people, leveraging Pivotal knowledge. With our development teams every month: webinar, or on-site visit.
  • Sparrow: 5 junior Java developers… we built it from scratch in parallel while existing teams maintained the platform… we then had to integrate the processes together… figure out decomposing the monolith platforms, etc….then we had to just cut off stuff when it was too much of a hassle.

August 17th, 2016 – Greg Otto SpringOne Platform keynote

  • Slides.
  • X1 boxes – a new release about once a month.
  • Processing 10’s of millions of transactions on this new platform daily on Pivotal Cloud Foundry/new platform.
  • “About a 75% lift in velocity as well as time to market, and the business is really feeling it.”
  • Developer reactions:
  • comcast what customers are saying.png
  • Momentum Stats:
  • comcast key state from otto.png
    • 40 apps to 900 apps, 2015 to 2016
    • 300 AIs to 4,100 AIs, 2015 to 2016
  • All with “zero outbound marketing from my team, this all word of mouth from all those happy developers.”

June 9th, 2016 – Greg Otto CF Summit keynote

  • “Late last year in 2015” – live in production [on Pivotal Cloud Foundry] with business critical systems from our back-office systems on our Cloud Foundry environment.
  • We put Pivotal Cloud Foundry directly in the customer critical path.
  • Applications doing 30,000 event a second on Cloud Foundry.
  • Started in 2014, met with Pivotal.
  • Had sort of thrown all the people into the Pivotal Cloud Foundry pool, they had to do a lot of research and such.
  • But, people were really interested in the ease of working with the platform [the productivity improvements].
  • Successful prototype app 30 days after platform.
  • Idea to feature, before after: “several weeks, at least”/“2-3 days”
  • Time-line and summary:
  • comcast otto summary.png

June, 2016 – Open source at Comcast story

  • Write-up.
  • “If Comcast has a problem to solve, there are three possible approaches: solve it themselves by making an investment in teams and resources; solve it through a commercial vendor that could build a product for them; or work with the open source community.”
  • OpenStack: “In addition to Linux, Comcast is a heavy user of OpenStack. They use a KVM hypervisor, and then a lot of data center orchestration is done through OpenStack for the coordination of storage and networking resources with compute and memory resources. Muehl said that Comcast has roughly a petabyte of memory and around a million virtual CPU cores that they are running under the OpenStack umbrella. As an operator, Comcast does a lot of things around operations, and they use Ansible to deploy and manage OpenStack at scale.”
  • Cloud Foundry: “They also use Cloud Foundry, but according to Muehl that work is in the very early stages at Comcast.”

May 2015 – Running Cloud Foundry at Comcast talk

  • Neville George, Sam Guerrero, Tim Leong, Sergey Matochkin
  • They wanted to make custom URLs.
  • Used Puppet for stuff.
  • (~8:30) Their requirements for a platform:
  • comcast platform requirements.png
  • A lot of emphasis on self-service and the micro services benefits of operating independently, product management wise.
  • They use OpenStack, Docker, and [Pivotal] Cloud Foundry.
  • Pre-provisioning resources for a pool of containers that are ready to go, etc.
  • (~27) a couple applications in production today… we’ll be ramping up quickly.
  • (Either this video or the 2016 one, a few minutes from the end) Q, training mode. A, Sergey: “I can’t say we have a really good training model…. We do brown-bags to have people aware. We focus on 12 factor application model… on overall microservices model, not just to shape application, but also data. Developers need to understand how they [do] applications for PaaS instead of traditional.

Scaling DevOps in large organizations – My April Register column

apololypse_now_smell_of_napalm_in_the_morning

My The Register column this month is on scaling DevOps/cloud-native teams to the entire organization. It’s easy to build one team that does software in a new and exciting way, but how can you move to two teams, five teams, and then 100’s? It goes over the amalgamation of a few case studies and plenty of over-the-top gonzo analogies, per usual.

Check it out, and check out past ones if you’re curious for more.

The news from Docker-land, plus, the money being fought over – Notebook

With DockerCon this week, there’s no end of Docker quotables and items. Here’s my collection

General momentum

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.

Moby

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.

See more on this legacy migration stuff and the program with Avanade, Cisco, HP, and Microsoft from Docker’s Scott Johnson.

Major vendors

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 bundling middleware in Docker containers:

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:

  1. 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.”
  2. 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:

More

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.