There are many things I like, but these are some I can think of now1:
If you are thinking “but I’m not on that list, don’t you like me?” Don’t worry, I love you even if you’re not on the list. ↩︎
I like are.na - it’s fun, and not icky. Having to pay a little bit to post more than 200 items has a great filtering effect on the content.
Anyhow, I wanted to include the things I put in are.na here, on micro.blog, but finding their RSS feed is elusive.
Thanks to Fridaycat, I found how. If you look in their source code, you can see that all you have to do is append /feed/rss to the end of an are.na channel page and you get an RSS feed.
So, now, when I post something to my inbox stream on are.na, it’ll get cross posted to my blog. Fun!
I’m a Texan living in Amsterdam, so when I come back to the States (Dallas and Austin this time), I noticed things about American that I never did:
Originally in my newsletter.
I’ve started writing this bit two times (see the community one and the one on ICs vs. managers for what happened instead).
If Twitter fails - or I stop using it - I’m looking forward to recalibrating my sense of urgency.
One thought going around is that no one would want to rebuild Twitter (I hear it most in the Ben Thompson Podcast Universe). I haven’t verified the business-side, but that seems true from the business angle: Twitter isn’t, like, that great of a business and has failed to figure it out like the Facebook Conglomerate.
Then there’s all the negative things too. Here, Twitter is like guns: too easy to use for bad outcomes.
After using Twitter for so many years, my sense of urgency is too short. I think in quick cycles and don’t have that “slow work” or “slow living” approach to most things.
I notice this with my kid’s education the most. School for kids is a long, long game. They have to learn to “do” school, which can take years and isn’t really taught in school. You know: keep track of assignments, due dates, make sure you understand what you need to do for each assignment (e.g., a five paragraph essay format; showing your work in math; adding those extra layers of work that show you’ve understood the higher-level ideas and synthesized them into some output), etc. These are all things office workers do without thinking, but kids don’t even know they exist - they’re unknown unknowns.
When my kids don’t learn these things the first time I explain it to them, or the 20th time, or the 30th time where I’ve tried to orchestrate some tricky way of teaching them, I get frustrated. But my timescale is just an hour, a week at most. It should really be, like, five years…ten years.
The same goes for that publishing vs. managing bit also here.
Another example is the rise of platform engineering and how quickly it’s gone through the full thought-leader cycle.
Backstage has been out for awhile, but it wasn’t until about February of this year (when Gartner wrote a paper on internal developer portals), and then this summer with all the devrel/PR-campaigns that Humanitec has done, culminating in BackstageCon that platform engineering came to the top of the heap.
About three weeks ago, there were the usual series of marketing-opportunistic articles saying “DevOps is Dead!” You can tell when this crest happens when there’s 1+n articles on The New Stack stating it as such - or if both The New Stack and InfoQ publish the same article, just written differently.
The response to the dead-thing was swift, and actually pretty good. It was like, “hey man, don’t harsh our vibe and all the work people have put into this thing for the past ten plus years. Be kind!”
This was a very fast loop!
I don’t remember how long that loop took with SRE, but I think it was longer and more…thoughtful?
But, the urgency model we use now made us all think too quickly about platform engineering and try to create a whole new category. Indeed, my theory is that, really, platform engineering is purely about internal developer portal and the tools team (the “DX team” if you like) - basically, the SDLC tool suite developers use. With a name like “platform engineering,” thought, it’s easy to also pull in the runtime environment - the IaaS and PaaS layer. (And, boy, kubernetes is really looking for it’s PaaS layer - so that world will grab onto any thing that floats by.)
But, this conflation of the two probably isn’t accurate or helpful. And I’ve done it myself!
With the Twitter-speed urgency though, you have to process and come up with takes quickly like this. You can’t sort of just let it play out and see what happens.
Anyhow: it’d be great to have less urgency. The thing with Twitter-speed urgency is that, really, it doesn’t matter. I mean, you could summarize the last two weeks of Twitter like this:
The long awaited PE buyout closed and was followed quickly by layoffs and uncertainty. For example, after laying off half of the staff, some had to be hired back. The new management team was unusually brash and rude, damaging the brand reputation of Twitter. Some big-name advertisers who were already unsure about the value of putting ads in Twitter began to worry about the association with Twitter, paused spend, and went into a wait and see posture. The new team followed the philosophy of “move fast and break things” when exploring new features, but because their theories were wrong, eventually slowed down to take a more considered approach. Meanwhile, the service stayed up, defying expectations. Clearly, the new management team has a lot to learn and even more interest to pay. More than likely, this was all a bad idea.
Following the minutia is fun, but I have to say, there’s not enough of it to make it rewarding. There’s only about one interesting thing every two days - so I’ve realized, there’s no payoff to checking all the time.
…the point being: my urgency calibration is all screwed up from Twitter-brain. And, you know, it’d be great to slide back to blog-brain urgency, at the very least.
This urgency is more about the expectations I set on myself rather than my craving for “news.” One day, I hope to be satisfied with one, solid piece of work published weekly rather than worrying about doing a quick-trickle of a bunch of small things.
Some commentary on a recent survey commissioned from my work, VMware.
Unsurprisingly, open source is used by almost everyone. When it comes to what I care about software development, open source is indispensable. In fact, it’s hard to imagine a developer who only uses closed source software, if not whole systems like kubernetes or Cloud Foundry for running their applications. It’d almost be impossible.
And, indeed, in our State of the Software Supply Chain survey this year, 2022, 90% of respondents said they were using open source in production.
Still, I wonder what those other 10% are doing!
Do they write all their own software? They’re not running Linux in production I guess, either.
What’s holding those 10% back?
There’s so much they’re missing out on. For all this praise about open source for me, what are the benefits of using open source?
80% of people said reduced costs. Now, a lot of people will tell you that open source isn’t free. What they mean is that the cost of labor to use and maintaining it (upgrading and security patching) in staff time and pay…but clearly people are benefiting from open source overall being cheap. And, of course, many companies pay for commercial support and closed source tools for the open source stuff they use.
Cost was also the number one benefit in our 2021 survey.
The other benefits were flexibility, support from a large community, and developer productivity.
All of these are the promises of open source and what we’ve come to expect over the decades. Indeed, if you look the reasons people chose open source and then the benefits they got, those expectations pretty much line up. For example, 50% of people said they expected developer productivity as a benefit, and 52% got that benefit.
Let’s look at the concerns people have.
Security is what we should really dig into since it’s such a big concern. Now, I don’t think the concerns about security mean that open source is NOT secure. I don’t really think that’s the case at all. I think open source tends to be as secure as any other type of software, closed or run in the public cloud. What’s important is that you have the right process, packaging, and management in place. Again, this is important for anytime of software. Open source software is as secure, or, if you like, as insecure as closed source software. Make sure to get the right tools in place.
I want to add my own criteria for using open source that you should consider: make sure there’s a thriving, well supported community that you can depend on for the long-term. There’s two reasons for this: you want to make sure you’ll get community-based support when you’re learning how to use the OSS and troubleshoot it. Also, you want to make sure over the years that new, innovative features are added.
A thriving community will address these criteria.
What you want to do is make sure that community and the vendors and cloud services you work with prioritize getting updates and patches out for their open source packages and services. And this is about more than “security”: it’s just upgrading to new versions of the projects you use to get new features and performance improvements.
You want to have the processes and tools in place to deploy those updates as soon as possible, ideally without taking down production and stopping the business from running.
The container-based applications that run in kubernetes and Cloud Foundry - both open source! - provide excellent ways to do this nowadays. For example, the US bank Wells Fargo runs many applications in containers and because of how open source is packaged and managed in their platform, they’re able to deploy updates multiple times a week without disrupting their applications and, thus, business. I’ve seen this across banks, government agency, retailers: you name it.
So what you see in our second survey, here, is that with the right tools and process in place, and managing how your open source is packaged, you can get tremendous benefits from cost savings to developer productivity. The added bonus is that these same controls for open source can be applied to your own code and software. Securing open source is important, but the more important problem to solve is securing your own software. That comes down to the same thing: tools, process, and package management.
Once you have those controls in place, you can get that innovation engine going.
From the report “Top Strategic Technology Trends for 2023: Platform Engineering,” Paul Delory and Oleksandr Matvitskyy, Gartner, Oct 2022.
This report is free to download, my work licensed it. If you’re reading this, you’ll find it useful, so you should go read it!
Securing Your Environment with Tools Before Rules
My colleague Bryan Ross talk about security in the whole cloud native world. There’s plenty go shift left, and something called “shield right.” Also, he concisely explains the value of having a container-native build service (here, the Tanzu Build Service) and how you can get developers securing their code (better) from the start with Accelerators (templates), and buildpacks.
I think buildpacks are one of the more impressive, under appreciated things from the Cloud Foundry community. The idea of, well, preventing developers from building their own containers is huge if you want control over security, governance, and even basic things like instrumentation and other production management concerns.
You may recall this Bryan from this excellent talk he gave about his experience running a platforms in large organizations. If you’re in this whole cloud thing, you should really watch it if you haven’t.
Looking at four months of numbers, here’s my theories of how to get more attention for my enterprise tech videos:
I do a lot of videos for my work - selling kubernetes and appdev stacks for enterprises, along with the services/consulting that go with it (hey! VMWARE TANZUUUUUU!). Over the past two months I shifted from longer form vidoes (30-50 minutes) to tiny ones.
Sort of counter-intuitively, tiny videos take just as much work as long ones - lots and lots of editing, making subtitles, making zaney thumbnails, and all the usual uploading posting around. Sometimes tony videos take more work than just uploading longer, 45 uncut minutes.
The results are dramatic though: the shorter videos I do get a lot more views and “engagement” than the longer ones. This fits common SEO, social/influencer hustler folklore: no one likes long form content. After over 15 years of podcasting and presenting and blogging, I know that folklore isn’t, you know, universally true.
The following tables are incomplete, it focuses on the tiny videos. See the taller table that follows for the numbers for the longer videos. (Click for the larger version of each chart.)
Table 01 shows the Dec 2020 and Jan 2021 tiny videos I did. I’ve been very time constraint of late (we have to - er, get to - home school a seven and ten year old, and also need to watch a 10 month old), so I’ve shifted to doing these small videos in the time I can find, often when I’m taking my baby daughter on a walk and she finally falls asleep:
Table 01: Tanzu Talk tiny videos (and some long), Dec 2020 to Jan 2020.
Table 02 shows the tiny videos I did back in the Spring (2020). I was similarly time-constrained - technically (and, mostly - hey, my therapist has helped me recognize that I’m a workaholic, but, like, the content I produce for work is my passion - my work isn’t just yelling at supply chain people and arts and crafting PowerPoint slides and pivot-tables…OK…I’ll take a breath…) I was on paternity leave, so I had to snatch the times I could. I uploaded these videos to my personal YouTube site (the Dec/Jan ones are on the VMware Tanzu channel), so their YouTube views are shit:
Table 02: cote.pizza tiny videos, Spring 2020.
I call these “cote.pizza” videos because that’s the URL for a CTA I had.
Then, for comparison, Table 03 the views for all the Tanzu Talk videos - most of them are long form and were only hustled with YouTube links in Twitter, LinkedIn, etc.:
Table 03: All Tanzu Talk videos, tiny and long, 2020
There are some key findings:
The major component I’m missing is following what happens when people click a CTA link. I encoded most all links I use for attribution to me, but I, of course, didn’t tell any of our web-funnel acquisition people this, so I don’t know how get those numbers. This would be extremely valuable info.
On the other hand, the price range of software and services (six to seven figure deals) I help sell is so high that having just one click, or just someone having seen and been influenced by my video evne though clicked nothing trackable.
Also, I’m concerned about echo chambers. Many of the “engagements” (likes and stuff) I get are from co-workers, which I value tremendously! There are, though, a sort of knowable set of “customers” who also engage. I need more insight into how far out of the echo chamber I’m reaching.
Let me state this clearly: I have no idea if all of this is helping the business. BUT IT SURE IS FUN TO DO!
All of that aside, let me tell you a (depressing?) secret: the only thing people care about are raw views. There may be some quibbling about completion rates, CTA following, etc.: but at the end, people will just remember the raw numbers. (Still, I’d like to have more visibility into the money I’m helping bring in and retain, but, hey, as I like to say, “I get paid either way.")
Oh and… HEYYYY, GUYYZZZ! Three, two one! LIKE AND SUBSCRIBE BELOW!!
Some additional notes as I think of them:
There are two types of digital transformation. First, literally. You had an analog process (booking appointments at the barber shop with phone and paper, planning tanker refueling schedules with a white board), and now they’re replaced by pure software. These transformations are often about optimizing an existing business process, gaining huge cost and time efficiencies (bottom line revenue, profit) and resulting in higher customer productivity and satisfaction (top line revenue, “growth”). You might call this sustaining in the innovator’s dilemma canon.
Then there’s creating new business and innovating existing ones. Here, you use custom written software to create a new line of business (in-Home hair cuts) or make an existing one better (ordering pizza from an Apple Watch, using drones to do auto accident claims, entering a new market, wealth Management for lower income people, on-demand [uber like] Long-hail trucker scheduling).
The line between the two can be blurry (is using drones for claims inspections really just changing an analog process to digital? A better one might be doing spot/temples insurance [i want to buy a three hour policy for broken limbs and such minutes before I climb into a zip line, grocery curb-side or home delivery]). But don’t get too worked up about it: the work you end up doing ends up being the same.
The point of the distinction is more to make sure you don’t forget about one or the other. Sometimes you need a dramatically new line of business enabled by software, and sometimes you just need to transform a whiteboard into an app.
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:
This is the common OpenStack meme for coverage. Each Summit there’s more and more users - “customers” - but it will take a while before OpenStack is suddenly us an “overnight success.”
Looking at it from a different perspective, OpenStack is one of the biggest, new model for open source development: they’re iterating on the concept and mechanics of open source in new and novel ways, deep in bazaar mode vs. Fred Brook’s surgeon model, to mix metaphors and ages.
I think it’s best to think of OpenStack as a continuation of the Eclipse model, that isn’t really too explicit about it: the point of the overall effort is to provide and commoditize all the common components needed to make cloud software. The vendors - be try ISVs, service providers, or SIs - who take those common components make most of “the real” products (not all, of course). If there happens to be a fully functional cloud platform as a result apart from vendors, even better.
What’s incorrect in my comparison is that this doesn’t seem to be the explicit mission of the community. Indeed, I think holding back from a strong mission like that is intentional: and that’s where the OpenStack is more like the ASF. Unlike the ASF, the OpenStack community isn’t opposed to profit and business; those ASF guys seems allergic to it (which maps to their mission perfectly well).
Hence, it’s all sort of new. I don’t really know what “The Model” is yet.
See also Nancy’s piece on the meme.
The great OpenStack conundrum: with 15,000 members, why is adoption lagging?