Beware of High Expectations in Enterprise Tech

Here are three charts.

First, while everyone is freaking out about AI, it’s had little impact thus far:

Second, since 2020, usage of cloud seems to have leveled off at a 50/50 split between on-premises and public cloud:

But don’t worry, everyone is planning to move more to public cloud in the next three years. At least that’s been the case for the past seven years:

There are some rules of thumb for the impact of new enterprise technology here:

1. It will probably take much longer than you think.

2. The business value you achieve will probably be less than you think.

3. There’s not as much urgency to “transform” as us vendors would like you to believe.

The AI craze is an especially interesting case for me. It is clearly a big deal. I never used Docker, but the first usage of ChatGPT is what it must have been like to use Docker. You don’t believe what’s happening, it’s so effortless, and you can immediately start getting value from it.

For enterprises, however, things are more complicated. Just as you wouldn’t want your developers doing whatever they wanted with Docker - especially just downloading images of the Internet and, like, using them to run your paycheck processing, missile guidance, or just where to ship this box of celery systems - you don’t want ChatGPT just running around willynilly inside your enterprise. Even more: it can’t. You can’t just upload everything to ChatGPT and have it do wonderful things. Believe me: I’ve tried!

You can imagine all sorts of stupendous improvements to how a company operates if they unleash AI on everything. But, it will be less stupendous that we think, and take much longer. First, you’ll need to make sure all the governance and (as we’d say in the consumer world) privacy concerns are taken care of. This isn’t just about annoying lawyers and security people being annoying, it’s often to comply with regulations and laws. And it’s often a good idea!

Then, you have to figure out a way to actually load all that data into THE AI MACHINE. Access to all that corporate data across old ERP systems, CRM systems, Salesforce, email, Sharepoint, Google Docs, etc., etc. is already fraught and difficult. We’ve tried “data lakes” and…well? One of the main issues here is paying for all of that.

If you’ve ever tried to do what seems like simply pulling information from Salesforce or other ERP systems, you know what I mean. You rarely can just do what should be simple. First, you need access. And you’re going to have a get budget for that. Second, you need to actually understand the format the data is in. Third, you need the skills to actually find, clean, transform, and build reports out of that data. What this means is that you can’t do it alone: you always need to know “a guy” who can do it on the side for you. (Sidenote: if you’re working in a big company, always be looking out for this “guy.” If you see some really good charts or data in a presentation, ask who put that together and take that person to lunch so that you can ask them for help in the future.)

ChatGPT like systems could make this all much, much better. But it will take time, and it might not just, like happen as fast or as broadly as you think. Compare that to the public cloud usage in the above charts. We all know that using public cloud makes totally sense for any given apps. We all know that there are very few technical reasons to do it. We all know that the costs are, at worst, net-neutral. And yet…it’s going to take us three years to get there, apparently.

Why so slow?

This emerging technology adoption ass-dragging is driven by numerous things. The price to use new technologies and switch over to use them is often too high to easily deal with. If you’re serious about building an app platform on-top of Kubernetes, you’re going to pay a lot more money than you think. For a the smallest enterprises (let’s say, 5,000 to 10,000 people or more), you’re talking about millions of dollars a year. That can be either in staff if you want to DIY, buying vendor/public cloud services, etc. Just paying for the operating systems - a “free,” open source operating systems! - is going to cost millions. I have no idea how RHEL pricing works at this scale, but if you look at Salesforce’s numbers (moving 200,000 servers to RHEL), they feel like what big banks, large retailers, large government agencies, and other enterprises would face. That’s got to be, again, millions of dollars a year.

These costs are often worth it. You need computers and I’ve heard software is eating the world. However, when you introduce a brand new technology with such a steep price, you’re talking 12 to 18 months to get going. Enterprises work on annual budgeting cycles. If they’re using a regular calendar year for their fiscal year, you start “socializing” your budget needs around October, figuring out what you need, making deals with peers, sniffing out what your budget approvers actually value and will approve, getting your PowerPoints all prettied up with arts and crafts. Then you pitch it towards the end of the year. The budget is approved, then everyone disappears for two to three weeks for the December holidays. You come back in January, sort of putter around for a couple of weeks, and then you start finish talking with your vendors and public cloud people (who, hopefully, you started talking with back in October), finally selecting one to go with. Then you need to install the thing. But first you’ll need to talk with he networking and storage admins. The compliance and security people are going to want to see things. Also, you’ll need to update some training in the cloud center of excellence. And before you know it, a quarter has passed. You’ll have to spend a week or so preparing your quarterly review - more arts and crafts - to report on the status of it.

And so forth. (Also, I forget dealing with procurement. It’s hard enough to get an enterprise to pay for a $100/year expense, let alone $1.4 million.)

Then October rolls around again. Us vendors are like, “hey, how’s your consumption of this stuff: I gotta maintain the ARR, do some LTV farming…could you introduce me to that other group? I they’d like some steak dinners….”

Then, all of the sudden, those goofballs in the bond department screwed up their inflation estimates, and next thing you know another bank is buying you. “We’ve got some other things we need to handle now,” you tell your steak dinner friend.

You’ll get the stuff going eventually. You’ll get benefits from the new technology for sure - just ask us vendors to carpet bomb you with case studies! This shit is for real. It’s just that it’s for real once you get it all setup and learn how to do it.

It’ll take a lot longer than you think.

The revelation of reality

The Gartner hype cycle describes another phenomena here: inflated expectations. You’ve heard that AI (or public cloud, or cloud native, or CRM systems) is stupendous, revolutionary. There’s case studies from early adopters. But you haven’t actually used it yet. The hundreds (thousands, even) of people in your organization haven’t used it yet. You customers have not experienced its effects yet, and so forth.

Until you actually get your hands on it, at scale (not just some early PoC’s) you won’t know how stupendous it is in your organization working within your constraints and taking advantage of your capabilities. Getting to that point takes at least a year, often more to get more organization wide usage.

You can certainly get a better and better sense as you go along. You have to build in bureaucratic humbleness that is willing to learn and observe itself in action to get that sense. You have to be careful with your first impressions. What the hype cycle is telling you is that they’ll be inflated.

ChatGPT is a good example here. Once you use it day in and day out for months, you adjust your astonishment at it. It is amazing! But it’s now where near the level of earth shattering that the anti-AI people make it out to be.

Listen, it sounds like I’m being a wet-sandwich here. But it’s the opposite. The hype cycle has another mind-trick in it. After the peak of inflated expectations, everyone gets disappointed and you go into the trough of disillusionment. You get upset! You get letdown! (And when it comes to public cloud, all the on-premses vendors smell the delicious disappointment at migrating to the new and swarm - steak dinners galore!)

If you know that expectations are false, that it will take a long time to get the stupendous returns, you won’t get disillusioned. You’ll be smarter, reality will be revealed.

The rotting core

The other thing you have to keep on eye on is spending too much attention on the stupendous new thing. Meanwhile, you have the existing business to run, the existing systems to operate and optimize. I suspect that most of the benefits you can achieve from IT come just from doing what you’re currently doing better. For example, if you look at how you do software development, you probably call it “agile,” but most people are probably not following the actual practices.

A cool trick is to ask these agile teams how frequently they ship software. If it’s not at least monthly, you can probably do some improvements. And the improvement is probably just putting in some automation, talking with auditors to show them that that automation means they can trust you systems more and, thus, have less meetings about each release. Are you actually doing pair programming? What are your test coverage numbers? Are you actually standing up in your stand-up meetings?

I’ve studied the problem of rotting, neglected systems in large enterprises for the past two years and it is a big, big problem. One of my co-workers said at his previous job, at a big bank, they were spending near 50% of their time just on fire-fighting, upkeep, and dealing with compliance. As he said, time spent on that is time stolen from making the business better. And, also as he said, there’s well known, proven practices and technologies that could improve that 50%…you’d just have to actually decide to do it.

The issue with this rotting core is that (a) it’s boring compared to, like, AI, and, (b) it’s really hard to make a business case for addressing rot in your IT systems and software. It’s not going generate direct revenue, so unless your organization thinks in terms of running more efficiently (speeding the workflows your software does - for example, speeding up approving insurance applications or doing case management) and values agility, the business case is going to be difficult. Corporate strategy is a zero-sum game: those who win take from those who lost. There’s only so much budget and time that a company has. So if you’re pitching “just do what we do now, but better” versus “implement AI to revolutionize our business!”…it’s going to be tough.

The software factory

Most corporate strategy think doesn’t value well maintained software. The people making strategy decisions in enterprises seem to of software as one-off, install it and forget it projects. You have to think about your overall IT estate as a factory. Just as a you would spend a lot of time maintaining and optimizing your factory, you have to do the same with your IT “factory.”

I suspect that many organizations could get huge improvements just by getting better at what they’re currently doing.

That’s seemed to be the case business wise in the past decade. For example, banking startups were supposed to destroy traditional banking. Instead, existing banks just got better…without really changing how their business functions and what they do. And, as the public cloud charts show above. Well. That hasn’t rocked the world (but it will over the next three years!)

Two stupendous beguilement traps you should navigate right now

