Multi-cloud as dragging workloads across clouds hampered by data gravity

Organisations should not make portability a primary driver for adopting Kubernetes, Meinardi explains, as the likelihood that an application, once deployed, will move to a new infrastructure provider is actually very low.

This is simply because databases and data lakes are expensive to move, weighing down applications. The truth is that most organisations don’t think moving this data is worth the hassle so end up sticking with the same provider.

Gartner analysts question Kubernetes portability credentials

Relearning to change, improve

This is the process of relearning, which comes with its own challenges: (1) you must be willing to adapt and be open to information that goes against your inherent beliefs (2) you may need to to learn how to learn again and (3) you must create an environment for relearning to happen in a meaningful, yet often challenging, space outside your existing comfort zone. The point of relearning is that you’re trying to get better information and learn to see, sense, and listen differently, to respond and act differently.

Original source: Book Review: Unlearn by Barry O’Reilly

Move from the Bay Area, get paid less

But employees who worked at VMware’s Palo Alto, California, headquarters and go to Denver, for example, must accept an 18% salary reduction, people familiar with the matter said. Leaving Silicon Valley for Los Angeles or San Diego means relinquishing 8% of their annual pay, said the people, who asked not to be identified discussing internal policies.

Original source: VMware Cuts Pay for Remote Workers Fleeing Silicon Valley

Air France KLM modernizes their payments service, SpringOne 2020 talk – Notebook

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.”

– 350 agile teams. Using Scrun, Kanban. SAFe. See SAFe case study from ~2018, and some trip notes from someone at ACM Agile.

– 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].”

Little boxes

McLuckie has explained that with containerised applications running on an Infrastructure-as-a-Service (IaaS) model, code could be written in a hermetically-sealed unit, from which it could be deployed, whole, into disparate environments — a test cloud and a production cloud, for instance.

So far, this standardization of packaging and app architecture looks like one of the most useful effects of kubernetes. Using kubernetes comes with an implicit architecture model, a way of instrumenting applications (making them observable and manageable in production), and a defined life-cycle. It’s not perfectly clear-cut, but there are enough constraints in how you package up, deploy, and run apps in kubernetes that you don’t have many options.

This gives you an architecture you can just accept and start using: you don’t need to spend months – years, often – debating an enterprise architecture in your organization, coming up with many competing stacks, and then 3 or 4 years later sort of deciding on one but having to live with all that variation (e.g., the state we’re currently in).

Less grandiose, it means less architectural position papers you have to write, less meetings to go to, less arguments with rival ideas, and less time spent building and enforcing the policy of your enterprise architecture. Instead, you can spend all that time making the application better, and, thus, the business better. No CEO ever cared which kubernetes distro you ran, how much you paid to build or licenses it, or if it’s multi-cloud. They care if it helped them make money.

The same applies to ops: there’s now one way (sort of) to understand and manage it all. In contrast, we current have many different ways and tools, often customized within large organizations. That much variety ends up costing too much, and slowing things down more than you’d think.

Original source: VMware VP: Kubernetes as the ‘new IaaS normal’

Sharp edges

“We’re seeing Kubernetes emerging not just as an infrastructure service abstraction, but as a dominant control plane for driving workloads, whether those workloads are running in Linux application containers or pretty much anywhere. And that’s an absolute delight.”

The downside is that “it’s a fancy system and it has some really sharp edges.” This brings us back to the goal of simplifying the developer experience. “Creating a comfortable environment that uses the power of the system, that doesn’t force them to deal with all these sharp tools that can cut them all the time, is very important,” said McLuckie.

Original source: VMware supremo Pat Gelsinger makes peace with Microsoft, and Virtzilla pitches Tanzu to the Spring crowd

Manager, Heal Thyself! 

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

Portability isn’t a thing with kubernetes

Kubernetes facilitates portability because it helps standardize our software development life cycle and, most importantly, our operating model. However, it also adds management overhead to our organization, it forces us to engage with commercial vendors and to completely rearchitect our applications. Implementing portability with Kubernetes also requires avoiding any dependency that ties the application to the infrastructure provider, such as the use of cloud provider’s native services. Often, these services provide the capabilities that drove us to the cloud in the first place.

In conclusion, the portability tax is high. Make sure to pay it only for applications that truly need it and that are likely to switch infrastructure provider at some point. For all the others, don’t choose Kubernetes on the basis of a universal portability principle, just because it “sounds right”. On the contrary, adopt Kubernetes for agility, scalability and for modernizing your application architectures.

Original source: Why Adopting Kubernetes for Application Portability Is Not a Good Idea, Marco Meinardi, Gartner

Getting ready for change sure pays off when things change

Strong digital foundations are already helping leading companies adapt to the crisis quickly. One global retailer that invested for years in true omni-channel sales and delivery had already offered curbside pickup at 100 of its stores. When forced to close its physical stores owing to COVID-19, in just 48 hours it was able to expand its curbside service to 1,400 stores while maintaining a majority of its revenue. Meanwhile, many of its competitors struggled to shore up their online channels.

Black Swan thinking seems to be the principal that surviving long-term is all about avoiding the rare, but reliable occur disaster. When times are good, things are easy. You have the prepare for the worst, because eventually the worst will happen.

Original source: Accenture’s CEO: 5 rules for rethinking digital transformation during COVID-19

Gartner on Google Cloud

How about Google? Gartner said it is also strong for “every use case,” apart from edge, which is a rather strong caveat. It has won developer “mind share” via open source Kubernetes and TensorFlow, and according to Gartner, “closed a number of critical capability gaps between GCP and Azure.”

The analysts were not happy with GCP’s availability record, however. “Google’s much-vaunted network capabilities have been the source of a number of GCP outages during the last year, with devastating impact on customers,” they wrote.

The fact that GCP is “a small fraction of overall Google revenue” is also a concern, presumably on the basis that if parent company Alphabet were to decide to change track, the cloud product set might no longer keep pace with its competition.

Based in Tim Anderson’s summary, it seems like the MQ matches everyone’s general sentiment and folklore about the public cloud providers.

Public cloud is just becoming normal IT, with the usual benefits and faults. Ongoing, as negatives are found, the framing will likely be: it’s better than the alternative. That is, whatever faults public cloud has, the overall benefit will likely be better than sticking with majority on-premises.

Original source: Gartner on cloud contenders: AWS fails to lower its prices, Microsoft ‘cannot guarantee capacity’, Google has ‘devastating’ network outages