Coté Memo #082: Disrupting with high prices, indulging in colonialism porn, and dying among the tomatoes. Oh, and Docker!

Come to the Austin Docker Meetup this Thursday (Jan 7th) to see me and some much smarter people talk about “The Container State of the Union.” See below for some of the “prep” work I’ve done. Also in this edition, new types of disruption theory, compliance in DevOps, books, and an interesting link round-up.

Tech & Work World

Resetting Prices

Disruption theory follows a template: a new competitor starts with an inferior product at a lower price, finds success, and eventually takes over the market from the leaders. “Inferior” here means less features, capabilities: something that’s less appealing. At least that’s the interpretation that seems to win every 2-3 years when a big debate about disruption vs. Disruption comes up.

As an example, you can see some advice on how FitBit can win against Apple:

Zino, who maintained a “hold” rating on Fitbit shares, said the company should focus on products that cost less than $100 and have an intense focus on wellness.

A FitBit watch would be cheaper and less featureful than an Apple Watch. And that brings up the interesting point, as it’s the Apple Watch that’s “disrupting” FitBit, Jawbone, and all the others.

There’s a clutch of companies now-a-days that use high-end offerings to suck up market-share from low-end competitors, Apple being the chief among them. In this model, you start with a more expensive, usually more featureful offering (though not always, sometimes it has less features in the name of design elegance!) and, more often than not, don’t really lower your prices much. Instead, you seem to “rescue” lower price expectations, “resetting” the price. iOS devices are an example here, of course, but I think the pricing of other things – like public cloud and SaaS, depending on how you slice it up – are good examples as well.

You can see Uber doing the same (they started off as a black car service, after all). If you’ll pardon my lazy-lack of researching, it feels like there are others who do this: my own company, Pivotal, arguably is doing this in the application development space (our products are far from cheap, but we’re capturing a lot of market-share).

Let’s look at Apple more as an example: all their hardware is much more expensive than alternatives, and sometimes even has less features! That’s confounding in itself. There are times when Apple is more expensive and has more features, e.g.: the Apple Watch definitely has more features than a FitBit or an analog wrist watch. Again, Uber is an interesting example: they started at the high-end and are now going down-market. Maybe Silver Car is in the same bucket.

I’m not suggesting this cancels out Disruption theory at all, but like the boys often suggest, it seems like there’s a different type of disruption on the rise that isn’t talked about enough.

You can do all sorts of business theory gymnastics to re-define the job to be done to make Disruption theory work. Horace Dediu did this very well, long ago, in his analysis of the iPhone: it’s category was the PC, not the mobile phone which brought with it some of my favorite charts ever (see an updated version of the concept that better highlights the amazing growth of iOS).

Along those lines, usually, the cult of “big d” Disruption shuffles this type of “beyond Disruption” thinking off as “sustaining innovation,” which just means the industry improving their existing offerings and businesses. I’m sure that’s often the case, but I keep thinking there’s a new model in there somewhere.

On the other hand, I get the feeling that if I had some actual numbers and 3-5 other industries to look through, all of this would seem kind of silly. Another good trick is to look at market-share/revenue vs. profit. Again, Apple is instructive here: they may not always take all the revenue, but they seem to dominate in profit. It’d be interesting to run this kind of thinking versus Amazon Web Services and the trail of dead that have tried to compete with it. I have no idea what kind of business theory explains all that.

Dealing with compliance in DevOps

For my column last month-lyish, I wrote up some tips for dealing compliance and audit people when you’re “doing the DevOps.”. These things really apply to any type of cloud-enabled IT, mostly. As ever, I think the main points are: if you talk with people more and really understand what they need, then go understand your tools and what you can do with them, most things are achievable.

Check it out, I’m curious to hear how you deal with this stuff. It comes up all the time, and the answers are usually not very concrete.

Container State of the Union

I was asked to be on a panel this week for the Austin Docker meetup: it’s this Thursday, Jan 7th, 6pm, at the Rackspace Austin offices. My role here – other than trying not to shill too much for Pivotal – is to be a pretend industry analyst…I think. You may recall I tried to sort out WTF “container orchestration” was back in 2014 with CloudSoft. That’s pretty much what I’ll have to do; as dedicated readers no, I have no idea what I’m doing…but I can PowerPoint the shit out of any unknown!

Speaking of, here’s some fun-facts I’ve gathered so I can hopefully shuffle through some big, blue index cards like a nervous person:

451 Research on Container Adoption

  • Above, my old colleagues at 451 (Jay and Donnie) have a good way of looking at container adoption: 21% of surveyed people are doing something with Docker, 6.3% in production. That’s n=991 from their 1Q2015 Voice of the Customer research.
  • Run on 6% of the hosts DataDog monitors, n=7,000. “At companies that adopt Docker, containers have an average lifespan of 3 days, while across all companies, traditional and cloud-based VMs have an average lifespan of 12 days.” (DataDog, Fall 2015.)
  • Earlier in the year, New Relic said that the average life-span was 3 minutes, across 300 customers “using an aggregate of 40,000 to 60,000 containers daily.”
  • Anecdotally, in most all of the customer visits I go on or hear about, Docker is on the short list of things to look into. Obviously, companies don’t always end-up picking it by far (451 only had production use at 6.5% above…but plenty of experimentation): Pivotal Cloud Foundry had a run-rate of $100m/year based on 2015Q3 numbers, so plenty of cash in this small market is going to alternatives. We’ll see how it pans out.

Anyhow, come check it out the panel if you’re in the area!

Shameless Self-promotion


Over the Christmas break, I finished up some books…and started new ones:

Quick Hits

A lot of time has passed since the last memo, so there’s more links than this. As always, follow my links in Pinboard or Tumblr if you want more real-time junk to read:

Fun & IRL

“Cease to React At All”

If you are willing to look at another person’s behavior toward you as a reflection of the state of their relationship with themselves rather than a statement about your value as a person, then you will, over a period of time cease to react at all.
Yogi Bhajan

When I was studying Eastern philosophy in college, I had a strange relationship to Buddhism, Taoism, and all that. It seemed like giving up so much and disengaging with the world. The idea that the ultimate idea was not Logo-atic truth, but “nothing” seemed weird.

Now that I barely have time to contemplate what “nothing” even means, I value the idea of letting go a lot more. Somewhere between becoming self-less, table flipping, getting the kids ready for school, a fine bottle of bourbon and steaks at home with family, Vito Corleone dying in the tomatoes, watching the tech industry, and Courtney Barnett on repeat…is a pretty good place.



Coté Memo #081: The best steak I’ve ever eaten, and the slow train problem

Tech & Work World

How Microservices Fixes the Slow Train Problem

I write little columns for the internal Pivotal newsletter we have sometimes. Here’s one that’s about to go out.

The ideas of “dependencies” and “coupling” are important touch points for understanding and conveying the software delivery benefits of a microservices approach to architecture.

“Coupling” between services means that changes to one service have a big impact on another service. Coupling is considered bad in software architecture. Among other reasons, strong coupling usually means that each service can only be released as “fast” as the slowest changing service. For example, you might have an identity service and a reservation lookup service. Let’s say the reservation service can be updated weekly – the team working on it is fast! But, the identity service releases takes six months. Thus, the reservation service is forced to deliver on a six-month schedule.

Among other things, microservices remove the release cadence dependency. The goal is to allow each service to evolve as fast as makes sense for the business. Of course, there are some “new problems” to address:

  1. Ensuring backward API compatibility is a good idea. If we remove or change parts of identity services’ API and don’t change the reservation system, things break. Thus, it’s good to slowly remove functionality (or never do that!) with lots of testing, with the ability to rollback changes if/when things go haywire in production.
  2. Services should be able to isolate failures in order to “quarantine” errors in other services. If there’s an error in the identity service in production, we’d like the reservation service to gracefully fail. Operations patterns like the circuit breaker included in Spring Cloud, help manage these types of operational complexities.

Another benefit of decoupling services comes from shorter release cycles. The longer you wait to release code, the more code you’ll bundle into a release. Six months worth of code, across multiple services is a lot. When errors occur in production – and they will! – finding bugs in this ball of yarn will be much harder than finding the bad code in, say, a week’s worth of code.

Train Tracks

Think of it as train tracks. If five tracks all converge at one point, a problem on one of the tracks can cause confusion and delay for the other trains’ schedules—they’re strongly coupled. If each of the five tracks operates on its own schedule without having to converge, then of course there is no cascading schedule problem.

New Pivotal Cloud Foundry Release – a $100m/year business

Pivotal Cloud Foundry diagram