There’s two things going on right now that you can immediately apply this to.

Kubernetes

First, make sure you get realistic expectations about Kubernetes. The overall ecosystem has hyped the shit out of it, myself included many times. But if you look at actual adoption, it’s incredibly small. There’s probably about 10% of enterprise applications running in containers now, less in Kubernetes. There simply has not been enough use of kubernetes in enterprises to know if it’s a good or bad idea, let alone how much of a good or bad idea it is.

Don’t let Kubernetes migrations become a distraction from just improving how you currently work.

Instead, you need to setup a system - a culture, if you’re a DevOps fan - of learning and experimenting to figure out if Kubernetes will work for you. There’s a huge knowledge and experience vacuum when it comes to Kubernetes, and the strategic engineering move now to is fill that vacuum and then start making big decisions.

Platform engineering

Second, make sure you understand what platform engineering is before you launch big plans to transform how you do everything. Platform engineering is just DevOps under a new name. (At least that’s what I think this week.) At most, platform engineering just adds in internal developer collaboration tools (in the form of IDPs). Platform engineering might include building and running your platform-as-a-service…eventually.

But if you think through all the things in the umbrella of platform engineering, it’s too much. In a large enterprise (or even a small one), one group doesn’t have enough time, enough cognitive load to manage the tools developers use, the runtime environment they use, the middleware they use, and also do all that magic DevSecOps (pardon me, I mean PlatformEngineeringSecOps), and…all the other stuff. If you have a mature, proven platform like the Cloud Foundry ones, sure. There’s all sorts of people building platforms like that on-top of Kubernetes right now - so you can start with one of those instead of building your own. (You could also just short-circuit all of that and hand over the platform building and running to the public cloud - the dream!)

But people in enterprise IT are obsessed with building custom, bespoke platforms. I mean, builders like to build.

Most every enterprise I’ve ever talked with has numerous reasons why they’re different, why they can’t just use an off-the-shelf platform, and, thus, why they need to customize it. For the most part, their reasons are false. And, in most cases, they’re very common reasons that all of their peers and other enterprises have. And, as such, those reasons have been taken care of in the off-the-shelf platforms. Rather than change the unique constraints that drive the need to build their own platforms, these organizations work keep those constraints and are forced to build around it. It’d be like if you had to build a custom bed around an old radiator instead of just removing the radiator.

With the DIY platform mentality, you’re building a complex system, and you’re going to need a complex meatware system to manage it. “Complex systems build complex systems.” You’re probably already in a flywheel of doom made up of two complex systems - your software and your meatware - that’s making things more and more complex as the quarters tick by.

In that kind of system, you’re always going to need separate developer tools groups and separate platform operations groups. You can only break down silos if you put, as we used to say, an opinionated platform in place that standardized and centralizes what you do.

Have you tried actually standing?

So if you’re launching a Kubernetes and/or platform engineering, uh, “strategy” or “program,” figure all that out. Don’t have inflated expectations. It’s probably better to just, like, call in the DevOps Engineering team and the application development team, let’s see, the infrastructure management team, the security team…hell, get all the silos in one room, and ask them “so, tell me some daily tasks that we could be doing better. Are y’all actually standing up in your stand-up meetings?”

IncrementalOps

You’ve got to keep an eye on the new stupendous stuff. You should always be doing several projects to try it out. Not just “pilot” it or do a “PoC,” but to actually do real work and make sure you’re following a process to learn from it. If you think AI is going to be a big deal, spin up three projects that are directly connected to how the business runs and check in every month to learn what works and doesn’t work. You can’t do a business case for that. You just have to do it.

But, at the same time, spend a lot of your time just improving how you’re currently working. Remember, five years ago you did all of that transformation work, right? Maybe it’s time to go back and make sure you’re still following the practices and doing the things. That you haven’t just reverted to the old habits.

You know, instead of sitting, try actually standing up in your next stand-up meeting.

If you’re into the above kind of stuff, you should subscribe to my newsletter. It’s full of topics like these a few times a week, plus links I’ve found and other fun oddities to look at.

Subscribe!

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 19th Improving FinTech with cloud native think, speaking. July 19th Stop Tech Debt and Start Using Faster, More Secure Paths to Production. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking.

I’ve got what I hope will be a podcast-y type version of a webinar series I just wrapped up. I don’t know: something like a after show special where we talk about the series?

It’ll be live next week, on July 19th at 3pm Amsterdam time (check you local listings).

We did a good job in the series talking about how cloud native apps and thinking gives banks and other financial organizations new capabilities, how it changes, for the better, how you do security and compliance, and how to start thinking about modernizing all those legacy applications.

Get a reminder to watch it

You can watch it in LinkedIn, or YouTube if you prefer that. Come with some questions! We didn’t get any during the webinar series.

Logoff

I think I accidentally worked out the outline for my keynote at DevOpsDays Des Moines!

Finding an estimate of how many developers there are in the world is difficult. Oh, there’s plenty of people making estimates, but those estimates vary so much that the estimates are suspicious.

For example:

1. Microsoft/GitHub recently said they now have 100 million developers using GitHub.

2. “We estimate that, as of Q1 2023, there are 35.6 million active software developers in the world,” says Slashdata (who the CNCF uses for surveys).

3. Evans Data (by way of Statista) estimated that 25.6 million in 2021 and forecast 27.7 million in 2023.

4. In 2022, IDC said: “worldwide professional developer census, which IDC places at just under 16 million in 2022.” This is up from 11 million in their estimate for 2014.

Those spreads are pretty bonkers, huh!

Out of those, I’d trust IDC the most. This isn’t exactly apple-to-apples: IDC’s numbers are for paid developers, not just “hobbyists.” That’s fine, though, because when I’m interested in this number, I’m usually wearing my “pay the bills” hat and am only interested in professional developers.

If I could find the breakout between pro and hobbyists in the Evans data, I’d probably go with the Evans data. I usually go with IDC on any IT estimates, but Evans specialize in developers and have for years.

If you look back at IDC’s 2014 estimate, as summarized in The Register then you can get a sense for the hobbyiests: “11 million working as software developers and a further 7.5 million ‘hobbyist’ [as] developers.” So if we take those percentages, it’s 40%/60% between hobbyists and pros. Applied to the 2022 estimate, that’d get you, like, 26.6 million developers total. And, then, that lines up well enough with Evans' too.

(You could make an argument that since 2014 interest in programming has risen, access to computers and education has gone up, etc., etc., and say that the hobbyist share has grown, but, whatever: I’m a round numbers, “smells about right” kind of person once things get into the tens of millions.)

So, if I was going to use something, I’d say “around 16 million professional developers, probably something like 26 million total developers if you include people doing unpaid farting around.”

I’ve got what I hope will be a podcast-y type version of a webinar series I just wrapped up. I don’t know: something like a after show special where we talk about the series?

It’ll be live next week, on July 19th at 3pm Amsterdam time (check you local listings).

We did a good job in the series talking about how cloud native apps and thinking gives banks and other financial organizations new capabilities, how it changes, for the better, how you do security and compliance, and how to start thinking about modernizing all those legacy applications.

Get a reminder to watch it

You can watch it in LinkedIn, or YouTube if you prefer that. Come with some questions! We didn’t get any during the webinar series.

Wastebook

Relative to your interests

• Security Team Culture Matters - Being in security should be a happy job. // “Security and risk teams are more motivated and purpose-driven than others. As a 25-year cybersecurity veteran, this totally checks out for me. Almost everyone I know in [IT security] is mission- and purpose-driven. They took on this job to protect others!”

• Deploying the Swift Method to Modernize a Singapore Government Legacy System - Good description of what it feels like to be stuck in the legacy trap: “The [Singapore] government agency in this case study faced a similar issue with a legacy system that supported critical business processes, integrated with other business-critical applications, and was developed and maintained by third-party vendors. Over time, the codebase had become highly coupled within different business domains and contexts, making it difficult for developers to work on. This situation led to product development squads being slowed down by dependencies on the support team for this legacy system. The development squads also lacked confidence to make changes to this system themselves—given the low automated test coverage—and faced uncertainty about what they would be able to deliver for their own work streams independently.” You can see the original talk this is based on here.

More: The importance of on-premises applications and infrastructure; Managing negative emotions and cultivating happiness; VMware Tanzu and VMware Aria adapting to multi-cloud industry trends; Potential discussion on DevOps trends; WE CAN VIRAL IT FOR YOU WHOLESALE.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 19th Improving FinTech with cloud native think, speaking. July 19th Stop Tech Debt and Start Using Faster, More Secure Paths to Production. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Logoff

Now that summarizing is working again in ChatGPT, I thought I’d try putting in a list of things I asked it to summerize, but did not bookmark to list an official link. That’s what the “More” paragraph is in the links section above. It’s like that Matt Levine/Harper’s style of mashing it all together. An “official link” means I’ve extracted some quote and/or added a comment of my own, bookmarked it, posted it to my blog and Mastodon, and probably promoted it on some other social holes. These ones are from the cutting room floor.

Only 22% of software developers say they have a clear understanding of what they need to do to comply with security policy, to make sure the applications they're writing for their organization, are good in a security sense.

