devopsy.kinsta.cloud

Category: DevOps in the Cloud

IBM ‘is Ageist and Sexist’ | IBM Mainframe-aaS | IBM Vaccine Mandate

Think! Welcome to Big Blue Week here at The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: IBM’s employment practices scrutinized, IBM z/OSaaS breaks cover, and IBM encourages staff back to the office.

1. ‘Dinobabies’ and ‘Dated Maternal’ Workforce Woes

First up this week: IBM’s defense in an employment age discrimination lawsuit looks to be shredded. Internal emails “appear to show high-level discussion about paring the ranks of older employees.”

Analysis: Not a good look

According to one of the plaintiff’s lawyers, unnamed “top IBM executives were explicitly plotting with one another to oust older workers … to make room for millennial employees.” On the face of it, they seemed to be doing the polar opposite of the Age Discrimination in Employment Act.

Noam Scheiber: Making ‘Dinobabies’ Extinct: IBM’s Push for a Younger Work Force

Top IBM executives were directly involved in discussions about the need to reduce the portion of older employees … sometimes disparaging them with terms of art like “dinobabies.” … Documents made public by a Federal District Court … show executives discussing plans to phase out older employees.
…
The newly unsealed documents, which quote from internal company emails … show top IBM executives specifically emphasizing the need to thin the ranks of older workers and hire more younger ones. [One] email refers to IBM’s “dated maternal workforce,” an apparent allusion to older women, and says: “This is what must change. They really don’t understand social or engagement.”
…
Adam Pratt, an IBM spokesman, [claimed,] “IBM never engaged in systemic age discrimination.” [He] said that some of the language in the emails “is not consistent with the respect IBM has for its employees” and “does not reflect company practices or policies.”

Yikes, ageism and sexism? Experienced staff are valuable, says MrBanana:

I did some time at IBM [and] remember being invited to a meeting with a new group, headed by a new “thinker,” who had something to present to myself and a colleague. We walked past the foosball table to the meeting room. Naturally the room had no chairs, and was covered in multi-coloured Post-it Notes. Once they had gone through their mood boards and the non-linear presentation of this new idea, I turned to the other old geezer in the room. “Didn’t we look at something like this 8 years ago?”

“Yeah, we worked out that compute power just to run the UI for one session wouldn’t be available for a couple of decades.” The children were somewhat disappointed, and (fortunately) we were never asked back to their romper room.

But experience can be both a blessing and a curse, learned aahortwwy:

I experienced both sides of this in five years at a company in hypergrowth. … I learned so much at that job: … In year 1, I was determined to accomplish X and ignored the skeptical comments of some colleagues who’d been at the company longer than me. I failed and wasted some time. In years 4 and 5, new colleagues were determined to accomplish X and ignored my skeptical comments.

2. IBM Wazi as-a-Service Confusion

“Mainframe” is not a dirty word. It’s secure, vertically scalable, and it put the VM in VMware. Now, what IBM Wazi did for on-prem LPARs, Wazi aaS promises to extend to hosting z/OS instances.

Analysis: Mainframe-as-a-service reinvented

Mainframes and cloud-native DevOps need not be incompatible. To modernize legacy apps using hybrid cloud instances for dev/test—and even prod—can be a big productivity boost. But isn’t it weird that IBM spun out its mainframe-as-a-service zCloud offering only a few months ago?

Mike Vizard: IBM Shifts Mainframe App Testing to the Cloud

While many workloads over the years have been migrated off mainframes or simply retired, the applications that run on z/OS today are still among the most mission-critical that organizations run. … IBM this week revealed it has added the ability to set up testing environments on the IBM Cloud for z/OS mainframe applications.
…
IBM plans to make IBM Wazi as-a-Service (Wazi aaS) for z/OS generally available in the second half of this year, [which] will enable DevOps teams to self-provision an instance of a z/OS virtual server on a secure private space running on IBM Cloud. … At the same time, it will become easier to modernize mainframe applications by making them more accessible to other applications via a set of secure APIs … using a cloud-native set of DevOps tools that run in a Kubernetes environment.
…
Modernizing mainframe applications is a less complicated endeavor than migrating them. The challenge is that building, deploying, maintaining and securing all the APIs required to do so represents a significant amount of effort.

OK, boomer, why are we talking about 1960s mainframes on DevOps.com? Here’s ArchieBunker:

Mainframes are different beasts altogether, almost alien when you compare them to PC hardware. You have binaries written for the S/360 system in the 1960s? Good news you can still run them natively without a recompile.

You think virtualization and containers are a hot topic? IBM was running multiple OS instances inside a VM in the 1970s. … The engineering is incredible.

But z/OSaaS? It’s déjà vu time for Beleagured Greybeard:

“Cloud Managed Services for z” AKA “zCloud” has been around for over 10 years. … IBM offloaded it with the Kyndryl spin, so its odd that they now want to re-invent it.
…
If it’s a strategic platform, why didn’t they hold onto it instead of spinning it off to Kyndryl? Sounds like yet more daft leadership decisions.

3. IBM’s Return to Work Plan has Vaccine Mandate

IBM wants to “keep employees safe” as they return to office work after being fully remote. In practice, this means a vaccine mandate.

Analysis: IBM Digital Health Pass is divisive to vocal minority

Although there are exemptions on medical or religious grounds, IBM has promised to place dissenters on unpaid leave. As you might expect, the policy has a few employees up in arms.

Cassie Werber: How Salesforce, IBM, and HSBC are approaching return to work

When the pandemic hit, and IBM moved 95% of its workforce to fully remote, it was pleasantly surprised to discover no drop in productivity. … Still, they planned to return to offices.
…
The company saw this as a way to keep employees safe. … One example … is its development of the IBM Digital Health Pass as an alternative to vaccine cards or paper vaccine certificates, which they use to make sure all the staff that come into their offices are vaccinated.
…
Arvind Krishna, IBM’s CEO, meanwhile came up with what he called the IBM Work From Home Pledge. [It] included commitments to flexibility, kindness, sensitivity to family, setting boundaries, and acknowledged video fatigue. It concluded with a commitment to “be connected.”

