Container, DevOps, and Generative AI for Testing Usage

My work sponsored an IDC paper going over ways to use generative AI (and ML) at various stages of software development (the “Application Development and Product Life-Cycle Management”). There’s some interesting ideas in there, you should check them out.

As always, I like to collect the numbers from surveys and estimates. There’s some good ones in there! Here they are:

• “26% of organizations are using GenAI to support application development, testing, and management and 25% are utilizing machine learning with the greatest focus on leveraging AI to support DevOps analytics and process, governance, and security testing”

• “32% of application portfolios are built on containers and microservices today and, in five years [2028?], enterprises estimate that 39% of their portfolios will be built on containers and microservices” // I’m always after how many apps/workloads are running in Kubernetes. This is a new one! IDC’s numbers here don’t tell you which are running in production versus just in dev/test, but, whatever. Also, it’s “containers and microservices,” not just containers. // These are different estimates than a recent Gartner one: “By 2027, 25% of all enterprise applications will run in containers, an increase from fewer than 10% in 2021.”1 But, given that IDC’s is containers and microservices, maybe if you throw out microservices that are not running in containers, the IDC and Gartner numbers would be closer. I think the beers after work estimate, then, is something like: I don’t know, I’d guess companies are running something like 10% to 20% of their apps in Kubernetes? 20% seems, high - I mean, I just read the other day that 71% of developers don’t automate their builds and testing, right? So, who knows what’s going in enterprises. Anyway…want another beer?”

• “[E]nterprises are using DevOps methodologies to manage roughly 35% of their application portfolio today, with the anticipation of using DevOps to manage more than 47% of their portfolios in five years” // This seems like a better estimate than the headline one in the CD Foundation survey I looked at yesterday, which was (I don’t know the surveying name for this) synthetic conclusion based on the tools and practices people use, not the saying “we do the DevOps.” // Also, they’ll be spreading to 10% more of there portfolio over five years, to just under 50% of their portfolio under management. Change takes a long time! If we put the invention of DevOps as “[a]round 2007 and 2008,” we’re 16 to 17 years into DevOps and creeping towards 40% adoption. Probably fine, actually. It also shows you why we’re still talking about DevOps all these years later, and why there’s big windows for DevOps remixes like platform engineering.

• “[O]rganizations estimate that nearly 40% of their testing activities are automated, with ambitions to make almost 50% of testing activities automated in three years.” Now, this one feels bonkers. Who doesn’t automate their tests? Who doesn’t see the value in automating their tests? Well, could be that the someone in their team (or their org.) is automating tests and not the person answering “no” to this question. In my CD Foundation survey overview yesterday, I didn’t highlight the practices people said they used. “Test automation/management” use in the last 12 months was at 22%! So…I guess we’re to conclude that universal test automation is not universal. Bit of a WTF? there.

Above from “Applying Artificial Intelligence to Strengthen Application Development and Product Life-Cycle Management,” Pete Marston, IDC, November 2023.

Relative to your interests

• Spring Now Offers Free Access for the Spring Academy Pro Content - Free Spring training for all: “The Spring team has announced that the Pro Content from their Spring Academy will no longer require a paid subscription, effective April 5th 2024, to improve the learning experience for the Spring community. The Spring Academy will continue to provide new content in the future.”

• A Shift in LLM Marketing : The Rise of the B2B Model - Enterprise AI requirements are different than consumer AI requirements: “For a data-focused customer base, SQL generation, code completion for Python, & following instructions matter more than encyclopedic knowledge of Napoleon’s doomed march to Moscow.”

• IBM to acquire Hashi for $6.4 billion, seeks software boost - Enterprise AI businesses case are difficult: “But he also said buyers’ initial enthusiasm for generative AI has eased as they ponder whether it can generate return on investment. Users are finding that applying generative AI to a single business process could cost as much as $300 million, a figure Krishna said is unlikely to produce positive ROI.”

• Inside TSMC’s Phoenix, Arizona expansion struggles - Sounds like a shitty place to work! Long hours, sometimes filled with low value work. The TSMC people must think Europeans are insane. In contrast, for the American work-culture, this feels like a “thank the unions” story.

• The Chilling of TikTok - “the bigger concern will simply be the distraction of it all. Product decisions will take longer. Timelines will slip. Executives will be absent. Employees will leave.” // Yeah, never good for a tech company to feel under attack. They’re just not used to it.

Wastebook

• “The characters shouldn’t be able to end the entire endless night by killing a big bird.” Sly.

• “The Coddling of the American Parent.” Here.

• “You don’t need to raise a cow to have the milk. You just have to make sure that the milk can be delivered to your doorstep.” Prof. Hsu.

• “In LLMs as in humans, context is that which is scarce.” Here.

• Kubernetes Kopacetic.

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Atlanta Executive Dinner, May 22nd. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne, August 26–29, 2024.

This year, I won’t be at Cloud Foundry Day (May 15th in NYC), but if you’re going you can get 20% off with the code CFNA24VMW20.

🪵 Logoff

I’m starting to think I could put together a whole presentation based on these surveys. I wouldn’t want it to be negative, maybe something more like “hey, slow down, in the real world, everything is fine.” I need to come up with a talk to pitch for DevOpsDays Ghent - maybe that’d be good! A sort of “DevOps isn’t dead, it’s just super-chill”…?

The CD Foundation Survey, 2024

Today’s survey: “State of CI/CD Report 2024: The Evolution of Software Delivery Performance,” CD Foundation and SlashData, April, 2024.

Are people getting better at frequently releasing software and fixing problems in production? The most recent CD Foundation survey says…no:

• On average, 29% of respondents say they release software once a week or even more frequently; 40% take a more than month. The numbers here have been pretty stable over the past 4 years. This suggests that (a) improvement has stalled, and/or, (b) this is the normal baseline.

• 59% of respondents can fix production in a week or less, 40% in a day or less. This has gotten worse over the past 4 years. In 2020, 65% of respondents could fix production in a week or less.

Looking at the past 4 years of these surveys I also get the sense that we haven’t progressed very far with two of the goals of DevOps: more frequent app releases and fixing problems in production faster. This matches older surveys that show a very slow increase in release frequency, so slow that it might as well have stopped changing.

Does every organization need to release software frequently (weekly to daily)? Probably not, but in general what this survey tells us is not great. Does this means DevOps is a failure? Not at all: if you think these release cycles are long, you should have seen them in the 2000s and the 2010s!

My quick, hunch-made (read: “unscientific”) conclusion is that these numbers are “the new normal.” That means if asked how often enterprises release their apps, I’d say something like “about 50% of release their apps once a month or even daily (maybe 13% to 15% do daily or less?), and the other 50% take longer than a month, I’d guess most of those are quarterly.”

How frequently do most organizations really need to deploy, especially if you don’t count at-will bug and security fixes and patches? Does my pharmacy need to add new features every day, every week? My bank? The maintenance scheduling app my power company uses to send out trucks? Probably not. Maybe deploying once a month or more is actually perfect for most enterprises. What you’d like to see are survey questions that ask “and are you happy with this?” or “what are you plans, if any, to speed these up?” You’d want to divide these up by individual contributor and management/executives. I’d suspect the first would be like “meh,” and the second would like “fuck yeah!”1

To summarize: “You’re improving only getting slightly worse. Let’s put it like that.”