Now, it'd be easy to say the developers are just dopes and they don't know what they're up to. But I think what this is indicating is that figuring out how to practically do security policy at the software layer is difficult.

And that's where this concept of “shift left” comes in.

The idea of shift left comes the Extreme Programming and agile world where you are bringing unit testing closer to developers, and then from DevOps where you’re doing the same with automation and configuration, and even releasing and managing software.

You're bringing it all of that “left” into the application lifecycle, close to when the app code is being written.

That kind of literally makes sense. But nowadays, when you start hearing about shift left for security, that shouldn’t mean having the developers take on even more responsibilities.

If only 22% of them even know what they should be doing, you should probably not ask them to do security things. My colleague Darran recently called this “shift left and leave.” Instead, I think you need to “shift left and stay.”

What shift left means in a security and compliance context nowadays is moving your security and compliance activities closer to that part of the application lifecycle, where the coding is actually done.

What this often means is automating a lot of the checks, and also enforcing a lot of the compliance you have. You do this by using things like default templates and setting up for your developers to take full advantage of how cloud native architectures let you split up and divide things. Darran and I discussed what that means in our talk today.

There's another thing that Richard Seroter, mentioned recently, which is the idea of “shifting down,” which is to say, if you have the opportunity to just build something like security and compliance into the platform, to just remove it from anyone's concern, you should definitely focus on that. As analogies, you can think about at a very basic layer like file services, networking, even the way that UIs are rendered on screens. All of these have been “shifted down” into the stacks that app developers use. This was not always the case!

So if you're thinking about shifting security left - which people sometimes talk about is “DevSecOps” or even “secure software supply chains” - don't assume that means having your developers do a lot of work. Remember: only about 22% of them really know what that means!

Instead think about how you can go back into the application lifecycle and add security earlier in the application lifecycle. There’s a lot of new capabilities you’ll have if you’re using cloud native architectures, platforms, and thinking.

https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F85f30641-3576-4bfa-a461-f342f20b2f7c_970x702.png 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F85f30641-3576-4bfa-a461-f342f20b2f7c_970x702.png 848w, https://substackcdn.com/image/fetch/w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F85f30641-3576-4bfa-a461-f342f20b2f7c_970x702.png 1272w, https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F85f30641-3576-4bfa-a461-f342f20b2f7c_970x702.png 1456w” sizes=“100vw” loading=“lazy”>

Relative to your interests

• In the face of volatility, CFOs—and their organizations—adapt- Belt-tightening watch. Lots of micromanagement and management by finance metrics ahead: “In the year ahead, CFOs plan to increase their focus on operational value drivers, management of KPIs, cash management, and capital structure. Other priorities have decreased in importance since Q3 2022.”

• IBM takes on AWS, Google, and Microsoft with Watsonx - If it works, and also, it lets enterprises build up huge, custom trained models, and it has enough governance controls, it’d be a big deal for IBM. They key things learned from ChatGPT is that it has to be super easy, frictionless to get started with. That’s difficult for enterprises software makers, and it’s also hindered by governance, access control, and pricing per seat and data access. To be valuable to individuals, a company will need to put as much of their data into their models as possible. If you’re just querying your own email and files, it won’t be impressive enough to show long-term value to individuals. And if you restrict the model to just a handful of people (as is done with most corporate data), then it also will be hard to show long-term value. This will freak out security people and lawyers. Back in the 2000’s when file sharing in enterprises (like SharePoint and intranet search) became popular, there was a wave of people freaking out that previously hidden in plain sight documents were now findable.

• Beware the Digital Whiteboard - The assertion: writing with whiteboarding/Sticky notes is not good, and can lead to leaky abstractions. Seem more like a “right tool for the job” thing, plus the usual garbage in, garbage out, regardless of the tool used to process the garbage.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 19th Improving FinTech with cloud native think, speaking. July 19th Stop Tech Debt and Start Using Faster, More Secure Paths to Production. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Logoff

I’m writing the MC script for our upcoming SpringOne conference keynote session, it’s part of VMware Explore this year. And I’ll be co-MC’ing it as well. Writing a script like this is fun, and unique, sort of. You have tiny slices of time between talks where you follow a pretty basic format: (1) wow, how about that!, and, (2) here’s what’s coming next! There’s the opportunity to throw in a couple of fun easter eggs (I snuck two into last year’s SpringOne MC script). And then at the end, of course, you tell people when and where the free drinks and snacks party is.

I don’t write scripts much, at all, so doing that in the past few years has been something new to learn. Also, for the last SpringOne I worked on our CEO’s talk, which was especially educational. It’s interesting to put yourself in the head of someone else by learning their presentation style, mixing it in with what you know they like talking about and that they can talk about well, putting in the company strategy and then adding your own perspective and, like, “spin” on it. Then you see (as with the CEO and the two MCs) them present it, and you close out a very educational feedback loop.

Anyhow! You should come to SpringOne this year to see it all gel together :)

Our final talk in our software stuff for financial organizations is coming up tomorrow. Above is a little anecdote that Darran made to me as we were working on it. If you’re into security, compliance, that kind of thing, check out the third part of our series: “How Cloud Native Improves & Ensures Security, Governance, and Trust in Finance.”

Summarizing Articles with ChatGPT Works Again

Recently, I’ve been complain that I can't use ChatGPT to summarize things anymore because it won't pull from URLs. This was what I ChatGPT for the most when it first came out. It was amazing! It’d good for more than just summarizing. I’d also use it to see if I wanted to spend the time to actually read the article in more detail; the ChatGPT summaries are a little shallow, of course, but they’d be good at telling me if it’d be worth reading more. Second, if you use the same chat session for multiple summarization requisitions, you can keep a log of things you’ve looked at and ask things like “make a list of things I summarized today” or “what are some common themes, etc.”

Anyhow, this stopped working several months ago.

But, now you can do dit again! If you have plugins, enable Link Reader, and then it'll work again.

Instead of creating a new chat window for each article, I create one chat window every day or so where I just keep getting summarys. I'll rename the chat something like "20230710 tl;dr" with the theory that I'll go back and look at these some days.

Here's the prompt I've been starting the chats with: "When I paste a link here, retrieve the text of the article and summarize the article in detail using bullet points. Simplify and clarify the writing. Output in rendered markdown. Start by listing the title of the article and make the title of the article a link to the URL. Then write a paragraph summarizing the most interesting/novel points, and then make a bullet point summary of the article."

With that, I can just copy-paste a URL in there and get summaries.

Garbage Chairs of Amsterdam

Wastebook

• Headstone: “Ran out of Takes.”

• We think of the hype cycle more in terms of time and maturity of new tech. A neglected point of it is that most new technology has unrealistic hopes and dreams, like 20x reality. That is: most new tech will be a lot less group breaking than you think. Thus, when the new tech fails to deliver on its promises, the new tech isn’t so much a “failure” as your early calibration on its outcomes.

Relative to your interests

• Pulling On Threads - I forgot about the “bring your whole self” thing.

• Unleash developer productivity with generative AI, McKinsey survey - Their survey says it’s good in four areas: Expediting manual and repetitive work, Jump-starting the first draft of new code, Accelerating updates to existing code, Increasing developers' ability to tackle new challenges.

• Adopt Platform Engineering to Scale Application Security Practices - “Gartner Survey Data Reveals a Missed Opportunity - Platform teams focus on improving developer experience, developer productivity, software quality and delivery speed. According to Gartner’s 2022 Software Engineering Leaders Role Survey, only 25% of respondents cited “reduced security risks’’ as one of the top three goals for platform engineering and only 6% ranked it as the topmost goal.” // Here we are, about to finally have a moment that’s just focused on making appdev better, and of course security has to come in and try to grab all the attention. This already happened with Kubernetes in the past few years. And: maybe it was a good idea to keep all this stuff separated in its own team so that each team can focus.

• Steve McQueen by, John Dominis - That guy made being cool look easy.

• Island Series: 6 Pack - These look like more amazing notebooks from a boutique shop.

• Threads, The Fastest Growing Product Since ChatGPT - ’Threads, it hit 30 million sign-ups in less than 24 hours, which would be 60x faster than the 60 days it took ChatGPT to hit 30 million (as I hit send, I’m seeing rumors its passed 50 million, but nothing’s been confirmed yet)’ // This characterization is a little unfair. If Threads had just been a feature added to the Instagram app, no one would be calling those sign-ups. A sign-up should imply that people wanted something so bad that they put up with the friction of creating a new account. But, whatever: the point is still valid. // Also, this is a take if Threads with a positive tone instead of the usual shit-all-over-it mission.

• ChatGPT web traffic falls 10%, analytics show - Indeed. I think I’ve found the limitations. The main one is the limit in the text you can feed it. If I could build up my own training data, that’d be something! The Link Reader plugin solves the summarizing web pages problem that I was having. What needs to happen now is just to get it integrated into enterprise software, and all the data ownership privacy stuff that goes with that. That’ll take at least six month, if not a year, to get through the security, legal, etc. people. So, check back in in 2025?

• Scratch Pad: Fireworks, Bootlegs, Spock - “I remain convinced that most categories of online services are akin either to hair salons, to grocery stores, or to movie theaters.”

