Steven Sinofsky of a16z (previously Microsoft) probably first coined the phrase, “Don’t ship the org chart”. I think there’s a new variant of this worth discussing: shipping the microservices. I’ve been reviewing a few products in depth recently for different reaasons, and once you see it, it actually becomes really obvious.
Gosh, I wish I was at re:Invent. Personally, I don’t like the States much (the place is great; getting through the airports is an exercise in frustration) and while I’ve never been to Las Vegas there isn’t much that ordinarily attracts me to the place. But, to have so many incredible people in one place – amazing.
For those – like me – not there, what do the announcements today mean? I’m not going to focus on the tech so much, but more on the additional options and architecture that is becoming available. Let’s look at a strategic level.
I doubt there has ever been a time when software architecture was seen as a raging success. The “three-tier architecture” of the web has held up extremely well and is an excellent place for many people to start. The “12 Factor App” approach has encouraged developers to adopt practices that make deployment and scaling much simpler. Over the last couple of years, though, I’ve noticed developers advocating for architectures I consider to be extreme and limited in utility, foisting highly complex systems into startup environments at great cost. It appears to me to be getting worse.
Coming up with convincing vision and mission in a corporate environment is never easy – in fact, I think it’s one of the most difficult things you can do. Setting a clear and crisp vision is crucial to create an aligned organisation. Refining down into an elevator-pitch sized statement while avoiding generalisations, platitudes and (frankly) abstract jibberish is practically impossible.
Doing so outside a corporate environment I think is even more difficult – money is at least a straightforward motivation to hang a hat on. One of the best guides to doing this is Guy Kawasaki’s Art of the Start Manifesto, I particularly like the bit about making mantra.
The new mission for Fedora is:
Fedora creates an innovative platform that lights up hardware, clouds, and containers for software developers and community members to build tailored solutions for their users.
Unfortunately a few weasel words have crept in (“innovative”, “solutions”, “platform”), but I love the overall trust of it. The four foundations are pretty close to being a mantra and they’re indirectly reflected in this.
The main thing I find disappointing is that the mission ties in specifically to a few delivery mechanisms. Lighting up containers should be a consequence of the mission, and not be part of the mission, for my money. Containers are very relevant today – but are they going to be relevant in five year’s time?
Fedora is an operating system, the role of an operating system is to create an environment in which software can be allocated the resources with which to run. The end user value in having an operating system is precisely that you can run software easily. Having great support for containers is, right now, singularly important is being able to do that.
Let’s quickly thing about the future, though. Containers are one piece of technology, Kubernetes is a broader one. Day by day, I see more and more investment in k8s – to the extent that relatively soon we’ll need to think about k8s as an operating system in its own right. It’s never going to replace Fedora, and Fedora can run within k8s, but applications that run on k8s need to be quite specifically tailored for that – or even designed for that from the start. The whole story that k8s has is really about resource allocation.
Kubernetes isn’t the last word by any means. The true future is Serverless, which is coming at us at a rate of knots. Should this be part of mission? Right now, almost certainly not – but the mission should be the test. If the mission is about delivery of an environment in which people can run software, Serverless software will become increasingly relevant in that mission in the near future.
The really positive thing about the mission is that it can be used to test ideas. If something isn’t aimed at developers or the community, it likely doesn’t fall into the mission. Replacing legacy Unix is not part of the mission either.
If the redefined mission ends up being useful, it will be because it helps align the community and enables better, more consistent decisions to be taken – everyone will help push Fedora in the same direction. It will be great to see that happen.
There’s nothing that speaks more volumes than how a company treats its customers, and while it’s not the case that all their customers are treated this poorly, the fact they will go this low is shocking.
Employees are not “brand ambassadors”; as the agents of your company they are the ones building your brand. Customers aren’t always right, but when they are happy and talk positively about your company, you build your brand. Marketing and advertising help build awareness of a brand, good logos and design will give people an intuition about your brand, but the rubber hits the road when your organisation does things.
It’s always interesting reading how other people view strategy, and Vince Law’s WTF is Strategy? is a very entertaining read. Like a lot of my posts, it’s quite digital product-oriented, but I think these principles are pretty general and should apply for most people.
What is interesting is that one of the examples he uses – taking a road-trip across the States – is exactly an example that I cover early on in “A Practical Introduction to Wardley Mapping“. It’s different in some notable ways – his journey is east-west while mine is north-south, because the goals are totally different – but it’s very insightful that he chose such a similar example to mine to illustrate the point. This also helps point out the differences in our approaches!
Back in 2010 I wrote a post about Canonical’s business direction, in response to something Bradley Kuhn had posted. Both he and I were worried about Canonical becoming reliant on an “open core” business model – worried not just from the perspective that it would dilute the principle of Ubuntu, but that frankly every time I have seen this executed before it has been a dismal failure.
The posts are worth re-reading in the context of Mark Shuttleworth’s announcement today that Ubuntu will be dropping a number of their in-house technologies and, more importantly, abandoning the explicit goal of convergence. I would also say, read the comments on the blogs – both Bradley and I found it deeply strange that Canonical wouldn’t follow the RHEL-like strategy, which we both thought they could execute well (and better than an open core one).
Of course, our confusion was – in hindsight – obvious. We weren’t seeing the wood for the trees. The strategy has since been spelled out by Simon Wardley in his rather good talks; one example is here:
It’s well worth to take the time to watch that and understand the strategy against RedHat; but it’s pretty easy to state: “Own the future, wait for it to come to us”. Let’s see why this is important.
There are a lot of people with strong thoughts about brand and culture, and how the two relate to each other. From conversations I’ve had with others, I thought it high time to put my perspective down in writing.
I have a lot of time for this HBR article, “Brand is Culture, Culture is Brand“. It is absolutely correct to say that you cannot build a brand if your business culture does not / will not support and live that brand, and this is a fault seen so commonly. Business rebrand frequently; and it’s very common to see immediate push-back because the way the business operates doesn’t fly with the new brand at all.
However, I think things have to go deeper than this.