Coté
Coté
The eternal principles of an (enterprise) app stack
Suggested vibe for this edition:
The eternal principles of an (enterprise) app stack
These are not all of them, but it’s a start.
The function of an app stack is to allow your developers to be creative, use fast release cycles, and create software that can run in production: that stays up and meets whatever compliance (regulations, security, etc.) you need.
We keep trying to merge the dev tools stack and the runtime tools environment into one platform. The market rejects this over and over again. At some point, we should try listening.
It follows that: you will probably end up with a separate stack of developers tools, middleware, and runtime infrastructure. Perhaps our best bet is to focus on a common “API” (in the Kubernetes sense of that word, which, coming from a app dev background, I find an absurd use of that notion, but the street finds it’s own uses, etc.) that makes it easy to interoperate and integrate all those separate parts. Builders will build. At least give them some common set of patterns and interfaces.
Still, I think this assemble a best-of-breed pile of parts is, I don’t know, pretty stupid. You’ll always end up with an integrated, monolithic stack (a “platform” as we say now). Just make sure it’s not an accidental platform. Fully integrated platforms are proven to work. When you try to take them away from app developers who’ve finally given them a shot, the devs beg with you to stop standing up Kubernetes. (But, I have little credibility in my opinion here. I no longer do software, I just do slides.)
Building your own app stack is a bad idea 90% of the time. Everyone will think they’re in that 10%, but, do the math. If you build your own app stack, you now own it and have become a software company. Software must be a core part of your capabilities a. Is IT a “cost center”? Then this will hard to impossible. Buy an integrated platform and developer tools, whether that means committing to a public cloud or buying a layer of abstraction to layer on-top (“multi-cloud”).
Your app developers will dislike whatever you (the infrastructure people) do. They are wrong, if you do your job well. App developers always want to use the newest, most interesting thing. They will say anything to justify using it, and then they will hide using it. App developers don’t appreciate the need for long term stability, agility (you can change things, add new features quickly), and compliance/governance/security. App developers don’t care about the “ilities.”
Infrastructure people have the opposite problem: they overvalue the ilities and sacrifice app dev usefulness for them.
Of course, “the business” has one last “ility”: all for free, without changing anything…ility.
We tried service delivery to solve this, but despite intentions, it just created a wall of tickets that slowed things down and made stack evolution too slow. (How long does it take a brand new developer to make their first code commit? Even at Spotify, this is constant battle. Imagine what it’s like at a 80+ year old bank that doesn’t even track that metric!) Service delivery is very good at delivering a known and needed service, it is not good at building systems around constant change, i.e., software development and delivery. Otherwise: why would we be constantly talking about all of this? The system is defined by what it does, not what the builder’s intentions we’re.
Try something new! Try product managing the app dev stack. Talk with the app developers every week and follow a small batch cycle to improve the platform.
Technology matters a great deal. What also matters is that your process (how your work, how your organize, how you people manage - “culture”) adapts to the technology you’re using. You can’t force-fit technology into a culture. Try changing the culture to work with your technology. Change culture first. If you can’t change the culture, you need to change the technology. If you can’t change the technology, you have to change the culture.
The business does not want to be eaten by software. “The business” still doesn’t understand the value of software, that it can be the core enabler of the organization’s strategy, optimization, and growth/profit. I’m not sure they ever will, so you have to constantly prove this with metrics and success. “Speak the language of business” to the business. (It’s not like us tech people understand how “the business” functions either - we should do rotations, at least through the corporate strategy group…and vice-versa. Post-DevOps, the business/IT wall is the next wall to bring down.)
Above all else: (1) define what “working” is for you, and, (2) if your ability to build and run software to run your business and improve your business is working, keep doing that. Otherwise, change. Don’t keep doing things that don’t work for what you need.
Here is the obligatory common sense quote to put in big letters on a slide: “There is nothing so useless as doing efficiently that which should not be done at all," Peter Drucker.
Vacation is unhealthy for work, work is unhealthy for vacation
When start a vacation, I have to quickly detox myself from the daily habits of work: seeking and executing tasks; an eye on long term deadlines; carving out a space to operate on a large, mature company; interpreting and responding to strategy and group think; valuing delivery, making things happen above all else. In short, thinking about work all the time, using constant scheming to hedge against uncertainty. This mindset can’t be turned off, it even invaded my dreams from time to time. There is no work/life balance, there’s only work/life interruption.
When I’m going on vacation I have to stop thinking about work and thinking in that get shit done mentality. I have to stop thinking.
I’ve finally gotten the time that that flushing out work-mind takes to about eight hours. It used to be two days or so!
Vacation mode has no goal, little planning. Just reacting to possibilities, or not. There is no constant business case evaluation that drives action. Perhaps I’ll think a few days ahead to book museum tickets or a restaurant, or know that on Monday many things are closed. But I might decide to just stay in the hotel room for the night and read a book, or just sleep. My goal is to relax, and to do things that are relaxing. My goal is not to maximize the ROI of time or money spent. My goal is not to produce or deliver.
When I come back from vacation, the shift back to work is jarring, and difficult. It’s like I’ve finally experienced what it’s like to “be normal”: to have life be your job rather than your job your life.
For a long time this was fine, mostly. My identity was so based on work enough (almost completely!) that it was easy to shift back. But, just like recovering from a night of drinking, as I age, it’s getting harder and harder.
Well.
Back to work!
Upcoming
Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.
Sep 6th O’Reilly Infrastructure & Ops Superstream: Kubernetes, online, speaking. Sep 6th to 7th DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking (get 50% of registration with the code 50-SRE-DAY) Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking. Nov 6th to 9th VMware Explore in Barcelona, speaking.
Logoff
The weekend in Paris with Kim was great. We spent hours in the Picasso museum and the Musée d'Orsay. At some point, I want to figure out how to go to all of the little galleries in a town, the ones with new, contemporary art. I do not know how that “work,” though. How you find the “real” ones, what you talk with people about if you’re confronted, how you prioritize and choose them: how you succeed at it.
Kim helped me discover a pathology of mine: if I don’t know how something “works,” I am afraid of doing it. This is probably why it’s hard for me to learn new things, and, thus, change and improve. It also limits my, like, experience of the world. The negative effect is compounded by my living in Europe where I always don’t know the languages, cultures, norms, etc.
I used to have a set-piece with my therapist on this: going to the butcher. In our previous neighborhood here in Amsterdam, there was a much aclaimed butcher just down the street. We don’t have much butcher availability, really, in the States, let alone sprawling Austin, Texas. (Instead, the grocery stores have plenty of good meat.) I love meat, and the meat in The Netherlands grocery stores is, well, you know, not to my Texan liking. The butcher had the good meat though. But, because I didn’t know how “going to butcher” works and I don’t know Dutch, I never went. It was a double hump of not knowing how something worked. Kim once got me a t-bone for father’s day, and it was magnificent. Somehow, I could get over that double hump and start gettinggood steaks.
Hopefully I can get over this needing to know how something “works.” At this point, it’s what’s holding me back. Sure, what I need to do is instead crave “learning.” But we all know what we should be doing and thinking, the trick is getting there.
***
No links this episode. I barely read anything online since last time. Instead, I read A Waiter in Paris over the weekend. It’s fun to read a book set in the place you are, especially on vacation. It was a good book, you should read it if you like that kind of thing.