• Porter’s Five Forces and the social web - There’s something interesting to do here in applying Porter to contemporary tech.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 11th How Cloud Native Improves & Ensures Security, Governance, and Trust in Finance, online talk. July 19th Stop Tech Debt and Start Using Faster, More Secure Paths to Production. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Logoff

See y’all next time!

A bonus Sunday episode!

Waking up this morning, my first thought was how different my job is now with less travel. Like many tech companies, we have smaller budgets for travel. The means I can only take three or so trips a quarter unless I get someone else to pay for it, or for customer/sales visits.

I dropped down a level in airline status due to decreased travel over the past year (and the lack of KLM maintaining your status to make up for COVID-times for several years). Yes, yes, “must be nice” and all that. I do a lot more at the desk work: writing, webinars and online talks, plus just general meetings/consulting about stuff.

That mix should have more videos, but as I mentioned awhile ago, after three years I don’t think my topic area works for videos. What do “executives” actually read and act on?

The explosion of social media is a huge blow to the developer advocate and tech marketing world. Surveys asking where developers got their info used to show that Twitter was up there.

Maybe I’m supposed to write more books? Arrange more online chats and panels in, like, LinkedIn? I was invited to an online CTO, like, salon last week. It was late on Friday night for me (living in Amsterdam), so I didn’t attend. That format is interesting…?

Is less travel better for my work, for my career, for my well-being? It must be better for, like, the environment.

Over the years, I’ve seen thought leader types…not so much burn out, as reach an end of their willingness to travel for work, or, maybe at the effectiveness of travel. You sort of run out of things to say at some point; you fill your audience’s idea-bucket. And once you start feeling like you’re repeating yourself, it’s hard to think all the effort you put in it worth it.

I’m not really sure what these grounded thought-leaders shift to doing instead. It used to be that you could just shoot out some clever tweets weekly to keep your thought leadering up, but that’s all dead now.

When I try to work on more content, there’s two problems I encounter.

As mentioned above, I can’t get the kind of eyeballs I would at a conference, just presenting to a room full of people. I spoke at a conference in Utrecht awhile back, and the number of people who followed my CTA and downloaded my book was huge compared to, like, the Internet as an audience on any given day. What do people in my field even read? I have no idea. Talking to people face-to-face is still incredibly effective.

Two, if I work on more official, marketing department run content or pop in other flows, it takes so long to get anything out the door…and then it just encounters the lack of eyeballs problem.

Despite all of that, people seem to think my content flows are fine. One of the more interesting analogies people make is that I’m like my own little company, managing all aspects of content flow and my work. They say this about my co-worker Josh, who is even more so. Another co-worker of mine, Dan, has done an amazing job at this over the past year as well. And Whitney has built one of the most unique concepts I’ve seen in the years.

That analogy is good, and it means I need to build up more “flows” that I “own” rather than having them done by others.

For example, one of the reasons I moved to Europe in 2018 was to do more executive engagement. “Executive engagement” means doing thought leadership with, let’s say, enterprise architects, to VP of operations or applications, to “C-level.” It’s a lot of talking about culture, swapping stories about how larger organizations change how they manage software. And so forth.

I was incredibly lucky that Hinada was running that in marketing when I got here. Even before I moved here, she’d had me do several. Over about four years, including during the pandemic, we did something like 40 of these events. Maybe more. They were great: small rooms of people where one or two resulted in actual business. By the metrics, they worked. Plus, I mean, it was just fun to meet and talk with people. But, as organization and budget shifts happened, as they do in large organizations, and especially when she left, that dried up. What happened is that I did own that flow. I didn’t establish my own ongoing contact with that group of people, a “club.”

That’s what you have to build up as a thought leader: your own “following.” For over a decade, you could more or less rely on Twitter for that. During the pandemic, and maybe a little before, it switched over the YouTube. There’s newsletters now, and all the various post-Twitter things. Those post-Twitter things are way too new, though. We’ll have to wait several years to see which ones work. For me, LinkedIn is where I should be trying to build a following more and more…but even that is…weird. I don’t have enough analytics to know if the following I have is all vendors, or includes enough “customers” to care. If I look at who likes and otherwise engages in my content on LinkedIn, it’s mostly co-workers. This is great, of course, I appreciate it very much. My point is not that that’s “bad,” it’s that I want to make sure I have “customers” in that following as well.

(This leads to an intriguing theory: if my large LinkedIn follower base - at least, the subsection that engages with my stuff there - is vendors, then perhaps I should start thought-leaders for vendors more.)

What I don’t have figured out yet is the medium and the content type that works for me and also for that “executive audience.” I’ve really enjoyed doing this series of financial industry talks with my co-worker Darran. It’s been very satisfying. Maybe I can give that kind of thing fine, and focus a lot of my “own little company” efforts on promoting them.

And, a little side-note on how mercantile my word choice is here: “customers,” “eye-balls,” “promotion.” I mean, yeah, sure - pure as the driven snow and stuff. If I were an independent book author (hopefully, not of the take-down-able airport book variety), perhaps I’d be saying “readers” and “consulting engagements.” A thought-leader mostly exists to drive business of some kind, whatever words or obsequious phrasing you’re using. I prefer to just be plain-spoken and open about it. I work at a company that sells stuff! I’m part of the funnel, and even lead-gen.)

Anyhow, so long as I can use the priority lines at Schiphol when I need to travel, I should be fine.

Speaking of! Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 11th How Cloud Native Improves & Ensures Security, Governance, and Trust in Finance, online talk. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Logoff

I was going to include this in the regular episode today, but the mix of reviewing a podcast and two cups of coffee into the morning thinking seemed discordant. I’ve been thinking about the above a lot recently: the changing nature of the work I do driven by the constraints I now have. So - there it is!

I listen to a lot of podcasts, and have for, I don’t know, over 20 years. I’ve made and make a lot of podcasts. You might call me both a podcast listening and podcast creating expert. In the classic sense: a critic. I should review podcasts more frequently!

If Books Could Kill - Worth the Resulting Shitting-On Vibes

A few times I year I try to eliminate all the bad vibes media from my life. You know what I’m talking about: there’s all sorts of things out there whose whole deal is to have a negative take. CringePub.

That’s what happened to If Books Could Kill after I listened to the initial episodes. The whole point of the podcast is to take down airport books. Their analysis of books like Freakonomics and Men Are From Mars, Women Are From Venus were pretty perfect. With a lot of these airport books (you know, super popular advice books and what can only be described as the “turn out,” Malcom Gladwell genre), you’re often left thinking two things (1) but now what I am I supposed to do differently, (2) I don't know, that all sounds a little too clever and kind of fishy?

Each episode delivers on that intuition perfectly. And the two hosts are meticulous in their research and structuring the take down. If you’re familiar Michael Hobbes’ years on You’re Wrong About, you’ll know exactly what to expect.

They actually read the book Well, often just one of them does. But this creates a good narrative tools:

1. The co-host who read the book has to give a good overview of it. The other one who didn’t read it acts as a sort of narrative straight man.

2. The co-host who did not read the book is a proxy for us, the audience who may not have read the book.

3. Hearing the real-time reaction and thinking that the co-host who did not read the book adds another dimension of analysis (and content).

Also, they do extra research to look up claims. For example, in the Atomic Habits one, they do a lot of double turns out’ing on the cutesy anecdotes and “studies” that are used to prove out the habits theories.

Finally, they’re good at spotting simple writing and structural nonsense. And, as they read more and more of these books, they’ve started to find the common tropes, structures, and, therefore, warning signs. In the Atomic Habits one, they come up with a grand theory of the structure for these turns out, airport books.

What makes them credible (in addition to reading the book and being able to summarize it, and the research) is that they point out the parts they agree with. And, in one of their first episodes, talking about Bobos in Paradise, they get really close to concluding something in the spirit of you’re not (completely) wrong, David Brooks, you’re just an asshole.

There’s also some great moments when they’re discussing the absurdly taken for granted things in some the premise of some books. For example, one one episode they shit-on The Game, a book about pick-up artist techniques. The whole premise of this book is that it’s hard for men to have casual sex with women. At one point in the discussion, Hobbes, who’s a gay man, says something like: wow, I never realized sex was such a fraught, stressful thing in the straight world. The implication being: this book only exists because those weird morals in the straight world.

But, like I said, it got to be too much negative vibes pouring into my overfilling, cracked bucket of a mind. At a certain point, especially when Hobbes is the straight-man (hah! pun!), they go overboard with just adding more and more shit-layering on the book. The shitting-on can make your brain-teeth start like too much frosting on a cake. And I was doing the spreading! So I stopped.

This week, Brandon reminded me of it, so I went back to it, listening to them do their shit-on show with Atomic Habits (hence all my references to it above). It suffered from the too much shit-frosting problem, but overall it was great.

If you read this newsletter, you’d probably like it!

(Sidenote: what is wrong with Wikipedia that the page for the podcast doesn’t seem to contain a link to the actual podcast? At least one that’s easy to find.)

Socialmedia, circa CY2023H2

My Content