Tricky to “be connected” if you’re not allowed back in the building. Anne D’Innocenzio, Heather Hollingsworth, Tali Arbel, Mae Anderson, Ken Sweet, Matt O’Brien and Dee-Ann Durbin:

IBM software engineer Justin Albano said his company recently notified employees that it would be revoking badge access to workers who aren’t vaccinated or haven’t proved that they are. “We’re not able to enter an IBM office at this time,” said Albano.
…
He said some workers have successfully sought religious exemptions but “my thought process was I shouldn’t have to explain to my company my faith” to get out of a policy that’s “immoral in its foundation.”

What’s the alternative? With a perspective, it’s Chris Haney:

Or, get the vaccine. Protect yourself and the people around you. You people really are detached from reality.

The Moral of the Story: Those who know do not speak; those who speak do not know.

You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

Image: Marcin Wichary—cc:by; leveled and cropped (ask your parents)

February 17, 2022
Cloudify Integrates DevOps Automation Platform With Terraform

Cloudify this week announced a free user interface (UI) module that extends its infrastructure provisioning platform and enables DevOps professionals to integrate unlimited Terraform modules.

Nati Shalom, Cloudify CTO, said Terraform UI provides a familiar construct for DevOps teams using the open source DevOps automation platform to provision infrastructure-as-code (IaC). The module enables DevOps professionals to seamlessly import Terraform modules to Cloudify without writing blueprints or any additional glue code, he said.

Cloudify now automatically generates the wrapper required for each Terraform template to enable DevOps teams to collaboratively manage secrets, execute concurrent deployments, store states remotely and monitor deployments, users and versions via any Git repository. Those Terraform modules can then be integrated with application programming interfaces (APIs) and continuous integration/continuous delivery (CI/CD) platforms as DevOps teams require.

DevOps teams can also import existing automation modules and scripts into Cloudify. Those modules and scripts can be automatically converted to environments that can be centrally managed via the Cloudify console or via export to ServiceNow’s IT service management (ITSM) platform as a software-as-a-service (SaaS) application.

That approach provides the added benefit of enabling DevOps teams to centrally manage all Terraform modules and versions via a single console as part of an effort to reduce misconfigurations that lead to security breaches, he added.

Cloudify enables DevOps teams to create a self-service catalog and portal through which infrastructure can be managed. Many DevOps teams have built their own portals to manage this process. However, Shalom noted those DevOps teams then need to devote resources to maintaining that portal when those resources could be allocated to other critical tasks.

DevOps teams can not only use Cloudify to apply patches, change topologies, add security features, make configuration changes or make additional resources available, Shalom added, they can also now integrate Terraform tooling with platforms such as Kubernetes or other automation frameworks such as Ansible. Cloudify also makes available an enterprise-grade version of the platform with these integrations.

It’s not clear how much time and effort IT organizations are investing in building and maintaining DevOps environments. In many cases, however, organizations should probably revisit decisions about building capabilities that, at the time, didn’t exist. That doesn’t necessarily mean that replacing custom DevOps tools makes sense across the board, but it is likely that, in the intervening years, the range of tooling made available via DevOps platforms has greatly expanded. Relative newcomers to DevOps, meanwhile, are enjoying the benefit of platforms they did not have to construct themselves.

In fact, Shalom noted that, in terms of DevOps adoption, an inflection point has been reached as more organizations launch digital business transformation initiatives that require applications to be both built and deployed faster than ever. The challenge, of course, is enabling that to occur both safely and at a reasonable cost.

February 17, 2022
How to Migrate Existing Infrastructure to Terraform
Infrastructure-as-code (IaC) enables managing and provisioning infrastructure through code instead of manual processes. IaC is crucial for DevOps teams as it lets them manage infrastructure components, such as networks and load balancers, and enables test applications in production-like environments early in the development cycle. It allows DevOps teams to build, change and manage infrastructure in a safe, consistent and repeatable way.

While infrastructure as code might traditionally be frustrating, as it requires cloud infrastructure to be created manually, Terraform brings the existing infrastructure under code management safely while removing manual processes. Terraform is one of the most popular open source IaC tools because it lets a user define resources and infrastructure in human-readable, declarative configuration files and easily manage infrastructure’s life cycle. It provides several other advantages such as the ability to manage infrastructure on multiple cloud platforms, write infrastructure code quickly, easily track resource changes throughout deployments, version control functionality and more. Terraform can operate on all cloud providers such as AWS, GCP and Azure, and is easy to install on machines or remote build servers.

How is Terraform Different?

Increasing fault tolerance by spreading infrastructure across multiple clouds is a common practice, as using a single cloud provider may provide a single point of failure. Multi-cloud deployment allows for easy recovery of the loss of a region or entire provider. But it can be challenging, as many existing tools for infrastructure management are cloud-specific.

Terraform addresses these challenges as it is cloud-agnostic and allows a single configuration to be used to manage multiple providers. It can also handle cross-cloud dependencies by simplifying management and orchestration.

Terraform provides a flexible abstraction of resources which allows DevOps teams to represent everything from physical hardware, virtual machines and containers to DNS providers easily. This flexibility can also manage a single application or even an entire data center—making it highly sought-after compared to other IaC tools.

Migrating From Existing Infrastructure to Terraform

Terraform brings existing infrastructure under as-code management in a safe and incremental way. One can easily migrate from an existing infrastructure by following these steps:

Install Terraformer from the below link:

Terraformer Install

To import resources from all services, use -- resources="*"

To exclude certain services, one can combine the parameter -- excludes to exclude resources from services. For example, --resources="*" --excludes="iam"

After downloading Terraformer on the machine, one can migrate existing infrastructure into Terraform. For a smooth migration, everything must be included in a single command; otherwise, the state file may be lost or replaced. To migrate manually created resources, you need to specify everything in a single command.

For setting it up on Google Cloud, for example, one must access the information from Google Project and provide authentication information by setting up the environment variable “Google_Application_Credentials” along with the file path to the JSON file that contains the service account key. In this example, we migrated GKE clusters in GCP.

terraformer import google --resources=gke --filter=container_cluster=<Clusters-name separated by :> --filter=container_node_pool=<node-pools name separated by :> --regions=<region-name> --projects=<project-name>