Deployment to production frequency

• The main question for app release frequency is: “On average, how often do you or your team deploy code to production?”

• In 2020Q3, 35% were at a month or more. In 2024Q1, it went up to 40% (this is bad, the wrong direction).

• The other time periods are mostly stable, but multiple deploys a day went from 12% to 9% over that time range.

• You glass half-full this and read it as: 60% of people release their software once a month or even more frequently. That reads pretty good, actually!

• If you want to get real detailed, you could pay close attention to the “you or your team” part of the question. This is different than “your entire organizations’ average across all apps.” For my purposes, the difference doesn’t matter.

How long does it take to fix problems in production?

• Fixing problems in production is measured her by time to restore service (MTTR)

• “The proportion of developers who can restore service in less than an hour has remained at around 11% since Q3 2022, though down from 17% in Q3 2020.

• However, the proportion of the worst-performing developers – more than one week to restore service – has been steadily increasing and is now the condition for 41% of developers.”

• Same point about “you and your team” versus “your entire org” as above.

Build automation and testing are not the norm

I use deployment frequency as the quickest/best metrics for measuring how we’re doing with getting better at software. Like I said above, you may not need to deploy at will. But if you’re doing all The Best Practices and DevOps Things, you should be able to deploy at least once a day if not more.

Can you deploy daily with manual deployments? Sure, we’ve all scp’ed files to production. Is that good? No. It is very not good. You want to automate your deployments, you know: Continuous Deployment. In an enterprise, like a big bank or pharmaceutical company, this is especially important because it’s the only way you’re going to reliably speed up the audit, compliance, and security bottlenecks.

Before CD, though, you need to automate your build and testing, you know: Continuous Integration.2

This has been known and recommended for a long time, 35+ years if I did the math right:

Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI [circa 1989] and did advocate integrating more than once per day – perhaps as many as tens of times per day. Wikipedia.

I’d add that Thought Works championed this, as did many other people, and it became a one of the foundational principles of DevOps.

So. How are CI and CD usage doing? NOT GOOD.

Let’s look at people who agreed with the statement “I test my applications for security vulnerabilities” across the last four years of the survey:3

Above you can see people who answered yes/agree to the statement In 2024Q1, 71% of people said they do not “use continuous integration to automatically build and test my code changes.”

One of the people who I asked to look over this pointed out that the wording of the question is for individuals (“I use continuous integration” instead of “My team uses continuous integration”). It could be that individuals on a team don’t use CI, but that their team does. This also points out another survey nuance: you have to be careful about questions that ask “does your organization…” versus “does your app/team…” For example, for the first you could ask “does your organization use Generative AI?” And if there’s just one person in a 300,000 person company using it, the answer could be yes. That “yes,” of course, is much different than if 40,000 people are using AI, or if the top 3 products in that company rely on AI. And, indeed, dear readers, you’ll know that I am always interested in how many applications/workloads are, for example, running on Kubernetes, not how many organizations are using Kubernetes.

For more on CI and CD usage, let’s look at a different survey that goes back further, the State of Agile survey.4 They stopped asking about tools usage in 2022, but we have surveys that go back to 2007:

These numbers are (much) better, but there’s a problem with the results from both surveys: improvement is flat. Things haven’t gotten better or worse in a ~10% band.

So much ROI in your future

So, something like 47% to 71% of people don’t do CI. I’m not sure what to do with that. I hesitate to even think it’s real.

¯\_(ツ)_/¯

But, let’s say this analysis is right.

What it means is that:

1. Need something to boost your annual bonus? If you don’t have CI in place, it should be easy for enterprises to get better at software by simply automating builds and testing. If you don’t have CI in place (never mind CD!), set aside everything else you’re doing and put CI in place. Anything new you’re doing in apps (cloud native, DevOps, Kubernetes, etc.) is going to fail (or at least fail to achieve ROI) if you don’t have CI.

2. If you can get people to pay for CI/CD, you’ve got a market goin’! Selling these tools is difficult because you’re selling to a group that thinks they can do it on their own and have small budgets - you’ve got to go in with a freemium/cheap option and at some point, you add in RBAC, and you can sell big, company wide deals.

Other Details

• This report is done by Slashdata. They have huge data sets and do many of the reports for the CNCF. If you dig around on their site you can find PDFs of their general survey, Developer Nation.

• Demographics aren’t covered very well. I can’t tell what percentage is tech companies versus “normal,” company size, or the split between management and staff in respondents. But:

• “We survey 30,000+ developers annually.” And: “The report is based on a

  large-scale, online developer survey designed, produced, and carried out by

  SlashData over a period of ten weeks between November 2023 and February 2024… from 136.”

• Everyone is doing the DevOps: “As of Q1 2024, 83% of developers are involved in DevOps-related activities.” // There’s some variation by industry and org. size, but it doesn’t really matter. People think of themselves as doing DevOps, and many of the practices are likely practices. DevOps Thought Leading wins!

• BUT! If you look at how they determine this, they ask what DevOps practices people follow. There are 9 practices, some of which are just general programming practices, e.g., using CI, automating testing. This is different than asking “do you do the DevOps”? I don’t really like this method, so I wouldn't draw any conclusion about how many people are “doing the DevOps.” Maybe how many people are using DevOps practices if narrowed down from those nine.

• It’s probably better to use fewer (if not just one) CI/CD tools than more: “using multiple managed CI/CD platforms has minimal impact on improving deployment frequency, but is much more likely to lead to an increase in low performance.” More: “One possible reason for this may be that lead time for code changes is impacted not just by platform usage, but also by their CI and development processes. Multiple managed CI/CD platforms may introduce fragmentation of the CI process, leading to greater negative impacts. Similarly, development practices like code review, collaboration, and testing may be impacted by having to adapt to multiple platforms throughout the workflow, and this challenge has a larger impact on lead-time performance.” I’m all for centralizing and standardizing tools/platforms/stack, so, sure, I like that one.

• I think the PDF is saying that if you use hosted (public cloud) CI/CD tools, things are better.

• There’s an attempt (which I’m really interested in) to see if running your tool stack on public cloud versus on your own is better. The answer is that doing both (“multi-cloud”!) is the best. I don’t think this tells us enough.

//

If you liked this survey review, check out the two recent ones on platform engineering (the Perforce Puppet one and the one from Port, also, a bunch of other ones from over the years).

🪵 Logoff

I’ll put some links and waste book stuff into the next episode. In the meantime:

• Yesterday, I had the wrong link for the “Things I Like” post I mentioned: here is the correct link.