Speaking of podcasts, this week Software Defined Talk is back to our usual format of the three of us going over tech stuff: This week we discuss RHEL licensing changes, check the vibe of DevOps and some thoughts on programing language. Plus, has ChatGPT already become boring? Listen in!

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 11th How Cloud Native Improves & Ensures Security, Governance, and Trust in Finance, online talk. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Logoff

It’s the weekend, so here is your suggested outro song to listen to as a cold beverage melts in your hand and you watch the golden hour horizon:

When a good teacher seems like cheating

All of the worrying about cheating with ChatGPT is hiding its biggest potential: being a teacher. As an “expert” (or, at least, well read) in digital transformation, DevOps, cloud native, blah blah, when I ask ChatGPT to do things for me, it’s mostly smell-free garbage, kindergarten stuff. But, when I ask it to tell me about something I don’t know about, it’s great.

For example, I’ve been reading Against Purity, which does the community thing of using a bunch of jargon without explaining it. One word was “syncretism,” which ChatCPT did a good job explaining it to me. What was especially magical about this little moment was that I used the text grabbing feature on my iPhone’s camera app to just copy and paste the text from an actual book into ChatGPT. Magic!

ChatGPT also great at simplifying dense text and ideas I don’t understand. It can be brutal in making a concept overly simplistic, removing all the artful phrasing that experts will use to describe something. Experts tend to either over explain an idea or over explain it.

When the CFO Says No

For example, I talk a lot about legacy software, and the need to modernize it. Here’s the slide I used to give a definition of it:

The longer definition is pretty good for people who are vaguely familiar with software. In focusing on the outcome (what it means), it doesn’t really tell you why legacy software causes these negative problems, nor wha to do about. But, someone knowledgable with software already knows why and what to do about it. Anne is just giving a good definition we can all agree on. Which is very important: just imagine if we all agreed on one defining characteristic/metric for “DevOps” or “platform engineering” (I’d suggest app deploy frequency) and we could move on with our lives.

The Michael Feathers one is an example of stripping away everything but the essence of a definition and make it into a tool. A developer who reads that will say “yes, I get it now. Legacy software is risky to change because you can’t verify that your changes don’t break things.” And then, those seven words also tell you what to do to escape the legacy trap: write tests.

And then my definition - the title of the slide - is just me being cute.

But to an outsider, I’d imagine these definitions aren’t very good. Here’s a definition from ChatGPT. I asked it to reduce a longer answer into a paragraph:

Legacy software refers to outdated or obsolete systems that are critical to an organization's operations but haven't been updated due to high costs or potential disruptions. Despite their antiquated nature, they are often maintained because they fulfill essential business functions. However, these systems pose increasing risks over time, such as system failure, security vulnerabilities, and integration issues, while their maintenance becomes more challenging due to the dwindling expertise in the old languages or hardware they use.

After a little bit of priming, I then asked ChatGPT to explain the Michael Feather’s definition to a CFO who is making decisions about budgets and doesn’t understand legacy software:

This definition highlights an important aspect of legacy software from a technical perspective. In modern software development, "unit tests" are like mini exams we give to bits of code to make sure they're doing their job correctly. If a piece of software doesn't have these tests, it means its functionality hasn't been assured in a systematic, automated way. This could be a risk as it makes the software more prone to undetected errors. So when we say "legacy code is code without unit tests," we're saying it's older software that hasn't been built with these modern safety nets, making it more challenging and risky to maintain or update. For a CFO, it means these systems could lead to unexpected costs and disruptions if they fail or need to be changed.

Coming at from another direction, you a developer could ask ChatGPT to explain things to CFO is an expert at! With a little bit of going back and forth, I had it come up with an explanation a CFO might give for putting off legacy modernization:

As the CFO, I see the value in upgrading our legacy software, but we must prioritize the most impactful investments to meet Wall Street's expectations this year.

Our existing vehicle fleet, which is progressively more expensive to maintain, is a point of concern for both us and financial analysts. Investing in an updated, efficient fleet reduces these costs, satisfies eco-conscious customers, and offers a more immediate return on investment.

Now, when I mention increased amortization, I'm referring to the process of spreading the cost of this fleet upgrade over the useful life of the vehicles. While this means we'll see an increase in our expenses in the short-term due to the costs associated with the new vehicles, this is far outweighed by the long-term benefits.

This immediate capital investment boosts our operational efficiency by reducing the ongoing expenditure related to fleet maintenance. Moreover, newer vehicles would lead to an uptick in customer satisfaction and usage, directly contributing to our net earnings.

These factors should collectively improve our stock value, addressing Wall Street's expectations for prudent management of our capital resources and strong earnings performance.

Regarding the software modernization, it remains an important long-term project. But given the higher and more immediate returns from updating our fleet, I recommend postponing major software upgrades to the next fiscal year. We'll continue necessary maintenance to keep our systems running smoothly and securely until we're ready to invest in a full upgrade. I hope this offers a clearer picture of our financial strategy for this year.

I bolded the most important thing that the developer might not be considering: yes, but my job is to increase the share price as a function of being a responsible steward of our investors money.

An expert in one field forgets they need to be taught in other fields

The CFO’s explanation is much longer than the corresponding legacy modernization pitch to the CFO. I tried shortening it (scroll down to the CFO part of the chat I’ve been doing here), but then I realized a fun point: my need to have it longer is because I’m not an expert on this stuff and I need that extra simplification and expanding it out. That’s the whole point I’m making here! If I tried to piece that together from wikipedia, Investopedia. reading some CFO Weekly trade publications, or even people commenting on a TwitterMastodonBlueskyThreads question…I don’t think I’d get as good an explanation.

(All y’all DevOps-heads out there can fancy this up by name checking the Dunning–Kruger effect. As a side note, if you look at the part of my chat session [towards the end] where I try to get ChatGPT to use all of this an example of Dunning-Kruger, you can see another fun teaching moment: an explanation that is totally unexpected [by me] due to different framing that I’ve been taught to have when it comes to Dunning-Kruger. That is, in the DevOps world, you often invoke behavioral economics and cool psychology tricks when you want to point out problems, be sarcastic, and otherwise be negative.)

Students are rarely good at being a student

Teachers are in short supply, and it’s impossible to search for answers like this, let alone ask for a new explanation, ask for clarification, etc. And yet, there’s so much worrying about ChatGPT ruining education. As with so many tools that can automate “the basics,” the initial freak-out reaction misses the benefits of doing away with bullshit work. When comes to education, there’s another benefit: scaling teaching, trying break the constraint of the supply of human teachers.

One of the most eye opening things I learned as a student was that to be a good student you have to learn how school works…how to do the actions of student-ing. There are deadlines for turning in work. You will be told what needs to be in your history paper (the KPIs/MBOs/OKRs!). You must write your citations in this one format. You need to show your work in math. You can read a 400 page novel easily if you just read a little bit of each day. You should be taking notes as you read that book, and in class…especially if the teacher has told you what needs to be in your essay at the end. When you take a test, go through any answer all the questions you know the answer to first and skip over the ones you don’t know; that is, don’t get blocked on question three out of ten, when you know the answers to questions 4 to ten.

I don’t think we exactly know how to integrate something like ChatGPT into that “student-ing.” I mean, it’s only been in the mainstream discussion for, let’s say, five months. There hasn’t been enough time to learn what works and doesn’t work.

Socrates famously thought writing was a terrible technology that was going to destroy society. Like so many things, he was being an arrogant dumb-ass. Never mind video games, I think calculators were going to destroy society, and people think that having a computer in your pocket and access to the Internet is going to destroy society. I’m pretty sure people thought type writers were going to destroy society, and for a couple centuries, printing a book always ran the risk of being burned at the stake.

Instead of worrying about students using ChatGPT to cheat, and, thus, destroy society, maybe we should all focus on how to use it as a new tool. That’s what the history of everyday technology would teach us.

You can now buy enterprise support for those millions of Spring apps that are running the world

We’ve soft launched a new business selling enterprise support for Spring. If you’re involved in software and IT in a large organization, I guarantee you you’ll be interested in this. If you know what Spring is, you know why: it probably runs huge chunks of your business.

If you work in IT, even if you have no idea what I’m talking about, you should be interested. Pretty much every large organization builds and runs Java app, as RedMonk shows every year. This means most of them use Spring. Spring is everywhere and runs a large portion of the world as we know it.

As with anything that helps run there world, as versions of Spring (and especially the wildly poplar Spring Boot) come and go, you’ll want to get bug and security patches, including for very old versions that aren’t exactly supported well for free by the open source community. Plus, you’d like someone to call when you have questions, and it’s always cool to have training and certifications.

Anyhow!

You can buy Spring support now, just on its own, very straight forward and easy. It also includes tcServer, Tomcat, OpenJDK support. Don’t hold me all of this: I haven’t, like, taken the training to know the official menu. I’m just going off the web page.

And, yeah, this is enterprise software so you can’t just put your credit card into gumroad or something: you have to contact us to talk with an enterprise sales rep. I mean, you’re probably going to need to deal with your EA compliance cabal, and, then, procurement department, so, like, we’re already in the enterprise sales game zone. Also, make sure to ask them for a fancy steak dinner (unless you work for the government, I guess). And don’t miss out: ask before and after you close the deal.

