I had a great conversation with Boskey Savla (@boskey) goes over kubernetes for VI admins. We discuss what VI admins traditionally do, how that maps to kubernetes, and the new tasks and roles admins have when managing kubernetes. Also: what does “kubernetes in vSphere,” like, actually mean?
00:00 – Boskey Savla 01:06 – Her two courses at kube.academy. 01:56 – What is a “VI admin”? 05:57 – How kubernetes changes the role of VI admins. 10:00 – The “API”/interface differences between traditional VMs and kubernetes. 15:20 – Getting started with kubernetes: start with what you have. 19:54 – Putting together video training. 23:57 – kubernetes is in vSphere – wut? 30:46 – Bye, bye!
When you want to change, you need to find out what the new rules are, or start following the ones you’ve been neglecting. Also, stop trying to find who’s in charge: it’s probably you!
Topics
It’s not about breaking the rules, it’s about almost breaking them. Remember: you wanted to change, not stay the same.
0:00 – Agenda.
00:20 – Everyone is good at saying “no.”
01:58 – Don’t break the rules, almost break the rules.
07:20 – It’s you! There’s no one else to ask.
12:31 – Your CTA.
16:42 – Bye, bye!
Robbie Clutton joins me again to talk more agile-think. First, we discuss how you can nudge people to actually follow priorities. How do you get people to do what they’re supposed to? Then, we discuss how to think about and use cost of delay in business case thinking. Cost of delay is also a good tool for prioritizing work as well.
Getting good at leadership is always good, but make sure to mind the technocracy as well – someone’s actually gotta do the work! Also: plan for needing gadgets for your gadgets.
Topics
Less leadership, more technocracy.
Go beyond high-level “why,” seeking out the “why of how.”:
>“I think some of my best conversations came through finding ways to respectfully ask those whys and trying to learn more about the process and why we were doing certain things, and really just diving into some of those uncomfortable situations,” said Liberty Mutual’s LeBlanc about her Pivotal Labs engagement. “But respectfully pushing back and sharing my perspectives, as well, ended up helping us learn so much more because we weren’t just taking it all in. We were really trying to understand the whole process.”
00:00 – The agenda. 02:14 – Less leadership, more technocracy. 20:38 – kube.academy. 21:54 – tanzu.vmware.com/developer 23:01 – Pets for your pets. 28:34 – Geting started with your transformation strategy. 30:35 – Bye, bye!
If you’re starting your app modernization plans with the biggest, most critical app you can find, you’re probably stumbling through the drunk under the lamppost app modernization anti-pattern. Chances are, you’ll also encounter a lot of resistance and excuses to avoid changing. Also, I discuss saying “no” more as a way to think about prioritization. Bonus topic: deep-fried bread in The Netherlands.
Chapters
00:00 – Agenda. 01:49 – The drunk under the lamppost anti-pattern. 15:09 – Start planning your app modernization journey. 18:07 – Saying “no.” 25:12 – “Too many salads.” 30:23 – Learn kubernetes, free! 32:07 – Gartner on IT strategy “turns.” 35:51 – Free developer education & bye, bye!
Topics
“With in-house development and acquisitions, FedEx would bolt on technologies resulting in an ‘accidental architecture,'”” Carter said. Through its renewal program, FedEx began to “build out the core services and microservices that represent the less complex, more flexible, faster-to-market capabilities that we have today.” From “How FedEx’s CIO led a decade of modernization.”
Don’t get obsessed with the lamppost of pain: focusing on the difficult, critical things and concluding you can’t transform. Use a type of Disruption: work on lesser, cheaper things to creep up to the critical. Mobile apps, store finder, etc.
Saying “no” as prioritization. All these execs saying no to things to focus on other customer and prospect engagement.
Corporate strategy could be improved by shifting right, moving closer to the week-to-week software cycle to get more familiar with customers and changes in the market. See more on corporate strategy in The Business Bottleneck.
Plus, I discuss bottleneck removal and thinking about policy and governance as human system, not static “laws.”
Mentioned
The Amsterdam bridge inspired font I mentioned, VLNL Berlagebrug.
When you put a new process, like agile, in place, you often realize there was very little process in the first place. Also, kubernetes at the edge, T-Mobile, and as architecture.
00:00 – Staycation.
01:32 – Doing something works better than doing nothing
04:36 – BMC case study
09:03 – ending zombie process
11:21 – lack of management tools
13:59 – example of a management tool
15:09 – three small things on kubernetes
28:31 – Your CTA!
IT, let alone software development has a poor track record for success in large organizations. And yet: we’ll told software is not critical for enterprise survival. We’ve got to figure out how to de-risk software, then. That’s the topic today.
Jana Werner, Tesco Bank – “Tesco Bank has embarked on a digital transformation journey, and at the heart of it lies a shift of culture and the adoption of modern product development practices. What could go wrong? Everything! Culture, leadership, bureaucracy, route to production, you name it. Yet, with the help of VMware Pivotal Labs, we delivered an amazing product during a time of great need for our customers: a digital gift card allowing volunteers to shop for self-isolating and vulnerable customers, while creating our very first cross-functional Product Team, now scaling out rapidly with enthusiastic people and full exec sponsorship. If you’d like to learn what it takes, what not to do, and how to fast-track your digital transformation, don’t miss this talk.”
BT wants to get better at how their do business, through software. Their strategies are, of course, operational excellence, but also getting software that improves the customer’s experience. This means they need to simplify how business is done, which they did by transforming the way they do software: IT underpins this corporate transformation, Rajesh says.
His approach to telling this story is to talk about how BT questioned some initial assumptions. On some of their initial plans, they pivoted (adapted) when they discovered new needs and realitis. On others, they persisted when they really needed the change. For example, at first, they thought that having a PaaS would be good enough for all development and app needs.
A pivot example: they discovered that more fine grained control was needed for some apps (esp. legacy ones), so they added in kuberntes. Here. PCF/TAS and TKG.
A persist example: security had to move from security by static IP. Because they were moving to AWS and microservices, things needed to be more dynamic. There was no way to achieve their tech-stack transformation otherwise. So, they persisted.
The third area he describes is their approach to removing ops toil from application developer’s agenda. As ever, they want apps developers to focus on…apps! And have time to explore and innovate making the apps better to deliver on customer service goals. (You see several example from Comcast on this with their new TV apps and improving customer service with ChatBots, and even in-home wifi coverage calibration, etc.) He also comments on a discovery, or validation of a predictable state, in my rewording: developers aren’t good at production ops and don’t really realize all the new tasks they’ll need to do – responisbilities they have! – in a DevOps model. So, they had pivot to training them and putting in place tech stuff to make it work better for them.
He has some fantastic framing: "instead of letting [developers] grapple with operating model choices, we adopted a more human-centric approach to educating teams."
He touches briefly on some portfolio modernization strategy. The benefits of doing, I think, were that they spent their time wisely, modernizing apps that were feasible and valuable to modernize instead of all of them. I could use more detail here, but I think the point is made – I mean it’s a five or six minute talk, so it’s fine. For a lot more, check out the ever excellent Rohit explaining this kind of portfolio app modernization analysis.
BT business – Fixed line, mobile TV, and networking.
Goals:
Lead in converged activity by simplifying business.
Build scalable platforms for growth.
Creating leaner business models.
IT underpins this corporate transformation.
"The challenges arise from our ways of working, process, account policies, security postures, and even we inventory software assests."
Three challenges and how they worked with them:
Strategy.
A PaaS, PCF/TAS with Spring – time to deploy from 2 months to 2 minutes. Also, microservices.
But, people wanted kubernetes for finer grain control, and needs for non/fuzzy cloud-native apps. Used TKG for this.
Listening to devteam
Security.
Moved from static IP to static IP, public IP addresses.
AWS networking needs, i.e., elastic IPs and REST endpoints.
People.
"They also were not fully aware of the [new] shared responsibilities of managing infrastructure as code, or how their roles changed when adopting the cloud."
E.g., with a more DevOps approach, "their responsibilities did not end with a cf push."
Enterprise architects looked through portfolio to bucket apps into legacy, strategic, SaaS, PaaS, and IaaS to plan out the way of working, priorities, app modernization tasks.
Drives concensous on "application treatment" and how to educate teams on their roles and new skills.
Also, this eliminates scope overlap in our budgets and app modernization plans, allowing the PaaS team to focus on executation, [instead of work that wasn’t applicable to the various apps strategies and bucketing].
Rajesh: "What really happens is you’ve got to tease out what is containerizable"
"To overcome this challenge, BT has established a platform team, dedicated to helping application teams identify these containerizable elements and find the best environment in which to host them, be it in the public cloud or on a platform-as-a-service (PaaS)."
Rajesh: "You have to handhold them, otherwise they will take the biggest unit they can handle, put that into a Docker container and then lo and behold you’ve got the same monster on better infrastructure — that doesn’t solve your business problem."
"This is a constant tussle," he admits, "where people want Kubernetes by default, but I think you’ve got to be a bit more prescriptive in the beginning to developers and then as you see them maturing, have them make those independent choices."
"the next task is to scale it out via documentation and word of mouth buzz, both for in-house engineers and with external partners."
Rajesh: "If you look at how standards are democratized, you’ve got enterprise architecture that looks at the overall architecture standards and policies, then you have solution architects, who are a level down and are specific to a product, and finally we have distinguished engineers — we call them expert engineers — who are also key influencers for other developers, who look up to them."
Charts!
Modernizers reported better outcomes across the board compared to migrators, according to IDC’s paper.
The most popular digital transformation initiatives for IBM i shops, according to IDC’s survey.
IDC questioned all four cohorts (IBM i shops that modernized, IBM i shops that migrated, System z shops that modernized, and System z shops that migrated) about their satisfaction across a range of metrics before and after their move, including: customer experience; overall performance; security, availability, and disaster recovery capabilities; agility, microservices, and DevOps; ease of finding talent; ability to incorporate AI and IoT; and API, mobile, and Web enablement.
Across all seven metrics, the IBM i and System z shops that modernized their “legacy” systems scored higher than their IBM i and System z colleagues who chose to migrate off their systems. What’s more, organizations that modernized instead of migrated reported paying less on hardware, software, and staffing, and reported higher revenues to boot.
Making software better rather than just lifting and shifting it usually works out better.
“The research effort included a total of 1,024 individuals, all of whom have a role that involves daily use of Spring.”
77% of the respondents have been using Spring Boot for 3 years or more. So, these are people very familiar with Spring and Java.
Industries: technology companies (30%) and financial services companies (20%). All major sectors are represented, including retail (8%), services (6%), and healthcare (5%).
37% work at organizations of 5,000 to 10,000+ staff. Of that, 28% from 10,000+ orgs.
So, a bit heavy on tech companies, but good enough on both industries and diverse spread of organization size.
“52% of developers surveyed use Spring boot as their only or primary development platform.”
No slow-down in use: “75% of respondents expect Spring Boot usage to grow over the next 2 years.”
Uses, lots of API use, interesting:
Types of Spring Boot apps.
Lots of public cloud only use: “When asked where they deploy their Spring Boot apps, 57% of respondents were either deploying exclusively to public cloud (21%) or in a hybrid mode with both on-prem/private and public cloud deployments.”
– Most running in containers – 65% containerize their apps, 30% planning to.
…to run in kubernetes: 44% already running in kubernetes, 31% plan to in the next 12 months.
Air France KLM modernized their payments service recently, EPASS. This is a 12 year old system that provides the backend for processing purchasing airline tickets (and other things, I guess) from numerous front-ends: the web, mobile app, and social apps as well. The system was difficult to scale, it required manually adding new servers and had a long development cycle. As more and more people want to interact with Air France KLM through software (phones, online, in WhatsApp, or whatever other “channel”), they want to be able to evolve their software quickly. They want to use software as a core innovation tool for improving customer experience and, thus, business. So, here we see one of their first experiences modernizing their backend and transforming how they do software.
Talk presented by Oya Ünlü Duygulu and Patrick Zijlstra.
Highlights
-Rick in intro: transformed payments platform in 6 weeks.
– [Corporate vision] is to provide good, “our purpose as an airline group is create memorable experiences for our passengers.
– So, they want to (1.) focus on customer centricity, (2.) innovation, and, (3.) efficiencies in our processes.
– “Digital” as the primary channel is on the rise. People want to interact through apps and such. So, KLM needs to meet the customers there… “As an airline, we want to be where our passengers are” (~3:00)
– Some examples of digital features: “‘About 10 percent of the ideas actually end up on the market. A recent example of this is the hand baggage check in the KLM app. Through augmented reality travelers can see whether their hand luggage meets the set dimensions. This function went live last month. ‘ Six months ago, a 3D rendering of the business class seats was also shown when checking in online. ‘This with the idea of stimulating the sale of these chairs.”
– For example, listening and interacting with customers in social media [something I’ve done many times – it’s great to chat with someone (or a bot?) in WhatsApps, Twitter, etc. instead of a phone call]. (~3:40) Social media is now “our closest connection to passengers.” And in China: “For instance, Chinese travelers rely immensely on mobile devices. How can these personal devices be used for authentication – identity management, payment etc. to streamline the journey wherever possible? In China, the whole landscape is different, and we need to ensure we aren’t relying overtly on drawing customers only to our touch-points.”
– (~3:10) merged together KLM and Air France backends to get less complexity in the back-end and a unified experience in the front-end for customers. Social media is now “our closest connection to passengers.”
– The use SAFe release trains (which they call “release planes”), mapped to customer value journeys, e.g., sales, paid products, or airport.
– In the digital department, they have about than 50 product teams.
– Planning every three months, come together get a roadmap from the business, and all the teams plan together. Then they start sprinting bi-weekly.
– Also shared services and practices team.
– Their /goals:
– (~5:50) “We are designing our products focused on time to market, innovation, robustness, and security.”
– Focusing on getting CI/CD in place.
– Also, reducing complexity and speeding up business value [realization], so we are moving towards a microservices architecture.
– [Business stuff:] EPASS handles payments from many places, created 12 years ago. Wanted to modernize [not sure why]. They worked with Pivotal Labs on modernization for a six wee project.
– EPASS app – made 12 years ago, handles about 37,000 payments transactions per day. Takes care of all online revenue.
– Six week engagement with Pivotal Labs. This brought expertiese from the outside, combined with their existing skills.
– “Six weeks is very ambitious for such a project, but getting this expertise from Pivotal and their dedication we made a success story at the end.”
– Modernization road-map for EPASS.
– We want to speed up with release cycles, which was then one month. [Move to single piece work-flow: whenever a user story is ready, then it can go live.]
– In six weeks, all the could focus on was transforming the app and moving it to the new platform [PCF]. But, they could also modernize their skills by adding in TDD and pair programming.
– Switches to Patrick.
– (~10:55) – they go over their way of working.
– Inception to set expectations. Outception to look back at what was achieved. Some blocker removal meetings. And the usual agile meetings.
– Two teams: one does modernization, the other delivers business features.
– Worked in one week iterations.
– Doing pair programming. “We noticed that this really increases the code quality that we deliver.”
– (~12:30) EPASS architecture. Was hosted on bare-metal Tomcat server. To scale, had to add new server and put EPASS software on it. This was becoming a hassle and fixing that was a motivation to move to VMware Tanzu.
– (~14:00) new architecture – five different components. Three in Tanzu Application Service.
– After, the majority of things were put in VMware Tanzu…
– [Picked some small things at first to test stuff out, hardcoded secrets but later fixed that – used CredHub – in long term will move to Vault.]
– (~16:00) Used Spring Boot, adding health check [this is good to highlight, that it gets instrumented/observable “for free”].
– “It was invigorating working to work with the Pivotal experts and now there’s more confidence in the team to continue.”
– Used Bamboo, added in automation stuff for deployment…
– Problems: networking problems
– Benefits: response times improved by 10%; “all the power for scaling is within the product team itself” instead of having to work with other groups, file tickets, etc. Also, time to patch is within 72 hours (3 days).
– (~21:08) “The experience was very positive. It was invigorating to work with the Pivotal experts. And, now there’s more confidence within the team to continue to improve the application.”
– The projects have been finished for a few months. No more components in bare-metal Tomcat.
– “From the organization side, there is no more fear of big changes. If such an old application as EPASS can transform, then it’s possible for any application.”
– “So more and more and more applications will be moving to TAS [Tanzu Application Service].”
The panel I put together and moderated for this year’s SpringOne. It turned out really well. Here’s the abstract:
When you’re trying to improve how your organization does software, how do you change what managers and executives do? We hear a lot about how developers and operators change, the composition of product teams, and always about Kubernetes. But there’s very little conversation about transforming management. This panel of managers will discuss what managers’ and executives’ roles new and old look like, managing managers, and how individual managers can manage their careers when their role changes.
The panelests: Neville George, Manager at Comcast; Jon Osborn, IT Executive at Bell Tracy, Ltd.; Jana Werner, Head of Transformation at Tesco Bank
In larger organizations, there are layers of managers, in a good way: teams aggregate to a manager, that layer of manager aggregates to another, then somewhere there’s executives, and, I don’t know, the mythical shareholder. Everyone has a boss. I want to discuss what it’s like to be the boss of all those managers and help them transform into all the existing, new fangled agile and digital transformation stuff. Most of the discussion I encounter is about individual staff and the product teams (those working on software or running it), but I don’t hear much about the management structures above those teams. Also, it’d be interesting to talk a little about what exactly things like “servant leadership” mean and how one manages their career (gets promotions, more compensation, etc.) when they’ve moved from being The Boss to a servant (to be tongue in cheek about it).
Questions
We’ve heard the notion of servant leadership, which sounds, you know, helpful. Can you give me an example of what that looks like though, like an actual one that happened?
I was watching a webinar that Jana did recently on her white paper. In the Q&A, they asked attendees something along the lines of “do you ever think of your organization’s vision and strategy, does it ever determine what you work on and how?” As I recall, almost zero percent of people responded yes. This seems like a critical tool for managers to use if they’re setting up autonomous teams that need to make decisions on their own – they need to know the principals, the goals. How should managers be moving beyond facile vision and strategy?
For years, I’ve heard about “the frozen middle,” managers who don’t want to change despite the urging and permission of executives (“above” them) and enthusem of staff (“below”). Is this cliche real? If so, what causes that frozen-ness?
(Following on from that), when you’re managing managers, what are you doing in this new, agile, world? Are you a servant to the servants?
There are occasionally “accidental managers” who sort of ended up there. But most of them have been pursing a career of going “up” the meatware stack. They want to grow their career, which usually means responsibilities, the glory and power that goes with it, and the rewards. So, if you’re a servant to people below you, how do you end up managing your career?
As you push responsibility down to teams, what are safety nets you put in place as they figure it out?
The report goes over how software development needs and programs should adapt to the urgency that COVID brings. Highlights:
Obviously, teams are working from home more now. This exposes all of the face-to-face, undocumented processes that were happening (“manual processes address handoffs across departmental boundaries”). If there were too many, work can’t happen as well anymore when everyone is working from home.
“The trend catapulted use of Zoom, a videoconference service, from 10 million average daily users to 200 million during March 2020 and introduced us to our coworkers’ tastes in home décor.1 But it also separated millions of workers from the paper files they require to complete their missions, breaking millions of business processes. Paper files are an obvious point of failure, but manual processes based on desktop tools like excel and email lack visibility and tracking that are vital to remote workers.”
Paperless efforts are really on the front-burner now: “any enterprise relying on paper to advance its processes needs to automate just to continue to function.”
Also: “Topping the list for most now are tracking and tracing applications: tracking of employees, people entering hospitals and other sensitive buildings, equipment, facilities, patients, tests, research results, and on and on. These applications are not throwaways; they’re business-critical. and in the public sector, throw in new apps to manage new support, recovery, and stimulus programs or support existing programs straining under unprecedented volumes. Then in financial services, you have new servicing apps: servicing debt, defaults, new rescue programs, moratoriums, etc. (rather than new customers and new products and services). and any enterprise relying on paper to advance its processes needs to automate just to continue to function.”
And, more app types:
This urgency is driving business people to (finally) start getting involved more in IT/software: “as organizations scramble to fix processes and rapidly automate to keep them running, it becomes clear that businesspeople are the primary source of operations insight…. Bringing businesspeople closer to the development process through iterative, rapid prototyping and sometimes allowing them to develop solutions on their own offers promise for much faster and more agile responses to business needs.”
With apps being used remotely (as a SaaS, over the internet), organizations will likely discover new scaling needs – when the apps run outside the corporate network, and are home grown. “Scale becomes a vital focus. Many development teams are getting their first glimpse at what massive scaling looks like for their applications.”
Companies are overworking staff: “a us hospital network made Java developers scramble 24×7 for 20 days to create a visitor registration application to extend its hospital administration system.” [This isn’t sustainable and if done too much will leave a bad taste in staff’s mouth about “agile” and “digital transformation.”]
The authors really like and recommend low-code stuff. This probably makes sense to get a lot of line-of-business people to start putting together wizards and UI-driven workflows around databases, Excel/CSV, and APIs to ERP systems.
I like to track CI/CD* surveys as an indication of far along organizations are doing at getting better at software: “digital transformation” where the main focus is using software to improve how you do business.
If you’re not doing CI, you’ll have a hard time getting better at doing software, or, really, doing good software at all. I
Anyhow, here’s one chart I put together based on the State of Agile surveys:
Source: State of Agile Surveys, 3rd through 14th, VersionOne/CollabNet/digital.ai. CI/CD not tracked in 5th/2009. Over the years, definitions change, “delivery” and “deployment” are added; but, these numbers are close enough to other surveys to be useful. See more CI/CD surveys: Forrester survey (2019), DZone CD reports (2014, 2015, 2016, 2017, 2019).
The data isn’t perfect, scientific, or whatever. But it’s a good rhetorical device. Also, it matches up with other surveys on this topic (from the likes of Gartner and Forrester).
The general take is: CI has plateaued, but it’s high; CD has been slow to catch on and still has only minor growth in adoption year over year.
So, if you think you’re doing agile, there’s a good chance you’re not. Go do a walk-about and see what’s actually happening and make putting CI/CD in place a priority if you’re not doing it. Otherwise, all your other efforts to get better at software will fail and be a waste.
(Also, as noted by Jon, if you don’t have testing in place, then start there. Also: version control. Yes, it’s worth mentioning that. You’d be shit-your-pants surprised.)
A two part video/podcast, with white-boarding and stuff. Rohit Kelapure knows his stuff from years of first-hand work. If you’re working in an enterprise on software, and especially if you’re an enterprise architect, you should check these out. The real work of application is modernization isn’t rewriting and re-platforming, but it’s the analysis that goes into finding and ordering what to modernize and then the process that runs your program over the next few years. Rohit boot-straps you into that.
Because of lack of skills, they setup a team (named Stratus) to centralize [and also market?] the new platform.
(~4:10) – Building a centralized, standardized platform is important for efficiencies (reducing duplicated efforts) but also governance and maintainability, long-term. “We are building a solid container platform. Why would a team not do it themselves? If you have about 600 teams that want to use containers and everyone would need to build their own unique container platform, it would become unmanageable as a company you cannot control it, and it would be a lot of reinventing the wheel.” MS-Word dictation transcription: And that’s something you don’t want because then things are wasting, the team’s time, the valuable time so therefore it would be good if one team would build a strong foundation or the other teams can build on top of that. Also need to enforce policies/governance/security on the team’s work.
They do the typical platform team stuff – building the platform, running it, evolving it, consulting for it, etc.
They basically use Azure, with some AWS it seems:
~7:30 figuring this out all on your own can be very time consuming – maybe a couple years of learning, PoC’ing, [vendor negotiations], etc. We needed to do it in one. We started with the CNCF reference diagram.
[I didn’t pay attention closely enough much beyond to take good notes.]