• On this week’s Software Defined Talk, I interview Jana Werner about some digital transformation cards she and her AWS friends have been using when they work with executives. It’ll post this Friday (April 26th at 7am Amsterdam time. It’s good stuff! You can find it in our YouTube channel or by subscribing to the podcast.

• Here’s my case for buying you cloud native platform instead of building it. I’ll probably regurgitate this in a future newsletter as well.

When I look at recent platform engineering surveys, the results are positive: people see the value in platforms and platform groups. I’d say this is because platforms are helping speed up the app release cycle by automating a lot of the infrastructure work app developers would otherwise need to do, baking in/automating security and compliance, and, to a lesser extent, standardizing how apps are built, run, managed, and optimized.

Below are my notes one of the many, recent surveys.

The Port survey

Source: “2024 State of Internal Developer Portals,” Port, survey conducted October, 2023, published Dec 2023.

Major Take-Aways: The Internal Developer Portal (IDP) definition isn’t widely known yet, with only 54% of respondents following the survey’s definition. Backstage is the most commonly used stack, at 25%, followed by other commercial portals. The primary goal of IDPs is to increase developer productivity, reducing deployment time is a distant second. Respondents do a lot of DIY work and reporting for developer metrics.

Further Details:

1. Demographics. N: 100 full-time employees from the US and Western Europe with 150 or more developers. Geographies: 50% of respondents were from the US, and the remaining 50% from Western EuropeIndustries: 30% were from “tech,” 21% from insurance (!), 11% manufacturing, and then spread out below that. Company size: 89% of respondents were from companies of 500 or fewer developers.

2. The answers are from a management point of view: 99% of respondents were “management” or “executives.”

3. The survey was done in October, 2023. In a brand new category like developer portals, that’s a long elapsed time between then and now.

4. The definition of developer portal isn’t widely known yet: “only 53% use what we define as a portal, while 35% use spreadsheets with microservice data and 12% use a self-service platform that isn’t a portal (e.g. CI)”

5. People use developer portals to improve developer productivity, mostly (?) by removing waste and toil. In contrast, only 25% of respondents used “reduced time to deployment” as a measure of IDP success.

6. After that, there’s interest in making “ops” related stuff better: “easing DevOps fatigue,” security, compliance, and making Kubernetes easier.

7. What portals do people use? Backstage is the most common at 25%, and other commercial options at 17%.

Developer Metrics

When it comes to measuring that developer productivity, most people are DIY’ing it with surveys or custom reports: “Surveys (43%) and custom reports (31%) are the most common ways of measuring productivity, signifying a focus on either self-reported productivity or custom measures of productivity instead of frameworks such as the DevEx framework (15%), DORA metrics (5%) and SPACE (5%).”

The mix here is a little odd: DORA metrics and SPACE are actual metrics, not tools or techniques for gathering metrics. You could be measuring them in your surveys and custom reports.

Nonetheless, you can probably conclude from this that selling metrics software/services/solutions to enterprises is tough. Once DIY stacks are in place in development and ops, unseating them is difficult. They’re often “good enough,” can be customized, and cost zero.1

It continues to baffle me that anyone thinks DIY stacks are a good idea. It is a terrible idea for most organizations.

//

Also, see my notes on the 2024 Puppet platform engineering survey.

My Work: Tanzu, Tanzu, Tanzu!

This month we’ve been doing a “what’s up with Tanzu” media-blitz. You maybe recall this excellent overview I was involved in. Here are some other recent article and videos:

• "VMware’s Spring AI with Ryan Morgan and Mark Pollack," Software Engineer Daily, Lee Atchison.

• “The Evolution of Tanzu Post-Broadcom Acquisition: A look at VMware’s refined focus, ” SiliconANGLE, Victor Dabrinze.

• “Driving Software Agility with VMware Tanzu,” theCube, John Furrier.

• “Why Broadcom is Investing in VMware Tanzu,” SDxCentral, Emma Chervek.

• “Platform-Centric Cloud-Native Apps with Broadcom’s Purnima Padmanabhan,” TechStrongTV, Mike Vizard.

• “VMware says Tanzu is key to strategy after Broadcom acquisition,” SiliconANGLE, Paul Gillen.

• “VMware Tanzu Simplifies Accelerated App Delivery,” VMware News & Stories, Purnima Padmanabhan

Relative to your interests

• Most developers have adopted [D]ev[O]ps, survey says - I’ll have to look at this more, but: “29% of developers used continuous integration to automatically build and test.” This means that 71% of respondents are not automating their builds and tests. // “Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI [circa 1989] and did advocate integrating more than once per day – perhaps as many as tens of times per day.” // 35+ years later, here we are at 71%. WTF? Something is weird here, or just 🤦.

• Lessons after a half-billion GPT tokens - In nerd-space, the deflation of AI expectations has begun, finally, after a year or so of usage. This is good! We can finally just get to realistic work. Let’s get those insights on accounts receivable.

• Real-world gen AI use cases from industry leaders - Speaking of everyday enterprise AI uses…

• AI isn’t useless. But is it worth it? - “they do a poor job of much of what people try to do with them, they can’t do the things their creators claim they one day might, and many of the things they are well suited to do may not be altogether that beneficial.” // I’ve lost the links to all the Tweets-n-shit on this sentiment, but I’m more or less like this: most of the time I try house AI to create, it would have just been faster and easier to do it myself. AI is great of search and for learning (I spent an hour figuring out NPV and discount rateing as applied to non-economic thinking everyday life - ChatGPT was great at this!). AI is not good at creating…if you’re already an expert.

• Summaries of Airport Books - YES.

• The cloud is benefiting IT, but not business - “The central promise of cloud computing was to usher in a new era of agility, cost savings, and innovation for businesses. However, according to the McKinsey survey, only one-third of European companies actively monitor non-IT outcomes after migrating to the cloud, which suggests a less optimistic picture. Moreover, 71% of companies measured the impact of cloud adoption solely through the prism of IT operational improvements rather than core business benefits.” And: “Only 32% report new revenue generation despite having invested hundreds of millions of dollars in cloud computing.” N=“50 European cloud leaders.” // So, backward-looking FUD, sure <double hand-guns agreement>. But also: as opposed to what? Should we still be updating Windows NT servers with a binder full of CD-ROMs?

• Tech Time Capsule: Early 1990s Clip Art Captured an Era - Good stuff.

• Do software companies actually have good margins? - ’In other words, software development costs are COGS. Not literally; not according to the accountants. But in practice, if you can only sell SaaS software—and retain customers—by promising a steady stream of new releases, how are the expenses associated with developing those releases functionally any different than the money you spend on servers and support agents?’ // Counter-point: yeah, but their free cash flow is the best.

Wastebook

• “Management avoids firing people with paper trails.” Corporate Camouflage

• Domestic refactoring: re-arrange and clean the spice shelf. Move the pile of pills and bottles away from the bread. Stop buying so much bread. Use the wine fridge as the overflow fridge. Get rid of unused pans. Buy snacks you like. Save less leftovers: you’ll just throw away moldy goop weeks later.

• From the people who funded crypto, may I present: AI!

• Kids are less civil around their parents. They are different people w/r/t “don’t be crazy” around other people.

• Unless you’re working on the strategy, the planning, the ideation…don’t pay attention to the business sausage making. Just eat the sausage, or sell it.

• “is Santa effective?”

• One thing Noah Kalina a is doing is using his purposefully crafted awareness of being filmed as part of the “art.” He doesn’t always do it intentionally while filming, but he ends up using it as found footage in editing. This is especially, blatantly true in the ring-billed gulls on Seneca lake video.

• “If you have a barrel of water and this cantrip, you have a solution to most problems.” Here.

• “I wrote the first line in a loony bin in Massachusetts in August 2018. And the last line on Thompson Street in NYC last night.” Here.

• I did my annual thing of trying to use Obsidian. It feels so nice, but it is so much work…? Also, the syncing via iCloud is not good. I can’t get into the vibe. (See you never year!)

🪵 Logoff

I am thinking I should make a regular bit out of taking notes on surveys…?

Also, I made a list of things I like this morning. I found myself also typing up “things I no longer like,” which seems like a good follow-up.

Related: there’s not much, but I’m lazily figuring out how to use my weblog more.

Suggested Musical Outro.

When I look at recent platform engineering surveys, the results are positive: people see the value in platforms and platform groups. I’d say this is because platforms are helping speed up the app release cycle by automating a lot of the infrastructure work app developers would otherwise need to do, baking in/automating security and compliance, and, to a lesser extent, standardizing how apps are built, run, managed, and optimized.

Here’s my notes on one of those surveys, the one from Perforce/Puppet. (I’ll look at the one from Port in my next newsletter episode.)

The Perforce Puppet survey

“The State of DevOps Report: The Evolution of Platform Engineering,” Puppet, survey conducted August 24th to September 30th, 2023, published March, 2024

• Demographics: 474 people, 90% some kind of “management”; 44% in tech industry, 24% in ops and 19% in app dev; min. company size 500, 13% 50k or more; 89% from orgs with $50m+ revenue (16% with $2bn+); 38% NorthAm, 27% EMEA, 22% APAC.

• I usually toss out “tech industry” respondents - I don’t think how tech companies operate is “normal”: they use newer tech, pay IT much higher, typically already have good app and ops cultures, and defy most laws of enterprise CFOs and valuation. Outside of that, you have a pretty good mix of medium to larger organizations, and with 13% coming from, like, “Fortune 500” companies. Oddly, 67% said “I am on the platform team” - since 90% are some kind of manager…I guess this means that many of the respondents are platform engineering manager? I don’t know - anyhow - just something to keep around in the back of your head. It’s best not to over-think demographics in these surveys.

• Developer productivity is the top key benefit, followed by quality, and then faster releases (“reduced lead time for deployment”).

• There isn’t a common home in the organizations for platform teams. It’s spread across engineering, operations, and product. However, development seems to own the platform the most, with only 35% of saying that ops owns the platform.

• People believe the platform team is valuable: 65% say that “The platform team is important and is receiving continued investment”

• Platform product management is important: 91% of respondents agree that a platform product management is good (“important” or better) to have, 52% say they’re critical for success.

• “[M]ost organizations have had a platform team for at least three years.”

• “[W]e were surprised to learn that for a popular tool like Kubernetes, only 22% of organizations indicated that it was used in production, with a much greater 46% saying they had no intention to use the tool.” I’ll have to check the latest CNCF penetration numbers - but that seems…expected?

• Security - every vendor’s favorite topic! 60% say that platforms help speed up app releases because the platform has built-in security and compliance. “83% of respondents acknowledged that their platform team played a crucial role in enhancing their company’s compliance.” And most of the respondents agreed that the platforms help with security and compliance.

• Platform security helps lower risk (59% say), removed bottlenecks to growing the business (50%), and freed developers up (“48% reducing time for devs needing to learn security & compliance baselines” and “42% reduced manual work related to auditing”).

• Centralization is loose: 56% of respondents said their organization had 3 or more platforms. Last year (2023), 44% had 3 more or more platforms. This seems bad. The more platforms, the more things to worry about, and the less benefits of scale and centralization you get. Given the history of IT buying and app stacks over the years, it might be unavoidable. The answer here is to embrace this multiplicity and make sure you have standards and practices in place to make it work. Relying on open source tools - especially the shared architecture and config formatting - is a good start. Use Spring if you do Java development, use an open way of describing infrastructure (e.g., Kubernetes) and how to package and deploy apps (e.g., cloud native buildpacks). Still, it seems like a waste to me…

Who owns the platform? 👉 Who owns the budget?

It looks like (app) developers own the platform. For now.

The survey asks where the platform team resides in organizations. That is, who owns it. This usually means who owns the budget, who decides which platforms to use, and how much to pay for them.

Possible answers were in “engineering,” “operations,” and 'product." I’m not sure what the difference between “engineering” and “product” is.

If we assume “engineering” is “developers” (and probably application developers?), the platform team is in the developers’ organization for 44% of respondents, and ops for 34% of respondents. A 10% gap would be big enough to say something like “development probably owns the platform.”

Further, if we assumed “product” is part of development, we get 64% in development versus 34% in operations.

At the very least, you could say that ops is not the dominate buyer as only 35% of respondents said ops owns the platform.

This makes sense for en early developer-tools market. Developers are often the ones who bring in the new tools and they end up being accidental operations people. This happen[s|ed] with Kubernetes, with cloud, DevOps v1 automation tools, LAMP/rails, Java, etc., etc.

Eventually keeping the platform up-to-date, adding in new features, trouble-shooting (“carrying a pager”), dealing with security and compliance people starts to get tedious and boring for developers. As the chart above shows, the skills needed for running the platform are not application developer skills. App developers don’t want to own production. And if they do, they’re insane: they’re missing out on one of the primary life-style benefits of being a developer.

Operations will end up owning and running the all those accidental platforms, muttering “not fault, but now my problem” as they walk out of the hand-over meeting. This also means the budget shifts over to operations. That’s good, in a way, because operations typically has (1) a way bigger budget than app developers, and, (2) many more cost controls in place (you know, “FinOps”).

But, for now (and the next ~2 years?), it’s developers that drive most all of it.1

Selling platforms

For marketing, this means targeting developers, for product this means making it quick, easy, and cheap-to-free to use. For enterprise sales it means “ugh.” Developers usually both believe (1) they can do it all themselves (they’re developers, building software is what they do!), and, (2) they have small budgets (most of their budget is spent on people, see previous item). Those are both not fun for enterprise sales people who want to do six to seven figure deals. You want to sell to operations: they have the money and they don’t like building stuff on their own, they like running it.

An “enlightened” executive buyer would get ahead of this and buy into a centralized platform early (this is the case with many Pivotal/Tanzu customers), but most of the market ends up as an archipelago of misfit platforms. Because ops doesn’t product manage it well (it’s not in their skill set or traditional culture), the platform’s features get old and stale (but, it’s rock-solid!). The app developers get disenchanted and bored with the platform that ops is running…and they start tinkering with and building their own. The cycle repeats itself! So, you know, try to make better mistakes next time.

😎 Get a Proven Enterprise Platform in Place

Hey - speaking of, are you interested in a platform? We have several pre-shaved yaks you should use.

The first is based on the open source Cloud Foundry platform and has been used to run all sorts of enterprise apps by many enterprises for something like the past decade: the Tanzu Application Service (previously Pivotal Cloud Foundry, PCF). The second is a toolkit of components to build a platform on-top of Kubernetes, if you need that kind of thing: the Tanzu Application Platform. Both will run where-ever you like, public cloud, private cloud, etc.

If you want to get the bigger vision, check out the recording of this Tanzu overview I hosted:

I think it’s pretty ridiculous to build your own platform, but: I get it, my work sells those platforms, so I must be biased… ¯\_(ツ)_/¯

🪵 Logoff

No links or waste book today. But, here’s a quick idea to make solo roleplaying D&D even more fun.

Lots of original content this week, starting with this prediction about “enterprise AI”:

I also made these since last episode:

• Another go-round at figuring out playing D&D with ChatGPT. It went pretty well! Here’s my retro/analysis of it, and here’s the actual play session with inline commentary.

• I was the guest co-host on this week’s Cloud Foundry Weekly where we discussed the new features in the Tanzu Application Service 6.0. We, of course, spent a lot of time on the generative AI beta stuff that’s included. We discuss other new features as well.

• Software Defined Talk #462 - Lifting Code - This week, we discuss Matt Asay accusing OpenTufu of "lifting code" and recap the Google Next '24. announcements. Plus, we share some thoughts on camera placement and offer listeners a chance to get free coffee beans. You can also watch the unedited video.

Relative to yours interests

• IT departments are blowing their cloud budgets - “Nearly three in four (72%) of the IT decision-makers polled reported that their company exceeded its set cloud budget in the most recent fiscal year. Among the areas experiencing an acceleration of cloud deployments are: applications/workloads in IT operations (54%); hybrid work (50%); software development platforms and tools (45%); and digital experiences (44%).” // vendor-sponsored // has ranking of causes.

• Kubernetes community capitalizes on open source and AI synergies - Among AI talk, 451’s Kubernetes TAM: $1.46bn in 2023, growing to $2.85bn in 2028.

• Substack Is Setting Writers Up For A Twitter-Style Implosion – Home With The Armadillo - Seems weird. // “New reporting from The Wrap details how Substack’s decision to implement a new “follow” feature — part of its transition from newsletter publishing platform to social media site — has tanked subscription growth for lots of newsletter writers.”

• A simple model of AI and social media - “It is better to just start by admitting that the feed is fun, and informative, for many teenagers and adults too.” // I grew up in the Satanic Panic era, clowns kidnapping kids in vans around every corner, video games scrambling kid’s heads, skulls and boobs in ice-cubes, and of course fear of hip-hop. People actually thought that, across the country, there were Satanic cults trying to convert your children to worshiping the devil, or worse. It was in the news. A lot. I mean, you know [shrugs]: the 80s. So when I see people worrying about popular culture ruining The Kids, I’m immediately suspicious. // Also, I am part of the first generation of heavy Internet users (Gen-X), so I know what the analog world was like: from nothing, to beepers and pay phones, to alpha numeric pagers, the WWW, flip phones, laptops replacing desktops as the norm, WiFi, and then finally smart phones). The analog world sucked in comparison. iPhone 3G forever!

AI Corner

• Next ‘24 - Google Cloud CEO on why an open AI platform with choice, one which allows you to differentiate, is essential - Enterprise AI as a feature.

• ‘This shit’s so expensive’: a note on generative models and software margins - “The fundamental problem with generative models is that they are 10x too expensive to work with the industry’s default business models and structure. Either these companies who are going all-in on 'AI”'need to fundamentally change everything about how they work – laying off a bunch of people won’t make ML compute 10x cheaper so they’d need to change the org to survive on razor-thin margins – or they need to discover some undefined magical way of lowering compute costs 10x. So far they’re opting for magic."

• Counter-point: Notes on how to use LLMs in your product. - “Even the most expensive LLMs are not that expensive for B2B usage. Even the cheapest LLM is not that cheap for Consumer usage – because pricing is driven by usage volume, this is a technology that’s very easy to justify for B2B businesses with smaller, paying usage. Conversely, it’s very challenging to figure out how you’re going to pay for significant LLM usage in a Consumer business without the risk of significantly shrinking your margin”

• The Art of Product Management in the Fog of AI - “before products launch, it’s critical to run the machine learning systems through a battery of tests to understand in the most likely use cases, how the LLM will respond.”

• Amazon Isn’t Killing Just Walk Out But Rather “Pushing Hard” On It - Hmm, hopefully we’ll see some nuanced corrections in all them news outlets…

From the VP of Cable’s Mood Board, then/now, 2005/2024

Wastebook

• “You can never have too many chickens.” This guy is amazing. Internet art at its finest.

• “Meanwhile, I’m headed to Milwaukee this weekend to play pinball and get drunk. Perhaps I should rethink my life choices.”

• “Keep it up.”

• Word watch, “pink slime”: “Pink slime sites mimic local news providers but are highly partisan and tend to bury their deep ties to dark money, lobbying groups, and special interests.”

• They’re like the Karens of Europe.

• Mutually assured mansplaining.

• “Nexit.” NL Politics.

• News from the AI v. Human front: “You spend a week writing the 70 page doc only have [to] it sent back to you in 10 minutes. God help us.”

• “Everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” Here.

Logoff

My old pal Andrew Shafer bought a burger place in Tucson:

I know! I bet they’re good burgers - too bad I don’t get ti Tuscon much.

I don't think we really know what "enterprise AI" is yet, what apps will be helpful. So you need to just mess around and see what works. Come on a dog walk with me in Amsterdam and I'll tell you more.

Check out the experimenting we're doing with private AI in the VMware Tanzu Platform.

Logoff

No links or anything today, just the video above which I liked making. Will people actually watch six minute and 12 second video? Boy. I’m guessing not that many people will watching it all the way through. Too bad for them.

Last week I found Noah Kalina’s new YouTube videos, and, quickly got obsessed with them. So, I farted around with a little “future Coté” in this video. It’s fun.

Here’s two things of mine to check out:

What we do at my work

We broadcast our updated Tanzu overview yesterday. I MC it and do a Q&A session at the end. I tried to get a lot of my views of the platform engineering, what we do, build vs. buy, and the usual stuff in through my questions and the intro and outo parts. It’ll give an idea of what people do with our stack, you know, when it comes to building, running, and managing their apps. You should watch it!

Making Big-Ass D&D Maps with Generative AI

The second thing is a write-up of how I use Midjourney to make D&D battle maps. I even broke my 15 year hiatus and posted it on reddit.

I have a lot of pent-up material and commentary on how I do solo role-playing with ChatGPT (and other AI stuff). The problem in writing it up is that the time I spend writing it up is the time I could use to actually play. Maybe the “just start a live stream and push record as you play” option is what I need to get back to.

It’s fun re-entering this D&D world after (checks calendar) 33 or 34 years. I usually don’t like learning things new, let alone “on the Internet” because I really dislike the shame of being, like, ignorant and wrong. (Probably the number one reason I haven’t learned Dutch after 5 years living in Amsterdam.) But, with D&D, there’s a good mix of fun and safety when it comes to D&D. I don’t know if I’ll ever re-build the desire to play with a group of people, but, you know, it’s fun even being a learning-lurker in that world. For example, while there’s only a few replies to that post, there’s good suggestions in there that I’m excited to try out: better to overlay your own grid, and try out img2img. Learning doesn’t have to be shameful! It can be fun!

If “The Internet” has been one of my life-long obsessions (ever since that first day I logged into an AS/400 and starting typing up HTML files), then D&D was a very strong one before that. Mix the two together, and it’s a good stir-fry.

Anyhow! Check out some fun map making with AI.

Relative to your interests

Pile of AI stuff on-top here, mostly “enterprise AI.”

• AI - two reports reveal a massive enterprise pause over security and ethics - A preview of the next 3 to five years of “enterprise AI” as it nears then skis down peak of inflated expectations: “When we go into a CIO discussion, it’s ‘How can I use Gen-AI?’ And I’m like, ‘I don’t know. What do you want to do with it?’ And the answer is, ‘I don’t know, you figure it out!’”

• Don’t Get Canceled: How To Overcome GenAI Consumer Backlash - I am interested in enterprise AI governance and policy. I’m not even sure what that is! But what does security, audit, and governance look like for AI? What is DevSecOps, secure software supply chains, all that type of thing for enterprises using AI?

• CMOs Must Protect Consumer Trust in the AI Age - “only 20% of consumers are comfortable with businesses incorporating the use of GenAI into their operations, according to a survey by Gartner.”

• Americans increasingly using ChatGPT, but few trust its 2024 election information, Pew Research Center - Techmeme summary: “A survey of 10,133 US adults: 43% of those aged 18–29 used ChatGPT in February 2024, up from 33% in July 2023, compared to 27% of 30–49 and 23% of all adults”

• About Placemark.io - Is there room in the TAM for a startup like me? Seems representative of starting a software-business, there needs to be room in the market, a chance to make it big: “As I’ve said a bunch of times, the biggest problem with competition in the world of geospatial companies is that there aren’t many big winners. We would all have a way different perspective on geospatial startups if even one of them had a successful IPO in the last decade or two, or even if a geospatial startup entered the mainstream in the same way as a startup like Notion or Figma did. Esri being a private company is definitely part of this - they’re enormous, but nobody outside of the industry talks about them because there’s no stock and little transparency into their business.”

• Stop Chasing Unicorns - ‘When it comes to ways of working, what do the companies that beat you in deals do better product, design, and engineering-wise?" Silence. "Do they do better discovery and research, ship higher quality work, run more experiments, kill bad decisions faster, retain passionate team members, or have a more effective org design?’

• Skinny jeans hot for AW24? Two writers argue over the demonised drainpipes - Some real passion about skinny-jeans here: ’at least with skinny jeans there’s no chance of soaking up every puddle you slosh through on a rainy day, until the water reaches your knee and you develop a very real chance of developing trench foot. ’

• Redis vs. the trillion-dollar cabals - Defending yourself against the three public clouds.

Wastebook

• “Credit card issuers, when they screw this up, lose millions of dollars and dry their tears on money.” Here.

• Your cattle are my pets. Talk Theme.

• “Random acts of marketing.”

• Damnit, Jim. I’m a marketer, not a product manager.

• “We’re gonna need some more budget. No more Doritos for the rest of the FY.”

• “You fight like a dairy farmer!” (Example used by Gemini for something you’d have time to say with your free action in D&D 5e combat.)

• “Relative dearth.”

• “You’re pushing a rock [up a hill] that’s never gonna love you.” RoTL, #530.

• “Between you, me, and the microphone…”

• Living the dream: “Pelia related that what she found most challenging about her long life span was not the loss of friends and loved ones to time, but instead, boredom.”

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Tanzu Defined online, April 3rd (watch the replay!), The Internet. TEQNation, May 22nd, Utrecht, speaking. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne, August 26–29, 2024.

Logoff

Tomorrow’s Software Defined Talk podcast episode (“not illegal, works as designed”) is fun - we recorded it last night if you want to watch the unedited video instead of normal podcast-ery. Or, just subscribe to it and you’ll get it ready for your dog-walking, dish-washing, commute, or as good background noise for making your kids lunches in the morning. Those are the only sanctioned times to listen to the podcast, by the way.

Bye!

Relative to your interests

• Sometimes, Lipstick Is Exactly What a Pig Needs! - Abby Bangser, Syntasso & Whitney Lee, VMware - How can you start to take a design/UX-driven approach to building your platform (you know, your pile of Kubernetes stuff to pull it all together for app developers)? Whitney Lee & Abby Bangser have a good mind-model to think about designing the interfaces (how people use parts of that stack). Thinking through how you design your platform “interfaces” for app developers is especially important if you’re building your own stack instead of buying one of the already integrated ones.

• “Designing for Success: UX Principles for Internal Developer Platforms,” Kirsten Schwarzer, KubeCon EU, March, 2024. - Good tour of applying design-think to platforms. That is, what do designers do on platform engineering teams. Some items: (1) Do at least one hour long user interview a week. This gives you an idea of what your users (developers) are doing, struggle with, how your improvements are helping or not, and give you data to decide what to do next. The last is especially useful for fending off The Boss and others who have suggestions that are not helpful: show them the data about what is, at least that you do things driven by analysis, not hunch. (2) Progressive disclosure - only show what people need for a given talk, not everything the tool can do. Can help with cognitive (over)load. (3) Errors are a good source for finding what’s wrong.

• “Boosting Developer Platform Teams with Product Thinking,” Samantha Coffman, KubeCon EU, March 2024. - A lot of good commentary and advice on product managing the platform, some techniques, mindsets, etc. Chief among them: focus on the value/problem you’re solving first, then how you solve it second…also trying to quantify what the problem is so you can measure if it’s fixed, and prioritize it.

• State of Platform Maturity in the Norwegian Public Sector - Hans Kristian Flaatten - If you’re interested in how the Norwegian government is using cloud native stuff (like Kubernetes), this is a survey readout circa 2023/2024. The Q&A section is pretty great for walking through the usual concerns for a platform, especially compliance/governance.

• Ex-technology companies. - “Organizations that spun up dedicated in-house build and deployment infrastructure have fixed engineering costs to maintain that infrastructure, and the math that convinced executives earlier–some sort of argument about the multiplicative effect on the impact of other engineers–doesn’t make as much sense anymore. But often you can’t just stop maintaining those investments, because that would require slowing down to decommission the existing systems, and ex-technology companies have little capacity for maintenance. Instead they’re focused on survival or roleplaying the motions of rapid product development despite actually spending the large majority of their time on maintenance.” // This is pretty great! Finally, a business strategy model for deciding build vs. buy. Look at the costs of building, running, and maintaining your own stack over (whatever, let’s pick a number) 3 to 5 years. Is it higher than buying, assuming revenue is single digit growth? Put another way, with software, it’s the maintenance that kills your numbers. // Also, to ponder: “They no longer believe they can change the business' outcomes through R&D efforts, and as a result they shouldn’t include engineering as a major stakeholder in business decisions.”

• “Analogpunk, or, Tools, Shoes and Misery,” Bruce Sterling SXSW 2024 - He has a skill for turning mundane objects into lectures and relating them to culture. Put in direct link to MP3.

• How B2B Organizations Can Win With Younger Buyers - What the kids are up to. This feels like a description of youth of all generations. As the kids age in power, they both get tired, have their own kids, or otherwise just get tired and want to delegate, have help, or just coast. Until then: so much energy! So much flat hierarchy! So much energy! So much caring!

• Untranslatable - “We’ll let him do a trial run for a week first, to see what kind of meat we have in the tub.”

• 101 things I would tell my self from 10 years ago - “You are high in neuroticism, a trait that correlates with worse social relationships and an unhappier life. Sorry; there’s not much you can do about it other than be aware of it. Its saving grace is that it means you are attuned to what is wrong in the world and driven to fix it.” // Typical listical, but, sure, some fun stuff.

• The Justice Department Accuses Apple Of Smartphone Monopoly - ’When you’re as big as Apple, there’s a target on your back. The company’s market capitalization flirts with three trillion dollars, but more importantly, it commands a resounding 60%+ share of the smartphone market in the U.S. Therein lies the rub – our phones are the primary portal into how we live every moment of our waking (and sleeping) lives. What Apple chooses to allow or disallow has outsized implications for every provider hoping to get in through the portal and play a role in the digitally addicted lives of American consumers.’ And: “Apple’s obsession with its customer experience leads it to control the experience tightly, make decisions on its customers' behalf, and maintain an ecosystem that consistently delivers on the experience the brand promises. That philosophy limits choices for consumers. To that end, there is no dearth of people who are irked by this handcuffing and choose not to frolic in Apple’s walled garden. Then there are others who are part of the Apple family precisely because of the carefully managed ecosystem’s ease of use and intuitiveness.”

• A few thoughts on the Apple DOJ antitrust case, from someone who isn’t riding his first rodeo - “In organisations that are under antitrust pressure, ideas that might get put forward are held back, because people would rather not spend the time having them checked through legal and compliance teams. Acquisitions which a company might make don’t happen, because it would rather not appear rapacious or that it’s stifling nascent competition. And contractual clauses with partners can’t be as aggressive in locking them out of doing business in a way which doesn’t favour you.”

• AI means it’s Springtime for open source, says CNCF - “Bold words, alongside a prediction from the keynote stage that the cloud-native development market will be worth $2.3 trillion worldwide by 2029, up from $547 billion in 2022 – a 320% increase in less than a decade.” // Seems like a lot, especially when IDC forecasts the Kubernetes (“Container Infrastructure Software”) market to be $5.56bn in 2027. But, if you look at the CNCF “landscape” is basically all of infrastructure software now (a rewrite of the existing stack used to run applications), I mean…sure?

• From Here to GitOps and Back Again - GitOps as a feature of CI/CD.

• How People Are Really Using GenAI - It makes jargon-based work more accessible, and complex things easier to understand. Also, just some everyday uses. And: an alternative to the garbage filled results you get from search, a way to filter the Internet. // “just 10% use ChatGPT which enjoys 60% market share regularly”

• Late Night With the Devil: why people are boycotting the indie horror - “I’m not going to boycott an indie movie and the work of everyone else for what amounts to 20 seconds of AI title cards, because that doesn’t help artists either”

• Exit, Voice, and Loyalty - “The Exit, Voice and Loyalty model states that members of an organization, whether a business, a nation or any other form of human grouping, have essentially two possible responses when they perceive that the organization is demonstrating a decrease in quality or benefit to the member: they can exit (withdraw from the relationship); or, they can voice (attempt to repair or improve the relationship through communication of the complaint, grievance or proposal for change).”

• First custom brand font for TJ Maxx built by McCann Design - ‘The Maxx typeface has a family of four weights and is apparently “chock-full of little gems in the Open Type features”. Typing out two X’s will bring up the option of the famous XX ligature that appears in the logo. There are also alternative shorter glyphs for the I and J, “to close the leading more naturally in tight typesetting”.’

• Battle of the Redis forks? - Commercialized open source is a mess right now…for the past ₃ years. Like other types of software, cloud has really been, uh, “transformative.”

• Content Editing: How To Handle Major Rewrites - Pretty detailed guide to editing (corporate) content that isn’t good enough.

• Platform Maturity Model with Abby Bangser - Good framing: providing internal (dev) services to internal (dev) customers. (Abby has been doing a great job, devrel wise, in the past year+.)

• The Unbundling of ChatGPT (Feb 2024 Recap) - AI is a feature, not a product.

• KubeCon + CloudNativeCon - if you build it, your customers might not come. Why? - Platform as a product!

We’ll tell you what’s up with my work now. All the cloud, platform engineering, Java, development, cloud native, yadda-yadda you know you like stuff. April 3rd, coming up soon! You can watch in LinkedIn or YouTube. Register (for free!) at one of those two and you’ll get notified when it’s started and reminded after it happened.

Wastebook

• “Full Stack IT Elimination.”

• I’m sorry for your loss/thank you for your service/thank you, please drive through.

• “toddler-led walks” Here.

• “Richard Stallman, too. He is our hero. Stallman does not visit our Brain Dump hackerspace, because he refuses to use Google Maps on principle.” bruces.

• “I don’t believe in most recycling. I may believe in recycling cans, though I know it takes much higher heat to smelt. I may believe in non-intermingled paper pulp recycling. I may believe in glass recycling. I say may believe because I don’t know enough about it. It is possible it is all a sham. I do believe in French wine and the money it requires to buy it so I took a load of cans to my local recycling center on the way home from the swapmeet.” Coco’s Dispatch.

• “It’s so quiet, I can hear my hair grow.” Here.

• “Judy says the problem with lentil loaf is the word ‘loaf.’” Alex.

• “not an expert on the day of the week.” RoTL, #530

• “Essentially, level five is utopia.” Cloud Native Maturity Model.

• She is the only person who is more me than me.

Korean-flavored, American Soul food sold in the Netherlands, delivered by Internet-enabled courier. Back when my peers were throwing bricks into McDonald’s windows, they had no idea what was hurtling towards them - some real cyberpunk shit, man. Now, we’re the ones ordering this stuff. Plus: it’s damn good chicken. Their Korean chicken-fried cauliflower is amazing too.

Logoff

The solo D&D with AI has been rocky of late. I’ve hit the problem of the AI not being able to move to the next action. It lingers on a sort of “what will happen next?” cliff. Instead, I’m looking for it to take that active roll of moving the plot forward that a DM would.

I’ve been looking at the Plot Unfolding Machine (PUM) for some inspiration. It seems to be built around this problem in solo role playing. Instead of the usual oracle mechanics, injecting random plot twists, and inspiration for the solo-player coming up with a new story…PUM tries to get closer to saying exactly what happens next.

Also, I’ve tried Gemini Pro (I have a two month free trial). I don’t have the ability to upload files (because I’m on the EU…or just can’t find it), which is very limiting: you have to start all over. I thought the huge context window would help, but I’m not sure.

All in all, I haven’t been able to capture that wonder and awe of the first week of doing AI driven solo role playing. The work continues!

Many of the videos from KubeCon EU are on YouTube now, just days after the the talks were given. That’s pretty great! Here’s three talks from the Platform Engineering Day that I really liked. They’re primarily focused on what I’d call designing and product managing a platform. I’m a fan of the “platform as a product” notion - I came across it around 2016 or so at Pivotal and saw many organizations apply it. These three videos are in that general area: how do you build a good product that application developers will want to use and “get value” out of, not just deliver IT capabilities and services.

They’re worth watching all the way through:

• “Sometimes, Lipstick Is Exactly What a Pig Needs!”Abby Bangser, Syntasso & Whitney Lee, VMware - How can you start to take a design/UX-driven approach to building your platform (you know, your pile of Kubernetes stuff to pull it all together for app developers)? Whitney Lee & Abby Bangser have a good mind-model to think about designing the interfaces (how people use parts of that stack). Thinking through how you design your platform “interfaces” for app developers is especially important if you’re building your own stack instead of buying one of the already integrated ones.

• “Designing for Success: UX Principles for Internal Developer Platforms,” Kirsten Schwarzer, KubeCon EU, March, 2024. - Good tour of applying design-think to platforms. That is, what do designers do on platform engineering teams. Some items: (1) Do at least one hour long user interview a week. This gives you an idea of what your users (developers) are doing, struggle with, how your improvements are helping or not, and give you data to decide what to do next. The last is especially useful for fending off The Boss and others who have suggestions that are not helpful: show them the data about what is, at least that you do things driven by analysis, not hunch. (2) Progressive disclosure - only show what people need for a given talk, not everything the tool can do. Can help with cognitive (over)load. (3) Errors are a good source for finding what’s wrong.

• “Boosting Developer Platform Teams with Product Thinking,” Samantha Coffman, KubeCon EU, March 2024. - A lot of good commentary and advice on product managing the platform, some techniques, mindsets, etc. Chief among them: focus on the value/problem you’re solving first, then how you solve it second…also trying to quantify what the problem is so you can measure if it’s fixed, and prioritize it.

With platform engineering, we’re asking operations and infrastructure people to think differently about what they do and how they do it. We’re asking them to think in terms of products, design, customers. This is in contrast to the traditional/current way of thinking about infrastructure which is more like: you tell me what capablites, capacity, and uptime/reliability you need, and I will deliver it to you. What you do with all that is not my concern. This is fine!

When it comes to a platform, though, the platform engineering people are want the platform team to solve problems for developers, not just give them the foundation needed to run their apps. These are different concepts, skills, tasks, and ways of thinking than existing infrastructure think and many won’t know exactly what to do. The talks above, then, are good at walking through new ways to think about “delivering” infrastructure, new ways to evaluate and plan for how you stack things together and gather up requirements.

There’s more videos to check out from the little platform conference, and a ton from all KubeCon, of course.

Oh, and also: If you’re thinking about building and running platforms. You’re probably thinking of just piecing together your own out of free parts and little doo-dads here and there. That usually doesn’t work well. We have a fine selection of pre-shaved yaks you should try instead.

Check out the video series here.

Wastebook

• “The Old Town is Old and the New Town is … well, less Old.” A correspondent on Edinburgh.

• “Grandboss” and “great-great-grandboss.” Here.

• “Something I’ve been thinking about lately.” Here.

• “Add it up.”

• “Build something cool that also meets my company’s requirements for security.” Here.

• There’s not always an “always,” even if there’s often a “usually.” Ibid..

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Tanzu (Re)defined online, April 3rd, The Internet. Tanzu (Re)defined, April 11th, Palo Alto. TEQNation, May 22nd, Utrecht, speaking. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th.

Logoff

In case you didn’t notice it, if you’re interested in what Tanzu (where I work) is all about, we have an online event now, on April 3rd. It’d be cooler to go to the in-person on on April 11th, but it’d be coolest if you make it to at least one of them. The online one will be broadcast in YouTube and LinkedIn. Sign yourself up for it, why not?

I’ve written a few (little) business books, reviewed several, and reviewed several proposal for business books. Here’s what I think works well in proposals you’re sending to publishers:

1. The publisher is in it to make money first, “important” content second. Your proposal is a business pitch, not an idea pitch. Make sure you talk about who the audience is, why they will buy the book, and why your topic (the market for the book) is hot, or at least, room temperature. Remember: the publisher is looking to sell these books for $30 to $50 a piece. They better be worth it!

2. Defining the market/topic and why it’s “hot” is important. While they may publish a lot of books, publishers aren’t experts in the topics you’re covering, and becoming an expert isn’t what’s important to them. Selling the book is important. Don’t go too long on the market, but try to talk about why the market (current trends, what people want to buy, and why alternatives are not going to be as good as your book [or simply don’t exist]) is good and why this is the right time to publish a book, and why you’re the right one to write it.

3. Be brief (unlike this list!). You should have three sizes of your pitch: a 3 to 4 sentence email/paragraph; a one page version; a longer version. As the author, when you’re writing the proposal, you’ll find yourself wanting to go over the ideas and the actual writing. This is where you’ll write too many words. Summarize the take-aways people will get, quickly cover how you will teach people those lessons/take aways, and really focus on the next thing:

4. Focus on what will differentiate your book for the thousands of other already out there and that will be out there in the future. What is new, different, and unique in your book? New methodologies are good, just going over the basics not so much. Case studies and stories are the best because they’re often unheard and unpublished: they’re something new.

5. Have a detailed, “real” outline at the end. This will give the acquiring editor a quick idea of what’s in the book and also show that you’ve thought this out. Don’t worry about sticking to the outline as you write it, it will change and everyone knows that. In your outline, make sure to the differentiated stuff, especially case studies.

6. Talk about why you’re qualified to do this, why you’re an excellent choice. For business books, I would focus on your first hand experience if you have it. Did you work at an actual company, or are you just a consultant or working at a vendor? Do you talk with a lot of people in your community and have you gathered lots of stories over the years? In most cases, you won’t be a fun and entertaining writer (you’ll be a good writer, but being fun and entertaining is a whole other skill-set), but if you are, that’s an asset to emphasize as well. You will need a bio section, so put all this in there. Be sure to list any written material you already have, even videos and talks. You need some examples of your writing, hopefully published.

7. What fame and community can you bring to the book? Again, the publisher is in it to make money. How can your existing audience, network, etc. help make the book more money.

Other considerations:

• Most publishers have their own template to fill out. They’re all general the same sections, just in different order, wording, length allowance, etc. Don’t get too hung up on getting your original pitch perfect because you’ll need to make it fit to whatever those templates are. Make the pitch in the template “perfect,” of course. And, obviously, just recycle the content.

• Keep in mind that the publisher is also evaluating you as both a writer and as someone to work with. Proof read your text for basic writing mistakes and spelling, typos, to/too, lose/loose, affect/effect,1 etc.; use a consistent style on things (e.g., either end all bullet point lists with incomplete sentences with a period or don’t, use contractions or don’t, etc.) - you want to show that you’re meticulous about your writing and pay attention to the details that non-writers don’t even know exist; and try to demonstrate that you won’t be a handful to work with. Favor a “natural”/conversational style over formal, business speak. Write in the first person, use contractions, and try to use simple words instead of business bullshit words.

• Some publishers do more than just books, so keep their business models in mind when pitching. For example, O’Reilly publishes books (focusing on a single sale of an e-book or 3D book), has an online collection of educational stuff for corporate accounts (focusing on making the ongoing subscription valuable), makes video series (here’s a really good one!), and licenses content to vendors for marketing/lead-gen.

Finally, just keep at it and don’t take anything personally. If they come back with questions and suggested changes to your proposals, work on those. That may seem discouraging, but as long as you’re still talking, they haven’t said “no” yet. Also, be nice: if if this proposal doesn’t work, they might be one in the future or other work you can do with them.

Proposals aside, for me at least, the most important thing is to start writing the book once you have the idea. Certainly propose your book to publishers, but don’t wait on it being accepted. In fact, if you’ve already written the book, or just large parts of it, proposing it will be easier.

Good luck!

I’ve been mentioning the in-person event we have about my work, Tanzu, here. We also have an online version coming up on April 3rd. I was in Palo Alto last week filming it. If you’re wondering what’s up with Tanzu (the Cloud Foundry stack, our Kubernetes stuff, our Backstage/etc. platform, the Spring Framework, etc.) now that we’re part of Broadcom, you'll find out at this event. You can of course register for free to see it: right here! I was there the whole time, so I can assure you that it’s good stuff.

And if you want to attend the in-person event on April 11th, then sign up here.

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Tanzu (Re)defined, April 11th, Palo Alto. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th.

Logoff

No links today.