Check it out!

I’m writing about this at length because I’m excited about it, both on its own, but as a strategy experiment. Pivotal and, now, VMware1 haven’t really directly monetizing the Spring Framework as much as they (rather, “we,” since I work here) could - as much I thought they should.

This is largely on purpose: the Spring open source community there has done well to remain, like, “pure.” Things have been fin! I work there, so I’ve seen plenty of second-order monetization over the years, both by us and others. Spring runs fantastically in the Tanzu Application Service (previously called Pivotal Cloud Foundry) and is first in line for support in our Kubernetes platform toolkit, the Tanzu Application Platform. And, you pay for Spring directly when you use the Microsoft Azure Spring Apps service. (With all my “hold on, this Kubernetes thing might be going too far?” waffling, I’m starting to think that some of the people I talk with who want want to make Kubernetes easier to use for developers just use that and get on with their lives.)

However, all the time, every year, we encounter the basic question “can I pay for Spring support?” Strategically, it’s also a fun experiment: it’s selling directly to developer groups, a very simple value-proposition (versus the very valuable, but very big and complex platform products we have), and, you know, kind of obvious. It’ll be fun to see how to turns out.

I don’t really understand all of this, but there’s also a lot of stuff going on in the Java world in at the moment (and through the next year) that creates a market window. That’s the seller-side way of putting it. On the buy side: there are some decisions to be made about how you use and get support for enterprise Java applications coming. Some of these are pure business, and some of them are just standard upgrade cycle events.

You should check it out!

Making the “DevOps Engineer” title acceptable

DevOps Thought Leader: if you have a group called "DevOps Engineering," you have no idea what DevOps is. You should at least feel bad if it’s your title. [Crowd laughs.]

Platform Engineering Thought Leader: Got it. Here, hold my beer. [Squints and grins]What if we called the group "Platform Engineering."

DevOps: Wait, hold on, that's not what I meant...

Platform Engineering: Hey, sorry, I was busy. Just launched a Slack and conference. posted 20 sponsored articles on The New Stack, and my O'Reilly book is coming out next week. Gotta go finish that post on Backstage sprawl now.

DevOps: …

Platform Engineering: oh, also: could you retweet my thread on “ten things you’ll got wrong about platform engineering”?

Wastebook

• Has business travel decreased, or it just me (and the tech world)? Ask perplexity: “Overall, it seems that while corporate travel budgets are recovering to pre-COVID levels, the number of trips taken is still lagging behind. Spending on international business trips is expected to pick up in 2023, but the frequency of work trips is unlikely to fully recover.”

• Culture is impossible, tools are easy.

• Threads: finally, an app for centrists.

• “I would dearly love a world full of these things. It takes me back to the days of a more creative time on the early internet, and makes me wish for a future that has more of this in it.” Here.

• What’s the 2023 take on the ethics of being annoyed? Not like, offended and hurt, just, like, annoyed in the way a kid if upset when you serve the Brussels sprouts.

• “I need a respite for my mind.” Dear John Letters #23

• I’ve been using HEY! again for email. I almost am there in liking it. I can’t wrap my mind around the idea of no archiving, and I don’t really like the way it lists The Feed. I want my newsletter subscribers to show up as one line and hide the ones I’ve already read. But, as I said to Dave Briggs when he asked me about it: “I have this ongoing theory in my digital life, though, that I should stop using tools that are too perfect, and instead use tools that seem to embody (or limit you to) a certain world view or life-style that looks good. Hey certainly seems like that. It's a kind of attitude about email that's a little less perfectionist/completionist. It doesn't value email as much? I don't know.” This is a twist on the #DefaultsLifeStyle.

• Also, he started a newsletter. You should try it out!

Relative to your interests

• Amazon Prime Video’s Microservices Move Doesn’t Lead to a Monolith after All - The New Stack - At this point, who knows anymore? I think the secret to being a grey beard in tech is to never say “oh, that’s just like SOA!” but instead to just nod and say “wow, that’s a great idea!”

• Facebook’s Threads is so depressing - Fantastic writing!

• Five Nos - “‘yeses’ matter more than ‘nos,’ and taking more chances generates more of each. While there’s a near equal chance of getting told ‘no’ in our endeavors, in virtually all cases, there is no penalty for that rejection beyond some brief discomfort or embarrassment. On the other hand, when you get a ‘yes,’ there is likely a positive outcome on many fronts.”

• How legacy tech can kill recruiting efforts, increase attrition and ruin the employee experience, Conner Forrest - “451 Research’s Voice of the Enterprise: Workforce Productivity & Collaboration, Employee Lifecycle & HR 2023 survey listed ‘candidates expect software or tools we haven’t adopted’ as the top recruitment challenge (52%) they face. To put that into context, the next-highest response was expectation of flexible work (42%) and then compensation expectations being too high (40%).”

• Rocky Linux project details how it will live on - “Nobody chooses RHEL because it’s state of the art. It isn’t. In fact, it’s about as far away from state of the art as it’s possible to be, and in the rapidly changing world of open source, that’s a very desirable attribute for a certain type of purchaser. They choose it because one specific version will be supported for a decade plus, and that in turn is why vendors support RHEL, and often nothing but RHEL.” // Also, the tricky way one of the clones plans to get the RHEL source code to make their clone distro.

• Gartner Survey Finds 79% of Corporate Strategists See AI and Analytics as Critical to Their Success Over the Next Two Years - This seems very true: “Strategists said that, on average, 50% of strategic planning and execution activities could be partially or fully automated; currently only 15% are.” And if you established a stranded memo format, even more so. And you could have it generate presentations for you. Key will be, as always, getting access to the market and internal data needed.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 11th How Cloud Native Improves & Ensures Security, Governance, and Trust in Finance, online talk. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking

Logoff

Of course I have a Threads account now. Having seen the meager uptake of other social networks over the years, I’m overly pessimistic, but I give this one a 70% chance of being wildly successful. If they actually do good stuff with whatever open standard, it’ll be like a new type of RSS. If they let me merge my Mastodon account, that’d be amazing. (Is that a thing you do with Mastodon? I know you can move to a new account, but you can merge your old account into your existing new account?)

Tomorrow I have the first installment (hey, it could always be the last installment if I get bored with the idea or just forget I was going to do it) of The Podcast Review. Here is the premise I was talking about (also) with Brandon this week:

I listen to a lot of podcasts, and have for, I don’t know, over 20 years. I’ve made and make a lot of podcasts. You might call me both a podcast listening and podcast creating expert. In the classic sense: a critic. I should review podcasts more frequently!

Make sure you’re subscribed so that you’ll get it!

LEGACY SOFTWARE AT BANKS! That's the topic of the talk my colleague and I are giving tomorrow. You can watch it for free, check it out. In addition to the talk, you’ll get a free copy of my book on managing legacy software, Escaping the Legacy Trap Here’s the slides we have so far, a preview:

The eternal first inning of cloud

According to the chart below, the movement of apps to the public cloud has stalled out at about 25% since getting to around 20% in 2017. You can see that people have been planning to get around 40% of their apps into the public cloud in the short term for awhile as well.

This is from a recent Benedict Evans post on AI in the workplace.

Of course, things can change quickly, as Horace shows every few years when/if he updates this chart (which shows market share of various “PCs” over the years):

One of the most important take aways from this chart is to pay attention to when the definition of your market changes. Then, in addition to just old apples to old apples comparisons, you can do old apples to new apples comparisons.

More on the RHEL Drama

Last episode I tried to figure out what Red Hat moving all “upstream” development to CentOS meant. I understand the effects of it: you not need to be a customer or in Red Hat’s developer program to (easily?) get access to RHEL source code.

I still don’t have a strong handle on how the whole thing functions, the mechanics of how the source code is managed that makes those effects happen. All the details are the kinds of things that the people freaking out must think are just obvious, and no one needs to point them out. After talking with a lot people, and reading more, I think it’s something like this:

1. Previous to the drama, anyone could get RHEL source code. I’m not sure exactly how (as it in CentOS, but that was canceled, sort of - so, maybe there’s just a RHEL repository or big download).

2. Cloners could build their own RHEL. It was all compatible and enterprise reliable.

3. Now, you can’t do #1. You have to be a customer or in their developer program to get the source code. (“Anyone” can still get the source code, but presumably Red Hat could deny them either being customer or in the developer program. Thus, Red Hat can control who has access.)

4. But, CentOS Stream is now the “upstream” version of RHEL.

5. And, yet, even though CentOS Stream is the source code for the future version of RHEL…this somehow means that you can’t get the RHEL source code.

6. Here is what’s new in my mind: “upstream” does not mean what I think it means at all, despite the diagrams. To me “upstream” means that, for example: first, the current version of RHEL is n. Red Hat wants to release version n+1 (the next version). You grab all the code from the “upstream” and compile it. Now you have RHEL n+1 and can release the new version of RHEL. Cloners could do the same thing. End of story.

7. It turns out “upstream” is more, like, code you base RHEL n+1 on, plus some security patches, etc. It’s not an exact copy of the future version of RHEL. So…it is not actually the future version of RHEL, it’s some code that is used to make the future version of RHEL, plus some other code that is…kept where?

