Window shopping in Vienna.
Window shopping in Vienna.
We’ve restarted the Tanzu Talk podcast. Check out this week’s episode:
Tanzu Talk is back! Your new hosts are Coté, Ed, and Ben. In this episode we cover recent news in the cloud native world, plus highlights from the recent Tanzu Application Release. Plus, light discussion of the political climate in Star Trek versus Star Wars as it represents programming philosophy.
So far, the format is to cover some cloud native news and then talk about a larger topic. We have some guests upcoming as well. It should be in your ears every week or so. Subscribe!
Platform Engineering, platform as a product, and so forth. If you’re standing up kubernetes or any cloud stuff for developers, you probably need to change how you think about operations in general. Shift from service delivery to product management.
14 reasons why your digital transformation initiatives to get better at software may be slowing down. Number four.
Often what you do when you’re fixing up how you do software in a large organization you’re putting a platform in place. Whatever your cloud infrastructure layer, along with whatever frameworks you use for developers and tools on top of it is to get them to be more productive.
Often time an infrastructure team is asked to build this and they build it without spending enough time with the actual customers of that platform, the developers. They’ll build this platform and then they show it to the developers, and developers are not interested in using it. Kind of little wonder because they weren’t consulted.
So there’s two things you can do to avoid that.
One is to involve developers very early on one or two teams to help decide what’s in the product and explore it, validate it, change it as you product manage what you’re building for them.
Two, you’re gonna need to do at least quarterly road shows internal conferences, where you can go visit teams of developers and have your platform advocates not only training them, but convincing them that it’s a good idea to use.
Figure out where to get started with a developer toil audit.
14 reasons why your digital transformation is stalling in a large organization: number three.
If you’re looking to improve the way that you do your custom software in a large organization, you likely have a huge amount of what people call tech debt or legacy software.
These are the systems you’re currently using that have brought you all the success and revenue that you have, and now they’re too old and they really can’t be changed. And if you actually try to go in and use them. There may not even be the skills of people who know what they’re doing. As you wanna start using those pieces of software, those services in different ways, it takes longer and longer to the point where people say it can’t be changed unless you’re willing to put up with six or 12 months.
Now there’s all sorts of reasons this happens, but mostly it has to do with neglect. Just letting things go too far and not maintaining them, not upgrading them and thinking about how you build long term architectural agility into them. So make sure when you’re looking to improve how you do software, you’re really paying attention to and planning for how you’re gonna modernize your software. Identify the legacy software that’s holding us back and modernize it as needed.
Read more in my free book.
02 – Security
14 reasons digital ,transformation fails in large organizations: number two security.
There’s many things your security staff is gonna wanna do when it comes to making sure the software you build and run is secure.
One, they’re gonna need to build up a risk profile to understand the new technology you’re using the deployment frequency, all the types of risks that can occur. These risk profiles give them way to model and think about the security risks they’re willing to take on, those they’re not willing to take on, remediations to do. It’s kind of the core model for how security thinks about things.
The next thing they’re gonna need similar to compliance is to make sure the software using follows the policies and the guidelines that you have. They’ll also use this to patch software as bugs come along the third party software that you use. In order to patch that software, they’re gonna need to know what you’re using and where it’s deployed, how it’s configured and so forth and so on.
So these are things that security groups are gonna need to know. And if you don’t anticipate and plan for that and talk with them about it, it’s gonna slow you down.
Read more in my free book.
14 reasons why it’s hard to change the way you do software in large organizations, number one.
Compliance basically means that you’re following legal and self-imposed policy and guidelines: the ways that you’re doing things and not doing things. Governance.
A compliance person can’t come in and check every single hour of something that’s happening. So your software developers and product managers and operations people have to document that they’ve followed the rules. And they need to also provide that documentation to the auditors who can then go in and audit it, look over it and make sure that it’s following the right way to do things.
The compliance people often work a lot slower than you want if you’re doing a weekly or even daily release with your software. That becomes a huge hurdle.
You need to spend a lot of time thinking about your build pipeline, the platform that you’re relying on, the process that you use to make your software, and even most importantly, going to your compliance people and spending a lot of time to show them the new ways that they can make compliance even better when you automate and change the way you do your software.
The charitable guidance on what “shift left” means is: operations and security people working closer with developers, being friendly with them, and vice-versa.
More or less it’s that lean idea of “move the decisions closer to where the work is actually done.” The phrase has gotten blown up to mean more than the original DevOps think (have developers put in work to make their apps run better in production, and have ops people work with developers to do so) to mean any activity that’s working closer with “developers” rather than in some waterfall-like, impersonal process before or after developers.
In response to a question in the Software Defined Talk Slack.
It’s easy to look at that “solution” tab and think “what is this madness?” But, “solution marketing” is actually useful, especially when it comes to “enterprise software.” Here, I discuss the differences, what each type of tech marketing is for, and an example.
I am in Vienna on a long weekend vacation with Kim. I picked this city to see the 12 Bruegels, so I thought I’d take a buffet-read at one of my favorite books, Short Life in a Strange World. Here, a passing montage of travel:
For the next four days, we will mostly move in international space: trains, stations, hotels, galleries and museums, escalators and lifts, restaurants, bars–places where everyone is welcome, or anyway invisible, if they have a little money. Like the child on the little sled, you glide along.
And, a reminder of what it’s like on the other side of the calendar:
Steve Barley and my brother and I take the train on to Würzburg, where my brother leaves us, heading back to Frankfurt and London. It is getting furiously cold now, across Europe. Barometric pressure is collapsing. Elements float free. The schedule loosens. Each train we catch is delayed, by a few minutes only, but delayed nonetheless, as though even Swiss–German railway efficiency were struggling to oil its points, to keep up steam in its boilers, to stay alive. Each stage of our journey is framed by a little fretfulness, a milling on cold platforms, a glancing at departure boards. But the trains come and we move on.
One of the things executives often forget when they’re transforming, how the organization does software is to transform how they do their job.
What I’ve found is they tend to sometimes have the same sort of meetings and they don’t really change the way that they think about how they’re empowering their staff to be more mindful of being involved and having responsibility with their products.
The other thing to pay attention to is making sure you’re actually transforming the way your organization is formed. Because, your organization structure was built around your previous way of working to optimize on costs and efficiencies, but also the productivity and the actual work people are doing.
When you’re transforming how you’re doing software, you’re changing how people work. And so you as an executive need to really put a lot of effort into changing the organization to match the new way that you’re working.
So don’t think that you can just transform the way that people do software or even project manage the software.
You’re gonna have to transform the whole factory of your organization. And indeed, that’s part of what you’re doing, is: transforming as well. Not just the staff who are making that lovely software that makes your organization so exciting, juicy, and successful.
Setting up your platform engineering team? Looking to support developers building and running apps that run kubernetes or whatever cloud-gunk you have? Check out my overview and advice for getting establishing a platform engineering team, backed up by real life stories. My daughter won’t be there to help, but it’ll be useful nonetheless.
It’s coming soon, August 4th. Register and watch for free!
Check out: VMware’s multi-cloud toolkit for Kubernetes.
And here’s my answer:
“Multi-cloud” mostly means, within one organization, using different types of infrastructure. Mostly simply, public and private cloud. You could say “traditional datacenter” (mainframes, AS/400s, virtualized x86…I guess?). And, you know “edge” (which is sort of an evolving concept, but real enough as a category).
If we narrow down to software, though, I think of “multi-cloud” a little different. Here, think about multi-cloud as meaning you can run your apps on whatever infrastructure you need to because you have a common runtime layer and, probably, management tools. This is sort of like Java’s “write once, run anywhere” vision. You can also throw in using services from different clouds and your own 0n-premises stuff.
I’ve been working on and waiting for this paper to get published. I co-authored it with some of my team mates in Pivotal/Tanzu Labs. It documents a practice that the Labs people have been doing, a developer toil survey.
First, we develop the concept of “developer toil” in the paper. I think it’s a type of tech debt that isn’t noticed and optimized enough: all the work and waiting developers need to go through to finally start coding and running their software.
Seconds, we go over a tool for finding developer toil and giving feedback on plans to fix it. A survey-driven “audit.”
What I liked about this process when I learned about it is that it has a mechanism for finding developer toil – it answers the “how” of the problem. The Labs people use a survey that you can send out to developers to find and rank common types of toil. Then, if your someone in charge of improving how your organization does software (“digital transformation”) you can go through that ranked list and start to fix problems.
It’s pragmatic, perhaps imperfect, but it’s better than nothing and should be enough to get your started on whatever you think perfect is.
Go download it for free, in return for your email address, of course.
Another public cloud move from a company that’s been holding onto private cloud for many years.
Original source: Delta Airlines takes flight with Amazon Web Services
O￼ne reason for this change in bargaining power at startups: Capital isn’t flowing as freely. As venture firms tighten up terms and investors offer survival advice to portfolio companies prepping for a downturn, startups are more focused on cutting costs than rapid growth. That means spending exorbitant amounts of money on salaries to attract new hires is coming to an end, say those who help recruit for the portfolio companies of venture capital firms.
Original source: Tech Workers Long Got What They Wanted. That’s Over.
If you ever feel lonely, remember that somewhere someone is making millions of dollars off of a self-help book entitled Deep Work. The author of this book believes that if you could just not look at your phone, you would not only be less of an idiot, but also a millionaire.
Original source: All it takes is putting your phone down