Pivotal Cloud Foundry 1.6 – there’s a new version of the product I work on (well, not coding, but you know, in my capacity of whatever it is I do). Check out my quick summary of what’s in it and, from the dormant analyst in me, an attempt to write-up the customer momentum we have.

I notice that most coverage of Pivotal doesn’t really focus on the business side of things, which is going excellent – like, we make real money and all that! Other than being nifty, I like that aspect because it means people (“customers”) find our work actually valuable enough to pay for.

If you’re interested in more “market talk,” check out the podcast I did with James Watters on the topic, GM of the business.

And, here’s some more coverage of Pivotal Cloud Foundry 1.6

Shameless Self Promotion

Quick Hits

Fun & IRL


I that steak at Roast in Detroit. I think it might be the best steak I’ve ever had. Would eat again, many times.



Coté Memo #080: Come on, register for this God damn webinar

This week is a lull in travel. I’m closing out the year by going to lots of DevOpsDays (Charlotte, where I’m speaking, and Silicon Valley next week), a few internal summits, and my first Gartner show, where I’m speaking in a sponsored slot.

Tech & Work World

Shameless Self Promotion

Journey Time

I finished up my “cloud native journey” series recently. The real title should be something more like “how not to fuck up your cloud strategy.” Obviously, it explains the type of thinking and environment that Pivotal Cloud Foundry is built for, but I spend most of the time discussing “culture” change in an organization, regardless of what technology you use.

Check out the series, and if you’d prefer the hear me present it, we have a three part webinar series, the first one is out next week, Nov 5th with the next two coming out in December, on the 1st and then the 15th.

There’s also a preview of the first webinar in the form of my slides if you want to poke at it.

Back to Evernote

Clearly, I’m the kind of person who switches between things a lot. After a long time using the old plain text files in Dropbox approach, I went back to using Evernote. I missed the “all in one thing” nature of Evernote and the ability to put images in there. This is sort of possible with markdown and plain text files, but not as easy.

After re-wiring all Drafts to save things to Evernote and a few weeks of usage, I think it’s pretty good. The iOS apps are responsive enough, and I also like having 7 years of my stuff in there. The related notes it shows in searches are interesting. The geo-location’ing that Evernote is also interesting. I enjoy looking through my digital past with as much data as possible to refresh my memory.

Now that I’m not getting briefed all the time (and instead spend most of time creating content rather than in meetings) I don’t actually take that many notes.

Quick Hits

Fun & IRL


At first, I thought this was a costume of a motion capture suit. “Light Up Stick Man” makes a lot more sense.



Coté Memo #079: No Comment, Slack Behavior

Tech & Work World

No Comment

Big news for the company I work in this week. Sadly for my desires to write about and link to interesting stories on it, I have to take a pass. It’s bad form for employees to comment on any of this stuff; and since I worked at Dell on strategy and M&A for software and cloud, it’s double a bad idea. There’s a lot of good write-ups out there, enjoy them.

Slack Behavior

I complain about Slack a lot in the SDT podcast, but, really, it’s a good, effective collaboration tool. The more technical people use it at Pivotal: we’re waiting for the sales and corporate marketing people to get in there. Once everyone gets in, I think it’ll be great. The idea that it not only cuts down on email but speeds up decision making (and, thus, action) is very true, anecdotally for me at least. Daily I find myself about to send an email and then thinking, “I should just write to the person in Slack or put this in the channel.” In that respect, it’s much like instant messaging, to be sure.

In the marketing/evangelism groups I’ve been in, we don’t do much with the integrations – early on we played with things like Trello integration. The integrations clog the channel up a bit.

What I’d like to see more of, in our use, is thinking more about how we use: making the implicit explicit, as it were. For example, we had a discussion about what the “available”e icon means. Does it mean someone will respond back quickly? Nope, not in out Slack “culture”: it doesn’t really mean anything, people will reply when they reply.

The other thing we should try to do more is create channels for ongoing “threads” of conversation. For example, we have a #DevOpsDays channel to discuss our participation on those conferences.

Anyhow, it’s a good tool. Slack is at that difficult point now where they have to balance throwing in new features and changing nothing at all. It’ll be fun to see what they come up with. I’d love to have a Google Hangouts/Skype/Zoom that works perfectly and seamlessly. They used to call it “unified communications,” and it’d be nice to have another go at that.


I’ll be at several events this Fall and Winter:

If you’re at any, I’d love to meetup and talk with you.

Recent Podcasts

Recent Posts &co.

Quick Hits