8. That’s not what “upstream” means to me, but whatever.

9. This is still very weird to me, and my head hurts thinking about, so I’m just going with the consequences that was clear from the beginning: if you want to clone RHEL for free, you can’t do that except through some artful work. It’s harder now. If you want the RHEL source code, the intention is that you should either get a developer license (and be limited to running 16 simultaneous RHEL servers) or become a paid customer for Red Hat. In both cases, you’re not supposed to take that source code and make your own clones of RHEL.

¯\_(ツ)_/¯

There’s also a pretty good page where Red Hat tells you why you wouldn’t want to use CentOS for, like, enterprise grade uses.

Relevant to your interests

• Food sellers fear extra costs & hygiene risks as plastic takeaway scheme starts today - (1) the point of the whole thing is great, and, (2) this is a great example of all the hidden complexities, scenarios, and thinking that has to go into what otherwise seems like a really simple change in an existing system.

• The Homework Apocalypse - How to incorporate ChatGPT (etc.) in school and lessons…in a good way.

• Patterns vs Platforms - It’s all hard stuff. Instead of centralized platforms, perhaps consider public cloud instead, mixed with conventions. Variation: don’t build your own platform, outsource it to a vendor/cloud.

• Tony Hsieh and the Emptiness of the Tech-Mogul Myth - ’Hsieh, in the end, was a rich guy who, early in his career, used his Harvard connections and some seed money to buy a series of lotto tickets in the tech boom, and then used his expanding wealth and influence to spread a bunch of marketing, in the form of pseudo-psychology, into the world. He slept with his employees and terrorized his closest friends. His descent into addiction and his untimely death were certainly tragic, but I couldn’t find much to admire about Hsieh in “Wonder Boy,” nor did I understand why I was reading dozens of meticulously reported, almost snuff-film-like pages about his journey into ketamine addiction and mania. None of this means that “Wonder Boy” is a bad or dull book—on the contrary, it should be mandatory reading for anyone who is interested in big tech. But it did not give much of an answer to the question of how and why so much of the press and the public got suckered in by Hsieh’s generation of tech evangelists.’

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

July 4th, July 11th Cloud Native for Financial Services talk series. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 18th to 19th SHIFT in Zadar. Oct 3rd Enterprise DevOps Techron, Utrecht.

Logoff

I saw the new Spiderman multiverse movie yesterday with my son. It was pretty good.

I don’t make the time to go do “normal” things like seeing a movie enough.

Source Code

I’ve almost figured out the drama around Red Hat redoing how they distribute the source code for RHEL.

Is this it?

Here is my understanding of it:

1. Before the changes, anyone could get the source code (and I assume configuration, build methods, etc.) so that they could create an exact copy of RHEL (“bug for bug,” as people like to say).

2. This means that “clones” of RHEL (or distros) could be relied on to act exactly like RHEL.

3. So, if you did not want to pay RHEL for access to RHEL and the support they’d give if things went wrong, you could get RHEL for free, or some discount from the clones (including Oracle).

4. The drama was: RHEL no longer provides that source code.

5. What this means, exactly, is incredibly confusing. Red Hat still develops future versions of RHEL all in the open in a project called CentOS.

6. HOWEVER - and this is key to everything, so if it’s not accurate, I am still super confused -, as Jonathan Bennett wrote here: “CentOS Stream just isn’t quite the same as RHEL, and there are bugfix patches that land in RHEL and not in CentOS Stream.”

7. That is, whatever is in CentOS is not exactly the same as what’s in RHEL.

8. Now, you can actually get access to the source code for RHEL, and thus the ability to build it on your own and get the exact copy as in #1 above.

9. BUT! There are new restrictions on that: you have to be a customer (I don’t think it matters if you pay or not) or be in their developer program (which is free).

10. There’s some open source licensing (GPL) “license interpretation innovation” going on here.

11. The thing about being a customer or in the developer program, is that Red Hat could decide to terminate you as a customer or your membership in the developer program at any point.

12. Thus, a cloner could sign up as either, get the current (and presumably past) RHEL source code. They could then build the exact copy in #1, and go about their business (literally and figuratively).

13. However, if Red Hat doesn’t like this, they could terminate that cloner, cutting off all future access to the source code.

Control

And that’s the drama: effectively, Red Hat now can control who gets ongoing access to RHEL source code.

It’s very hard for me to figure out if these details are correct. It all hinges on point #6 above. There’s another version of point #6 that is less “bad”:

It could be that CentOS is actually “bug for bug” compatible with RHEL. However, I think Red Hat said they will only sync up RHEL to CentOS for every major release of RHEL. That seems to happen every six months. This means that whatever happens in between every major release - in particular bug and security patches, the most important things you’d want! - is held back by Red Hat. So, if you went with a clone of RHEL, you’d have to wait that six months to get your bug and security patches. I don’t know though: that seems like some real tin-foil hat shit, and what does it even mean to “sync” code: is Red Hat maintain a private repo of all the patches and then they just do a pull request to the CentOS git repos every May and November. I mean…that’s not technically impossible.

To simplify it a lot, if I understand this correctly, first, even though RHEL development is done in the open, it’s only mostly done in the open. Some of the code is held back, particularly when it comes to bug fixes and security patches.

Second, Red Hat can control who gets access to the real RHEL source code.

This means that you can’t clone RHEL reliably, which means that if you’re running your organization on software that is only supported and verified to run on RHEL, you now have to run on RHEL and, thus, pay Red Hat.

I mean, that organization could run on not exactly RHEL clones and will probably be fine. The clones will have to figure out and distribute bug fixes and security patches, presumably. But no one wants say “yeah, the software that runs our factory, makes sure shipments get from Rotterdam to LA, makes sure the missiles don’t accidentally land in the suburbs will…probably work…there’s probably not a problem or incompatibility in the operating system.” Instead, those organizations will want the assurance (and, like, finger-pointing and support) that it’s all certified on RHEL and that they’re running actual RHEL.

Of course, you could come up with a scheme to get access to RHEL source code. The cloners could hire anyone off the street to sign up for an account and download the source code again and again, burning a developer account each time. Once that person had the source code, as I understand it due to the open source licensing, that person could give the code the cloners. Or just put in online for anyone to download it. Once you get a copy of the source code, you can then give it someone else if you don’t mind your developer account being canceled.

I assume you have to be 18 to get a legal developer account with Red Hat. There’s something like 2.6 billion people in the world over the age of 20. So, I don’t think the clones will run out of people to hire to fill out a form and click a button: the clones could automate the process as well.

You could even see people crowd funding this: you just pool together something like $5,000 a month to to hire someone for, like, $500 to fill out the developer program forum and then run a script to download the RHEL code. So whenever a patch comes out, you do that, and you can get an exact copy of RHEL, per #1 above. Someone like Oracle would probably be like, “here, how about $15 million?” Then you could even setup a foundation and get a fancy executive director!

This is a high degree of shenanigans, however. I can see the clone sales rep trying to explain it all to a CISO at, like, Citibank or the German Air Force and that CISO going like “hmmm…how about I just spend $20 million more every three years and totally eliminate a weird bucket of risks? I mean, I’m the CISO, all I have to do is sneak up behind the CEO and CFO and go ‘SECURITY! BOO!”, pick up the spare change that falls out of their pockets when they jump-scare, and then my budget is pretty much unlimited.

“I’ll get my Red Hat (or, even better, IBM!) rep to buy me some steak dinners a few times every year, fly me out to Vegas for the annual conference, be on a panel at RSA for them, and we’ll call it a day. (Also, we’re supposed to be running all our shit in THE CLOUD by 2028, where we won’t be using much, if any, RHEL, so…whatever?)”

So…?

Did I get that all correct?

Consequences

More than just control, all this means that more people would likely become paid RHEL customers. This is because the clones would no longer be reliable enough (see the “probably” scenarios above). There’s probably not too many enterprise customers that have reduced their bills by paying clones or just running without paid support. (I’ll let someone else look up the marketshare). I could see that a lot of telcos would be doing this, though. Some managed service providers, maybe even the big cloud providers. Still: how much extra revenue are we talking about: is it $15 million, or more like $2 billion?

The whole social contract, norms, feels and vibes thing is a completely “orthogonal” thing as the people involved might say. I just want to make sure I get the understand the new constraints in the system.

Developers

Also, in the developer program, you can only run 16 simultaneous instances of RHEL, which would put a damper on some companies, who, for example, would want to certify that storage arrays are compatible with RHEL. For example, if you’re a hardware manufacturer and you want to run 100 tests (I don’t know, for stats or some shit) for the new version of RHEL to make sure it works on your hard drives and computers, you’ll have to do that in chunks of 16.

Let’s assume that testing takes three hours. You need one hour of setup time, one hour to run the rest, and one hour to analyze the results. If you could run then all at once, then it’s just three or four hours to run those tests (plus the time to rig up the hardware and stuff, but let’s assume you’re really good at that by now, so it takes, like, two hours at most to do all of it).