Running this command will fetch all the resources of GKE into the local machine. However, this requires changing the backend to make these changes to Terraform cloud. Here’s how to do that:

backend "remote" {

organization = "<organisation-name>"

workspaces {

name = "<Your workspaces>"

The backend should be kept in a remote setting. The above steps ensure that the GKE cluster is migrated to Terraform without any interruption.

Challenges in Migrating Infrastructure
While Terraformer is an important tool to automate infrastructure and reduce the complexity of managing resources manually, migrating the infrastructure to Terraform can have its own set of challenges. It is important to include all the services in the import command. Failing to do so might require migrating the infrastructure by writing individual files which can be an intimidating task. Another challenge is that while importing different services, the backend file must be replaced or it may lead to losing the first infrastructure backup in the remote backend.

Importance of Migrating Existing Infrastructure

Migrating existing infrastructure to Terraform has several benefits such as:

Easy migration of all the existing infrastructure into the cloud without any interruption

Easy management of resources on the cloud while keeping track of changes

Secure deployment of resources in Terraform cloud

One further caveat: Terraform is a relatively new technology and adapting it to manage an organization’s cloud resources might take some time and effort. It requires specialized skills and training to use Terraform to effectively manage cloud infrastructure. It may also be challenging to use it while dealing with concepts such as a remote backend. Despite these hiccups, Terraform offers huge advantages for DevOps teams to easily manage infrastructure.
February 16, 2022
IBM Shifts Mainframe App Testing to the Cloud

IBM this week revealed it has added the ability to set up testing environments on the IBM Cloud for z/OS mainframe applications.

In addition, on March 15, IBM will make available an IBM Z and cloud modernization stack to make it simpler to modernize mainframe applications by adding application programming interfaces (APIs) using a cloud-native set of DevOps tools that run in a Kubernetes environment.

Tarun Chopra, vice president for the IBM Z Hybrid Cloud, said IBM Z as-a-service on IBM Cloud for development and test eliminates the need to dedicate mainframe capacity to an application testing environment. Instead, mainframe application testing can now occur in the IBM Cloud, he added.

Currently available as a closed experimental today, IBM plans to make IBM Wazi as-a-Service (Wazi aaS) for z/OS generally available in the second half of this year. That offering will enable DevOps teams to self-provision an instance of a z/OS virtual server on a secure private space running on IBM Cloud.

That hybrid approach means application testing no longer disrupts mission-critical applications running in production environments on a mainframe, added Chopra. The overall time required to gain access to a z/OS development and test environments will drop from days or weeks to six minutes or less, he said.

At the same time, it will become easier to modernize mainframe applications by making them more accessible to other applications via a set of secure APIs. Many organizations today increase their technical debt by duplicating functions that already exist within mainframe environments simply because those functions are not easily accessible to developers. The IBM Z and cloud modernization stack makes it simpler to modernize mainframe applications to drive a digital business transformation initiative without increasing the overall technical debt an organization needs to service, noted Chopra.

While many workloads over the years have been migrated off mainframes or simply retired, the applications that run on z/OS today are still among the most mission-critical that organizations run. A recent IBM Institute for Business Value study found 71% of respondents said mainframe-based applications are still central to their business strategy. Four out of five respondents also noted they needed to modernize those applications, as well.

Modernizing mainframe applications is a less complicated endeavor than migrating them. The challenge is that building, deploying, maintaining and securing all the APIs required to do so represents a significant amount of effort. IBM said it is committed to simplifying the mainframe app modernization process.

One way or another, mainframe applications are becoming part of the larger distributed computing environment. Most organizations that have invested in mainframe applications continue to run them in on-premises environments because of the unique transaction processing capabilities a mainframe provides. Mainframe applications that have been migrated to the cloud generally run more slowly than they did when running natively on a mainframe. There may still be circumstances where migrating a mainframe application to the cloud makes sense as part of a larger IT strategy. However, like every other application being accessed over a wide area network (WAN) there will always be performance tradeoffs to consider.

February 15, 2022
Unreliable Server Scare | Information Batteries | ARM IPO PDQ

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: We worry about chips failing randomly, we ponder a new way of thinking about workload shifting, and we grok Arm’s IPO.

1. Smaller Features Lead to Random Failures

First up this week: Could cosmic rays be causing increasing numbers of errors in cloud servers? As chips get faster and more densely packed, the worry is that undetected bit-flips could cause serious problems.

Analysis: How can you mitigate the problem?

As workloads grow in number and complexity, this is becoming a real issue—not merely theoretical. (See also: DevSecOps worries such as Rowhammer.) Think about where the critical data are and how to detect random errors. Even consider running important workflows in lockstep pairs.

John Markoff: Tiny Chips, Big Headaches

Imagine for a moment that the millions of computer chips inside … the largest data centers in the world had rare, almost undetectable flaws. … As the tiny switches in computer chips have shrunk to the width of a few atoms, the reliability of chips has become another worry for the people who run the biggest networks. … There is growing evidence that the problem is worsening with each new generation of chips.
…
Both Facebook and Google have published studies describing computer hardware failures whose causes have not been easy to identify. … Facebook researchers noted that some processors would pass manufacturers’ tests but then began exhibiting failures when they were in the field. … Smaller transistors, three-dimensional chips and new designs that create errors only in certain cases all contributed to the problem … according to Google.
…
Intel executives said they were familiar with the Google and Facebook research papers and were working with both companies to develop new methods for detecting and correcting hardware errors. [But] computer engineers are divided over how to respond to the challenge.

Have we hit a wall? So asks Thutmose V:

For more than 50 years, semiconductor manufacturers have been trying to keep up with Moore’s Law, which … has effectively served as the target for semiconductor engineers to push them forward. … The size of some parts of the transistors is now 10 nanometers or less. 10 nanometers is about equal to the width of 100 silicon atoms—100 atoms is not very many.
…
When things are that small, does quantum randomness start to be noticeable? Normally if the odds of something failing is a trillion to one, you don’t need to worry. But if you have 10 billion transistors operating at a clock speed of 3 billion times a second, a one in a trillion chance of failure is nowhere near good enough. … It is a miracle these things work as well as they do.

We’ve known about the problem for years, but only now is it becoming reality, says dsgrntlxmply:

We observed certain network failures to be caused by corruption of an on-chip routing table memory in a SoC that lacked parity protection for these tables. The failure rate was low, but was higher in units that were deployed at higher altitudes. … The problem was eventually mitigated by software table sweeps, and in newer SoC generations, by parity in critical tables.

These Single Event Upsets are said to be caused by muons generated by high energy cosmic ray interactions in the upper atmosphere. Third semester undergrad physics.

2. Mind-Bending Speculative-Compute Research

Many of us are familiar with delaying a workload until a time when servers are idle—or when energy is cheap. But some fascinating research asks: What if we could predict a future workload and perform it in advance?

Analysis: “Information batteries” can be cheaper than Li-ion

The researchers argue that pre-caching even parts of a workload’s output when energy costs are low—or even negative—can save far more money than traditional grid-scale storage such as batteries or pumped hydro. For example, speculatively transcoding video versus generating it on the fly, or predicting future machine learning training workloads.

Caitlin Dawson: A New Way to Store Sustainable Energy

Renewable energy has an intermittency problem. … What if surplus renewable energy could be stored as computation? … That’s the thinking behind “information batteries,” a new system proposed by … Barath Raghavan, an assistant professor in computer science at the USC Viterbi School of Engineering … and Jennifer Switzer, a Ph.D. student from UC San Diego.
…
When renewable energy is available in excess, it is used to speculatively perform computations. … The stored computed results can then be used later when green energy is less plentiful. … For instance, every day, YouTube data centers transcode more than 700,000 hours of videos to different resolutions. Many of these computations are predictable and can be performed at a time when there is excess green energy.
…
[But] computations that are completed in advance do not need to match exactly with the computations completed at a later time. … The challenge, said the researchers, is determining what computation to perform, where and when, and how … to efficiently retrieve the results later. … It is only possible in some workloads and in some contexts. But Raghavan believes with improved prediction and integration into large systems, the technology points towards a promising future alternative.

This isn’t just batch computing with a fancy name. cognizant_ape explains:

On AWS we do a lot of batch processing when the data centers are low on traffic. This is just the standard SPOT instances which you can trigger once the cost goes below a certain amount and then end when it goes about a certain amount.

The big issue is being effective with I/O and setup time. The article seems to be getting ambitious to the point of a distributed compiler with a flexible optimization metric.

Cut to the chase. It hinges on prediction, says bradley13:

Predicting loads is easy, but predicting the computations that will make up those loads? Not so much. … Imagine: Most employees start work in an hour — let’s predict which database queries they will generate. Your success rate better be high.

3. Confirmed: Arm will IPO, Not be Sold to Nvidia

SoftBank and Nvidia have bowed to the inevitable. Arm, designers of ubiquitous chip cores, will IPO sometime in the next 12 months.

Analysis: The only sane choice, but ecosystem risk remains

As I’ve said before, it seemed everyone was against the idea of Nvidia owning Arm. It put the kibosh on Arm’s open licensing stance, dooming the ecosystem to scraps from the table as Nvidia grabbed first dibs on everything. Now regulators must turn their attention to the very real risk that Nvidia will still acquire Arm anyway—via the stock market.

Richard Waters, Arash Massoudi, James Fontanella-Khan and Antoni Slodkowski: $66bn sale of chip group Arm to Nvidia collapses

The deal, which would have been the largest ever in the chip sector, was set to give … Nvidia control of a company that makes technology at the heart of most of the world’s mobile devices. A handful of Big Tech companies that rely on Arm’s chip designs, including Qualcomm and Microsoft, had objected to the purchase [arguing] that Nvidia would get an unfair advantage by having first rights to Arm’s technology.
…
Jensen Huang, Nvidia’s chief executive, hoped to use Arm’s processor designs to cement his company’s growing role in data centres. … Nvidia abandoned its pursuit of Arm at a board meeting on Monday, said a person familiar with the discussion.
…
The deal’s failure brought an immediate management shake-up at Arm, with chief executive Simon Segars replaced by Rene Haas, head of the company’s intellectual property unit. … In the UK, where politicians view Arm as a strategic national asset, attention is set to shift to whether the company will be listed in London [but] Haas said … no decisions had been made on where Arm would be listed.

Reminding us why this matters to DevOps, here’s Timothy Prickett Morgan:

Now there is no question that Arm Holdings will be going public. … The plan is to do so before the end of [its] fiscal year in March 2023. … Arm Holdings will be returning to its IP licensing roots, having spun off some uncore business back into SoftBank, and seeking out new markets as it has been able to do with hyperscalers [and] cloud builders.
…
When Intel was worried about AMD Epyc chips, what it really needed to worry about was boosting price/performance to keep Arm CPUs out of the hyperscaler and cloud builder datacenters. [But AWS] has Graviton Arm server chips on a pretty regular schedule, and you can bet Masayoshi’s last yen that Graviton4 will debut at re:Invent 2022 this year.

But what happens next? Pun it up, HereAndGone:

If Softbank is going to take ARM public, Nvidia will find it much cheaper simply to acquire a controlling interest. … Looks like a duck, walks like a duck, but cheaper than a duck—while ducking regulatory issues. This plan is not quacked up to solve what it pretends to solve and will likely prove most fowl.

The Moral of the Story: Fall seven times and stand up the eighth

You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

Image: Nicole Geri (via Unsplash; leveled and cropped)

February 10, 2022
How Stream Processing Goes Beyond Real-Time

How fast is real-time? According to Robert Miller’s 1968 seminal study on human-computer interaction, we perceive a response time of 100 milliseconds or less as instantaneous. This is much quicker than the average human reaction time, which one online test clocks at 273 milliseconds.

Nowadays, customer-facing applications need to respond in as close to real-time as possible to win our attention and meet standard requirements. For example, 100 milliseconds is a golden rule for credit card processors to meet SLAs. Especially in our new remote-first economy, other areas like media, health care, retail and manufacturing need to take full advantage of real-time data processing to enhance digital business and stay relevant. Yet, leveling up with real-time requires some technical nuances that might be challenging to implement with the current developer skills gap.

According to Manish Devgan, chief product officer at Hazelcast, the problem with most data management techniques is that data isn’t being processed in-stream at the edge. Instead, data gets stored and thrown into a data lake where it accumulates, unfulfilled. To make matters more complicated, decentralized data management means organizations may be overseeing many different data lakes, adding to the potential for unused data and increased latency.

I recently met with Devgan to learn how in-memory stream processing goes beyond real-time data. According to Devgan, the secret sauce is processing incoming data in-stream while tying it to persistent storage to create context. By doing so, companies could unlock more innovative real-time experiences, he said.

Use Cases For Real-Time

Real-time presents many opportunities for business operations and end-user customer engagements. This is especially true in the financial sector. For example, Devgan explains how one bank was able to use real-time data at the moment of customer interaction at their ATMs. The system was able to fetch a history of the user account and extend an offer for a low line of credit, increasing their total loans by 400%. Capturing value at the moment of user intent is a golden opportunity, said Devgan.

Capital One is another example of a financial institution leveraging advanced technology to improve the product experience. “They’re one of the leading banks in terms of technology,” said Devgan. Capital One’s threat detection system calls a machine learning model in real-time to detect and prevent fraud. Only by acting on incoming data in the moment of interaction can preventative responses like these be signaled.

Other scenarios are also beginning to incorporate increased real-time analysis. “This split-second preemptive decision-making is important for many other use cases,” said Devgan. Physical retail might loop into customer loyalty programs at point-of-sale systems to increase in-store spending. Or, automobile manufacturers may want to use real-time processing to detect a problem with their robotic arms sooner rather than later.

Real-time vs. Stream Processing

When an event comes in, it usually has very little information. But when you look up a customer profile and connect it to a greater context, you can direct further actions. “Correlating data in motion with data at rest is where the magic happens,” Devgan. This distinction uncovers the difference between real-time data and stream processing.

The real-time label tends to get thrown around a lot, and it’s quantified differently for different groups. Real-time might be five minutes for some applications but 10 milliseconds for others. Real-time could simply mean that a system accesses data at rest very quickly, delivering perceivably “real-time” results.

On the other hand, stream processing incorporates data at rest and data in motion. It computes incoming, in-stream data and correlates it with data at rest. “You don’t let the data land — you process it as it comes in,” Devgan said.

For years, enterprises have been collecting and storing exorbitant amounts of data. A survey by Seagate and IDC reveals that 43% of data collected is largely unleveraged and other studies estimate the amount of this “dark data” is over 50%. And, not acting upon data effectively makes it just another pile on top of the growing mountain of technical debt.

There is a significant storage expense for holding on to too much data, whether on-premises or in the cloud. But, the paradigm is shifting a bit, said Devgan. Organizations don’t want to hold onto everything. The attitude is beginning to shift toward “garbage in, garbage out.”

Technology Behind Real-Time Processing

So, what sort of technology does stream processing require? Processing data at the edge requires some fundamental changes to design thinking. For one, since data must be computed in-stream, there’s more emphasis on in-memory processing. Devgan explained this as “pushing compute around instead of pushing data around.” To enable this, Devgan pointed to open-source projects like Jet that provide powerful distributed batch and stream processing.

SQL has a storied history of acting upon data at rest. Now, Devgan said, he noticed the reemergence of SQL in a stream processing context. Though the industry is still defining how the SQL dialect will conform in a streaming world, he’s bullish on the prospect of SQL guiding this area. “Streaming SQL will be the lingua franca for streaming,” he insisted. We’re also in an early era of determining how to bridge the stateful and serverless worlds, Devgan added.

But regardless of computing location, it will come down to the net customer experience outcomes. “People want to build their business applications and are less worried about the operational management of the system,” said Devgan. Whether it’s building real-time offers for e-commerce or implementing fraud detection, it will come down to the numbers. There is also a role for stream processing in health care to optimize physical resources and enhance patient experiences with real-time data. In all these scenarios, rapid access to data and processing at the edge will determine much of their success.

February 8, 2022
Database Virtualization: Breaking Vendor Lock-In

Every enterprise is battling vendor lock-in—constantly. Ask any IT leader about what keeps them up at night and vendor lock-in is certainly near, if not at, the top of the list. And while network, storage and compute have long been democratized by virtualization, one discipline has held out as the last bastion of vendor lock-in: Databases.

How bad can it be? Take Amazon, for example. They celebrated their retirement of the last internal Oracle database exuberantly. People familiar with the matter suggested that replacing Oracle was at least a decade in the making, probably longer. It is anybody’s guess how much effort it took to accomplish this feat. A big celebration was in order, indeed.

Now, let’s take a look at database virtualization. As a relatively new discipline, the idea of virtualizing critical systems like data warehouses made a big splash recently. But does it apply to your systems? And the ubiquitous question: Does it come with performance penalties?

What Is Database Virtualization?

Database virtualization is the concept of abstracting applications and databases from each other. Using virtualization, an application written for, say, an Oracle database can run on an open source database like PostgreSQL without making changes to SQL or to associated APIs. As an aside, this is not to be confused with data virtualization—which is really a data integration play.

A database virtualization platform translates queries and data in real-time. Through emulation, it bridges functional gaps between the source and destination system so applications remain unchanged while moving to a different database. Database virtualization doesn’t make migrations easier; it makes them effectively obsolete.

The idea is rather compelling. So much so that Amazon developed and released their own version of a database virtualization product recently that targeted small standalone database systems.

Why You Need Database Virtualization

Here’s a simple rule of thumb. The cost of migrating a typical data warehouse—without virtualization—is about the total cost of the database over the next five years. So, if your current data warehouse runs you, say, $5 million a year, (which is typical for a mid-range system) your cost to migrate it will probably be close to $25 million. Moreover, the project could take up to five years.

But wait; there’s more. The true downside of conventional database migrations is actually their abysmal failure rate. Analysts put it typically above 80%. For large data warehouse systems, it seems to be higher still. That’s what makes databases the ultimate bastion of vendor lock-in.

As an IT leader, you naturally don’t have the time, the budget or the appetite for such a risky undertaking; you’d probably rather deploy that kind of money toward creating new revenue. Database virtualization lets you do just that: Sidestep these risks and, instead, focus on what’s really relevant.

When to Use Database Virtualization

Database virtualization is particularly suitable for replatforming data warehouse workloads. These workloads are notorious for their complexity and for the effort a rewrite would entail. Often, these workloads have been grown and curated for years—sometimes decades. Maintaining the workload while replatforming makes economic sense: It means preserving and protecting long-standing investments.

However, for database virtualization to be successful, both the source and destination systems need to be of comparable performance and scale. This should be obvious: Moving a workload from, say, a Teradata system to a Postgres instance is unlikely to satisfy your business users.

But there is good news. Over the past few years, cloud data warehouses have increasingly reached competitive performance targets. They have become viable alternatives to legacy on-premises appliances. From an IT leader’s perspective, that is great timing. Most IT leaders today are currently tasked with sunsetting these appliances over the course of the next few years. Database virtualization couldn’t be any timelier.

Goodbye, Vendor Lock-In

Virtualization, as a general concept, has revolutionized the IT stack over the past 20 years. Server virtualization, which started as a niche for QA and developers, became the foundation of cloud computing; virtualization then spread to network and storage. Databases are one of the few remaining disciplines that have bucked the virtualization trend—until now.

Not surprisingly, the premise of database virtualization resonates greatly with practitioners. And even though the initial success in the data warehousing arena is yet to be replicated in other areas, it seems like it’s just a matter of time before the concept becomes ubiquitous.

February 3, 2022
App Store Antitrust Bill | GDPR vs. Google Fonts | Wordle Worth $1M+

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: The Open App Markets Act polls well among devs, Germany fines a website for using Google Fonts, and the New York Times buys Wordle for an unfeasible sum.

1. Antitrust Bill Would Open Up App Stores

First up this week: The Open App Markets Act seems like a big hit with developers. In a survey, more then 80% wanted lawmakers to pass this bipartisan Senate bill.

Analysis: But 30% of nothing is nothing

One of devs’ biggest complaints is Apple’s 30% cut of all revenue—including in-app purchases. Many devs have also experienced random rejections of submissions to the stores. And these seem to be the main driving forces behind devs’ calls to tear down any walls around the gardens. But they should be careful what they wish for—users might not see it the same way.

Karl Evers-Hillstrom: 8 in 10 app developers back measure to rein in Google, Apple

The Coalition for App Fairness, [an] industry group for app developers, is pushing Congress to pass the Open App Markets Act. [The] bipartisan Senate bill … would block app stores from favoring their own in-house apps in searches, requiring developers to use their payment systems and preventing users from downloading apps from third-party stores.
…
Developers surveyed … complained about exorbitant fees … and expressed how they’d experienced difficulty getting their apps featured or accepted by app stores. Just 13 percent of app developers surveyed oppose the bill. … The margin of error is plus or minus 7.11 percentage points.
…
The proposal, co-sponsored by Sens. Amy Klobuchar (D-Minn.), Richard Blumenthal (D-Conn.) and Marsha Blackburn (R-Tenn.), is scheduled for a committee markup this week. The CEOs of Apple and Google have personally lobbied lawmakers to abandon [such] antitrust legislation.

Wouldn’t that just kill the proverbial golden goose? No, says this Anonymous Coward:

The only reason Apple has any success with the iPhone is because developers write apps for it, it’s no different to Windows in that regard. … If Apple’s app store is so good then everybody from developers to end users will continue to use it and nobody will use third party app stores.
…
Obviously there is a clear profit motive to exclude any competition in the app store space. But I don’t understand how people can claim that Apple makes great products and simultaneously argue that they couldn’t possibly survive competition on the platform.

But Dr. Edith Müdyk—@BabyHueby—doesn’t sound hopeful this will go anywhere:

Too bad policy isn’t dictated by public opinion.

2. German Court Fines Site for Using Google Fonts Without Consent

Did you know you need to get permission from a European user before you remote-load a Google Font? You do now.

Analysis: Schrems II comes home to roost

More GDPR popups ahoy! A German court has “clarified” that websites and apps should obtain informed consent before loading content—if loading it would reveal a user’s IP address to a third party. Luckily, the fine was only $110—this time, but if the perp was to do it again, the court threatened 2500× that amount.

Thomas Claburn: Website fined by German court for leaking visitor’s IP address via Google Fonts

A German court fined an unidentified website €100 ($110) … for violating EU privacy law by importing a Google-hosted web font. [It] passed the unidentified plaintiff’s IP address to Google without authorization and without a legitimate reason for doing so. And that violates … GDPR.
…
The website could have avoided this drama by self-hosting the font. … The ruling explicitly cites this possibility to assert that relying on Google-hosted Google Fonts is not defensible under the law.
…
The ruling directs the website to stop providing IP addresses to Google and threatens … a fine of €250,000 for each violation, or up to six months in prison, for continued improper use of Google Fonts. … These data privacy judgments … reflect the consequences of the EU Court of Justice’s 2020 decision to strike down the Privacy Shield data protection arrangements that had previously allowed US companies to exchange data with European partners under “Standard Contract Clauses.”

Isn’t that ridiculous? And surely not the intention of GDPR? Aristos Mazer very much disagrees:

This is very much the intended consequence, with a lot of analysis going into this regulation. … Even if that means redesigning foundations of the network.
…
Forcing sites to stop transferring data in any way shape or form to Google, Apple, Microsoft, Facebook, etc. … is exactly the goal. [It’s been] repeatedly validated by polls of EU citizens.

And indeed, the point is to get “informed consent.” Here’s Hans Neeson-Bumpsadese:

“To proceed beyond this point … your IP address needs to be shared with a 3rd party.” Would they click on that? … I know at least one person who would read that as, “If I click that link then you will tell people where I live.” (I know because they got a pop-up like that once, and phoned me in a state of mild agitation.)

3. Wordle Sold to NYT for Over $1M

Josh Wardle, a Welsh developer living in New York, has sold this winter’s social gaming hit to his state’s namesake newspaper of record. The New York Times thinks it’ll be a useful addition to its Games section. But the price tag is incredible.

Analysis: Nice payday for Josh

How much? Hard to see how the Times is going to make money out of this. Tomorrow’s word must be: NOROI.

Alexis Benveniste: The Sudden Rise of Wordle

In less than six months, Wordle has gone from a gift to a viral sensation, to … part of The New York Times. … Josh Wardle, a software engineer in Brooklyn, created the game as a gift for his partner … and it exploded in popularity.
…
Nearly two months later, 300,000 people played it. … The buzz around the game can be attributed to the spoiler-free scoring grid that allows players to share their Wordle wins across social media.
…
Wordle was acquired for an undisclosed price in the low seven figures.

In other words, north of $1 million. Not bad for a quick, one-dev hack by Josh Wardle:

The game has gotten bigger than I ever imagined (which I suppose isn’t that much of a feat, given I made the game for an audience of one). … I feel so grateful for the personal stories some of you have shared with me.
…
[But] I’d be lying if I said this hasn’t been a little overwhelming. [So] I am incredibly pleased to announce that I’ve reached an agreement with The New York Times. … I’m thrilled they will be stewards of the game.

But “RIP Wordle,” mourns _xeno_, seemingly speaking for many:

It’s about to be bogged down with trackers, and then later, ads. … A paywall is almost certainly on its way—The New York Times very carefully said it would “initially remain free.” … Not surprisingly, there are already plenty of clones. … There’s no way for the New York Times to make money off this.

The Moral of the Story: No disguise will hide one’s true character.

You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

Image: Masahiro Miyagi (via Unsplash; leveled and cropped)

February 1, 2022
Google FLoC is Dead | Meta AI Supercomputer Lives | ARM Deal is Dead

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Google’s FLoC proposal is dead, Meta/Facebook is buying RSC—a huge AI supercomputer, and Arm “will IPO” instead of selling to Nvidia.

1. Forget ‘Federated Learning of Cohorts’—Long Live ‘Topics’

First up this week: Google bows to the inevitable. Third-party cookies will soon go away, because people are fed up with being tracked. But Google’s FLoC proposal wasn’t the answer.

Analysis: FLoC is a flop

Google doesn’t want to invade your privacy. But Google does want to sell well-targeted ads. The key difference between FLoC and Topics is that FLoC buckets were automatically generated—and hence opaque, risking overlap with “protected categories”—e.g., race or gender. But the topic classifications in the Topics API are curated and have user-visible, descriptive names.

Frederic Lardinois: Google kills off FLoC, replaces it with Topics

Google’s controversial project for replacing cookies for interest-based advertising … is dead. In its place, Google today announced a new proposal. … Your browser will learn about your interests as you move around the web.
…
When you hit upon a site that supports the Topics API for ad purposes, the browser will share three topics you are interested in. … The site can then share this with its advertising partners to decide which ads to show you. … Users will be able to review and remove topics from their lists [or] turn off the entire Topics API.
…
It’ll remain to be seen if other browser vendors will be interested in adding the Topics API. [But] they all quickly turned a cold shoulder to FLoC. … The plan is to start trialing the Topics API at the end of this quarter.

A minor tweak and rename? “Yes and no,” equivocates mananaysiempre:

Yes, it still amounts to building user-tracking functionality into user agents. No, it’s not the same approach.
…
FLoC was doing unsupervised clustering of users, whereas Topics allocates users into predetermined clusters. This makes it potentially more transparent and also seems designed to work around the “protected categories” objection.

But Google has a long way to go to convince garett_spencley:

I’m glad FLoC is being ditched, but as an end-user I’m still not asking for this Topics nonsense. It doesn’t solve any problem that I have. It solves problems that the advertising industry has.
…
I’ll choose to use browsers that don’t support this.

2. Machine Learning at Metaverse Scale is Expensive

Zuckerberg’s new toy is RSC: A $400 million Nvidia-based AI supercomputer. And that’s just Phase One.

Analysis: 3.8×10¹⁸ integer operations per second is … a lot

If you rely on Open Compute Project systems for your DevOps, know that it’s no longer the bee’s knees over at Hacker Way. Meta/Facebook is investing eye-watering sums into a custom configuration of off-the-shelf hardware.

Timothy Prickett Morgan: Meta Buys, Rather Than Builds And Opens, Its Massive AI Supercomputer

If you thought it took a lot of compute and storage to build Facebook’s social network, you ain’t seen nothing yet. … To build the Metaverse … is going to take an absolutely enormous amount of supercomputing power.
…
But what is a surprise, given Facebook’s more than decade long focus on … opening up its hardware designs through the Open Compute Project, is that the … Research Super Computer [RSC] system is built from … commercially available … servers, storage, and switches. [It] probably comes down to … working a deal with some vendors who want the Facebook publicity and are willing to work the price and the parts availability.
…
[So Meta bought] 760 DGX A100 systems from Nvidia—which each … have a pair of AMD “Rome” 64-core Epyc 7742 processors … 1 TB of main memory … eight A100 GPU accelerators [and] eight 200 Gb/sec HDR InfiniBand controllers—all-flash storage from Pure Storage, and … caching servers from Penguin Computing. … At list price this machine would cost around $400 million … Phase one of the RSC machine is rated at 59 petaFLOPS … (FP64), and 118.6 petaFLOPS FP64 using the Tensor Core matrix engines. … With INT8 processing on the Tensor Cores, which is needed for AI inference, the phase one machine is rated at 3.79 exaOPS.

How much??? It doesn’t seem like news to kleiba:

I used to work at a university where my professor had been in automatic speech recognition for a long time, but basically gave up on that line of research about 10 years ago because he figured that universities simply cannot compete budget wise with the big industry players. I suppose the same will soon be true for most ML-related areas of research sooner or later.
…
Already, a substantial amount of research innovation in [Natural Language Processing] and [Computer Vision] has been coming from big companies in recent years. Of course there is a discussion to be had about what that means for society at large.

But 3.79 exoOPS? That’s the way the wind is blowing, according to sungazer:

Give it 15 or so years—this level of computation will be on your desktop. If desktops still exist.
…
Or desks.

3. Arm Bid: No Legs

Speaking of Nvidia, as I’ve said before, the Arm merger really shouldn’t go through. And it’s looking less and less likely. ARM chips are an increasing fixture in the data center—especially those that value “performance per Watt.”

Analysis: ARM M&A DOA—IPO PDQ

A veritable hornets’ nest of Bloomberg journalists have put their names to an anonymously-sourced report. The story argues that the proposed Nvidia buyout of Arm from SoftBank Group is dead. Next stop: IPO.

Ian King, Giles Turner, Peter Elstrom, Dina Bass, David McLaughlin, Ruth David and Dinesh Nair: Nvidia Quietly Prepares to Abandon … Arm Bid

According to people familiar with the matter … Nvidia … doesn’t expect the transaction to close. … SoftBank, meanwhile, is stepping up preparations for an Arm initial public offering.
…
If Nvidia manages to get the deal over the line, it would be a massive coup. … But it will be an uphill fight. … The world’s biggest tech companies rely on Arm technology, and they fear they could lose unfettered access under Nvidia.
…
Within SoftBank, there are factions. [And] the ordeal has created divisions within Nvidia. … “We remain hopeful that the transaction will be approved,” a SoftBank spokesperson said in an emailed statement.

Post-Brexit Britain would no doubt like to keep Arm independent. Here’s simonh:

Arm has I think ⅔ of its employees in the UK—mainly Cambridge—and they’re expanding the campus there. The Semiconductor Physics Group at the Cavendish Laboratory at the University is at the cutting edge globally with 18 PhD projects currently.
…
Guess where scads of Arm’s top scientists are recruited from? Arm and the University are joined at the hip. That company’s not going anywhere.

More broadly, it’s good news, thinks hatchet:

Hopefully this means NVIDIA will focus on RISC-V instead. This will be good for everyone.

The Moral of the Story: Zeal should not outrun discretion.

You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

Image: Reed Geiger (via Unsplash)

January 27, 2022
The Lego Approach to Overcoming the Developer Divide

As end-user demand for new services continues to rise and businesses adapt to changing times, digitalization has never been more important. Pressure is increasing on organizations to deliver digital transformation initiatives more quickly as 55% of CIOs in 2021 said they were increasing staff to accelerate their digital programs. The cloud is essential for this. Because it can enable new opportunities for revenue and quicker delivery to market, the cloud is the way forward for companies that want digital success. That’s why 95% of those surveyed by Accenture say they’ve adopted advanced cloud services.

However, this is not without its challenges. For one, teams need the skills to match—individuals who know how cloud works and the expertise to unlock its potential. But this is proving difficult as talent remains hard to recruit (a recent Gartner report found that IT executives view the talent shortage as the most significant barrier to deploying cloud, edge computing, automation and other emerging technologies). In addition, as 92% of companies believe DevOps is crucial for revolutionizing their digital strategies, it’s worrying to see a new report from Boston Consulting Group that revealed up to three-quarters of developers are looking to change their jobs within two to three years.

This is something enterprises need to address if they wish to accelerate digital transformation programs and take advantage of the emerging cloud technologies that support the growing need for a distributed cloud architecture. Without the required developer expertise, organizations will fail to address end user expectations and fall behind their rivals.

A Concrete Problem

While the shortage of developers was an issue even before the pandemic, the problem is only getting worse due to the increasing need for digital transformation. It is putting more pressure than ever on existing developers and making it difficult for organizations as they struggle to recruit more talent. In fact, research found that pressure on digital architects has more than doubled during the pandemic, with almost 50% saying they are currently under high or extremely high pressure to deliver digital projects.

This skills shortage is an important issue for companies to consider. It is well-known that the expertise needed to deploy and maintain cloud services differs considerably from what’s needed for on-premises environments. Without those skills, it becomes difficult for IT teams to oversee and understand what is happening with regard to their cloud deployments, and it ultimately hinders organizations from generating new revenue opportunities through increased innovation. Cloud is a whole new world where control and insight are limited, there are new inflexible cost structures to get used to and other departments can easily procure new applications without the IT team’s involvement. However, we still see examples of organizations being tripped up by these differences.

Organizations take proactive steps to keep their developers engaged and happy to avoid digital transformation burnout and ensure they make the most out of their cloud deployments.

One Brick at a Time

One way enterprises can do this is by embracing a Lego approach to their digital transformation journey. By adopting a composable business strategy, organizations are in the best position possible to remove pressure from developers and drive increased innovation with less need for highly specific technical expertise.

When building things with Lego, even if you’re starting without instructions, you don’t need to completely start from scratch—and you can use the same bricks time and time again. Composability, or the notion of building and configuring infrastructure and applications from component parts with well-defined interfaces, means the same is true when developing new digital services. Instead of having to start from scratch each time or write specific code, developers and even business users can quickly innovate new experiences by composing and decomposing existing digital assets and reusing them—just like Lego bricks. In this way, the company is using its existing skillset to the fullest; maximizing the value of its resources and allowing it to concentrate on actually developing new experiences and services.

Perhaps most importantly—especially for developers—this means less pressure on development teams, not only because there’s less need to reskill but because composability means they no longer need to worry about managing underlying infrastructure or reconfiguring physical assets like servers, storage and connectivity. Instead, they can manage all assets through a single unified control plane that spans multiple clouds, right through to the edge.

Making use of Existing Resources

As part of this composable approach, enterprises should also examine how they move away from legacy technology, making sure they invest in innovations that leverage their existing in-house developer expertise. For instance, using a database-as-a-service platform that has the same programming language and tools that developers are already used to will accelerate adoption and reduce training costs.

The move away from legacy technology won’t just increase value for the money at a time when developers are becoming harder to recruit and budgets are tight. It will, again, also make life easier for developers. Instead of having to struggle with the integration of older systems with newer innovations, next-generation technologies will make this process harmonious and easy, further reducing the pressure and speeding up digitalization.

Creating a Solid Foundation

The developer divide is an issue that organizations need to take seriously if they wish to drive forward their digital transformation initiatives. At a time when demand for improved end user experiences is high, the need for developers has never been greater.

While recruitment and retention remain a challenge, the Lego approach of composability means enterprises do not need to lose out. Using the existing skills and resources of a company, composability propels faster innovation and greater agility.

January 27, 2022