If you have to do that in batches of 16 [is this the right math: ( (100 * 3)/16 ) * 3?] then it will take 56.25 hours instead. That’s 2.3 full days (24 hours), and seven working days (8 hour days).

So, you could say that your costs became 2x to 8x (mostly in labor), depending if you already were running on three shifts (day, evening, midnight) or just one (day). This would also mean that to fully certify a patch, you’d need seven days. This means that, if a security problem came out on any other day than a Monday, and in the morning, you’d need people to work on the weekends, or have them work overtime.

And then, if had to patch previous versions of RHEL, you need to multiple that by however many versions back you go that needs the patch. Obviously, all of these numbers are made up, but you can see where there’s a model here for figuring out how only being able to run 16 simultaneous RHEL instances (for free) would change things a lot.

Now, I would imagine that a lot of the people, rather, organizations that are doing this testing already have an extensive, long-term customer/partner relationship with Red Hat. These would be from the likes of Dell, EMC, Intel, AMD, SAP, Microsoft, likely the public cloud providers, etc., etc. So, they probably don’t care. It’d be the smaller, even down to just one individual who’d suffer from the above.

And, I guess, if you were working a system or software that was intended to run more than 16 instances of RHEL - like most parts of Kubernetes, OpenStack, scaled out databases, etc. - you’d be kind of screwed too if you wanted to do it all for free.

Wastebook

• Goofball training - leaving my wallet behind is good practice for relaxing more, moving to a carefree lifestyle where I don’t worry shout all that.

• “There is so much to worry about, that we forget to worry about ourselves and then it’s too late.” Here.

• I don’t know what to do with Bluesky. I’m not really into the nature of truly keeping up with what people are thinking and doing - that’s Facebook, right? And I’m not big fan of that activity in Facebook already. So, I’ve just been posting a pictures a day there. But, really, until I can just automate it, I don’t think I will anymore. Thus far, I haven’t really found a point in the post-Twitter Twitters. This is due to the huge follower-ship I’ve built up in Twitter since, whatever, 2006/7 - that’s a big asset of mine, professionally. In comparison, the use of Mastodon and Bluesky as a publishing channel is not good. Plus, I’m increasingly tired of, like, trying. After all, my bigger project of is commiting selective infosuicide.

Relevant to your interests

• A modern-era lift and shift: Danske Bank seeks massive cost-to-income ratio improvement with the help of Infosys - As ever with outsourcing: hire cheaper labor under less restrictive labor laws…?

• 28 Questions to Ask Your Boss in Your One-on-Ones - Good things to talk about in your meetings if you can’t think of anything else.

• ‘Zero trust’ was supposed to revolutionize cybersecurity. Here’s why that hasn’t happened yet. - ’John Watts, a Gartner analyst, wrote in the firm’s annual predictions memo from last December that “moving from theory to practice with zero trust is challenging,” and that fewer than 1% of large enterprises are actually using it today…. Moreover, Watts predicted that “over 60% of organizations will embrace zero trust as a starting place for security by 2025 but more than half will fail to realize the benefits.” A report from Nathan Parde of MIT’s Lincoln Lab last May, meantime, estimated the typical zero-trust deployment will take anywhere from three to five years. That is a depressing thought, to be sure.’

• Midjourney and Adobe Stock - Using AI to make stock photography, etc.

• Mobile Industry Eyes Five Billion ‘Dormant’ Phones Sitting In Desk Drawers For Reuse Or Recycling - 5 billion phones sitting in desk drawers.

• The real story of how Facebook almost acquired Waze, but we ended up with Google - “Acquisitions are the first moment when founders and investors have diverging interests. This is the one time when you should be wary of feedback from your investors. And, of course, like any negotiation, whoever is willing to walk away will get the better deal – always have a red line and hold firm to it.”

• Beyond belt-tightening: How marketing can drive resiliency during uncertain times - What’s a little crazy is: shouldn’t this all just be the way marketing always works?

• Red Hat ends the RHEL clones’ free lunch - I still don’t understand exactly what source code is unavailable and when. If CentOS is the “upstream” code…then getting an older version of the CentOS code will get you the current version of RHEL code, righ? Is it just annoying to do…or is it actually not at all possible to build a “bug for bug” copy of RHEL now without paying or having the dev license…because the actual RHEL code is actually not in CentOS? Or the magic is all in the extra stuff Red Hat adds to the RHEL build (like drivers, config, etc.), which used to be no strings attached available, but is now not?

• How Google Reader died — and why the web misses it more than ever - “At its peak, Reader had just north of 30 million users, many of them using it every day. That’s a big number — by almost any scale other than Google’s. Google scale projects are about hundreds of millions and billions of users, and executives always seemed to regard Reader as a rounding error.”

• Fuel for Thought: The Transformation of Auto Retail – Bricks, Clicks, and People

Upcoming

Talks I’ll be giving, things I’ll be doing, places I’ll be going.

July 4th, July 11th Cloud Native for Financial Services talk series. August 21st to 24th SpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 18th to 19th SHIFT in Zadar. Oct 3rd Enterprise DevOps Techron, Utrecht.

Logoff

Hey, I really just am curious to figure out the stuff above. I do not have schadenfreude tingle-dreams here, or whatever. I just like to pull apart and understand puzzles like this.

See y’all next time!

I really liked how this first talk in out three part series came out. I wanted to talk as much as possible about actually strategy, business-think, so to speak, when it comes to how financial enterprises do software. All of us cloud native people spend a lot of time talking about the general benefits of cloud native stuff: better developer productivity and getting closer to the agile, deliver once a week (or daily!) dream; resilience/uptime; security blah blah; and etc.

These are good business outcomes/value, but I like getting deeper into what the actual apps are doing and how they’re helping create new types of business, products, and so forth. So, here, it was fun working with Darran (who’s actually worked on all this stuff at banks, most recently UBS) to talk about all that. Plus, I got to learn a couple new case studies from out customer base.

Anyhow, you should check it out. Sure, it’s a webinar, so you have to sign up for it, but: come on, no problem, right? You’ll enjoy it. Tell me what you think.

Watch the Talk

There’s two more in the series as well, next Tuesday and then Tuesday the week after that.

Changes in the streams

This week’s Tanzu Talk podcast: Ben and Ed try to help Coté understand what the changes in RHEL open source development mean. We don't figure it out completely, but get close enough. Also, Ed tells us what Crossplane is. Finally, we briefly discuss two new reports from Gartner and Forrester that seek to define the cloud native application stack.

Listen to the episode

Lost Videos

I found two videos I made that I’d forgotten about:

1. Thinking about governance in enterprise software.

2. Making a stronger connection between making money and all that money you spend on IT.

Depending on how you count them (are live streams of podcast recordings included?) I’ve made around 200 videos for work in the past three years. I started with some little goofy ones I made during paternity leave, then a lot more during COVID, and now it’s just a normal thing.

It’s not easy to make videos all on your own - it’s a multi-tool skill. Plus, you have to act, figure out the content, and promote them. The secret is that I was thrown into video making back in 2007 when I was at RedMonk. Or maybe it was 2008. Who knows. CIRCA &co.

We had a totally ridiculous (in a good way) contract with some early internet video startup whose name I forget. I think most of those videos are lost. Our boss was Steve Gillmor! His early podcast, The Gillmor Gang, was a huge inspiration for my own podcasting, general tech world thought leadership craft, along with Jon Udell, both who had shows on IT Conversations.

That didn’t last long (it was, after all, ridiculous). But, it lead to RedMonk starting up a video business, which I ran soup to nuts (except for sales, that was shared among the three of us). You can see those videos still in YouTube. As you’d expect 12 years later, their videos are insanely better now-a-days, not just a dork with a tripod in an poorly Las Vegas conference room and hallways.

Anyhow. I like making videos.

I’ve more or less come to accept that I both can’t and don’t want to put in the effort to get “famous” in the video world, which has sort of lessened me making videos more frequently. When you see that you only get, like, 150 views with only about 5 people watching all of the video, you start to think: why am I doing this? That’s in YouTube: the numbers in LinkedIn and Twitter are higher…but the people who drop off early on seem the same. I envy people who code in their videos: they at least are doing something instructional and there seems to be no end of content for them. I have to just talk in mine, and I’ve kind of said all I know to say.

Of course, there’s all the non-tech videos I make too, which are definitely worth it just for the fun:

I was thinking of all of this when I noticed I almost have 200 subscribers on my YouTube channel. Things are gonna start changing once I get over that hump!!

Upcoming

Talks I’ll be giving, things I’ll be doing, places I’ll be going.

July 4th, July 11th Cloud Native for Financial Services talk series. August 21st to 24thSpringOne & VMware Explore US, in Las Vegas. Sep 6th to 7th  DevOpsDays Des Moines, speaking. Sep 13th, stackconf, Berlin. Sep 18th to 19th SHIFT in Zadar. Oct 3rdEnterprise DevOps Techron, Utrecht.

Logoff

It’s almost July! My mother is coming for the summer which is always great. The kids, of course, love seeing her; she loves seeing the kids; Kim and I like seeing here; and, I won’t be coy: we finally get some free time from the kids!

I’ll probably roll up the links next episode.