devopsy.kinsta.cloud

Category: DevOps Culture

How Test Automation Can Help Drive DevOps Success

Testing can be one of the more time-consuming aspects of the DevOps process. It can be exhaustive, frustrating, requires a lot of hands-on labor hours and people seldom enjoy it. But testing is vital, and no developer should simply skip it.

Recently, a strong trend has emerged wherein DevOps experts encouraged developers to automate their testing procedures. Test automation can bring your DevOps projects to the next level, save time and maximize pipeline capacity for continuous testing.

Test Automation: Definition and Benefits

Test automation minimizes the amount of human labor required in testing. In test automation, tools and frameworks write testing “scripts” that work to ensure the high quality of your application.

DevOps can use test automation in a variety of different ways–it can even take advantage of test cases and detect bugs in your code. This automatic testing procedure speeds up the process, getting your product to the market much more rapidly. The automatic quality checks can also practically eliminate the risk of human error in the process of continuous testing.

Test automation can also ease the burden of the repetitive nature of some DevOps testing, simplifying and speeding up the process significantly. Finally, automation promotes a high degree of reliability throughout your testing process. Test automation can also optimize your process.

Test Automation in the Context of DevOps

DevOps is all about continuous development—the product is created, deployed, tested, and sent out to be consumed by the end users.

Since it came on the scene, quality assurance (QA) has gained importance. The traditional approach to QA (wait until the product deployed to go through regression and functional testing) was much improved with the advent of DevOps. DevOps integrates the QA team into the whole of the development process, merging all players into a unified team. This integration requires a great deal of coordination across the different stakeholders.

This also allows for a high degree of agility and speed in the process, speed which the DevOps methodology then magnifies through a high amount of automation in continuous testing (which can then be configured to run automatically).

Deciding on the Best Tools for You

To build up an effective test automation process, you must find the right software workflow tools for you and your DevOps team. These tools should support and manage your test assets from a central location, passing your product through the testing process much more quickly and maximizing efficiency. That said, as helpful as having an automated testing process can be to enhance the efficiency and effectiveness of your software, using tools that don’t fit with your team and goals will present potentially significant problems for your organization. There is a staggering array of test automation tools available on the market, and they all have their strengths and drawbacks. No single tool will satisfy every need related to automated testing, so your goal needs to be to find the ones that will work the best with your unique needs and desires.

What to Keep in Mind When Choosing a New Tool

Cost (for both licensing and support): Budget is an eternal tyrant, and your team needs to go into this procurement work with a solid understanding of your financial limits. If you have stringent limits there, there are some types of open source software like Selenium that could be useful. These tend to require a substantial degree of technical skill, so they may not be as helpful for you—if that’s a weakness of your team.

Type: There are several different types of DevOps testing tools. Language is one of the more important factors when deciding on one–make sure the tool operates in either the same language as your application or at least one in which your team can efficiently operate. The intended platform for the tool is also notable, as is the intended audience (i.e. whether the product aims more towards developers or testers).

DevOps integration support: It’s always important to double-check that your tool supports both DevOps tool integration and continuous integration. If you don’t effectively coordinate your tools, it will undoubtedly slow down your process.

Training: Depending on the level of expertise within your DevOps team, you’ll need to ensure that there is an appropriate degree of training on how to use the team—for the people who will be using it.

Quality test reports: Test reports with both depth and breadth are crucial to success in continuous testing. These help notice defects and their root causes, then allow you to test the effectiveness of your analysis.

Excellent customer support: You will want to use a tool that will serve your needs well. That means a tool that understands your specific situation and can help you work through complications.

The Necessity of Automation Skills

All of this aside, you cannot just rely on the strength of your test automation tools to get you through the testing process. If you decide to implement test automation without having people on your team with the skills to manage it, you may end up in a challenging position riddled with inefficiency.

Here’s what you need from a test automation software engineer: They must have a broad base of knowledge that encompasses test automation tools. Beyond that, they need to understand how to dive deep into software testing functionality and the technical complexities that undergird the project. They should also know how to write scripts alongside development, collaborating with both operations and development teams. That collaboration between test automation, development and operations will have a deeply important role in writing test scripts and maximizing the coverage of your tests.

A test automation software engineer’s skills offer invaluable stability. Indeed, tools are often built on a foundation of skills. If you have a resourceful and capable software engineer on hand, you’ll be much more prepared for the fluctuations of the market than if you’re relying on a single tool. If you decide to focus on only one tool, your team risks limiting itself and potentially falling behind the times and needs of your customers.

The Dangers of Automation

Automation is one of the foundations of DevOps’ success. But even so, you must strike a delicate balance. If you automate too much, you may end up hurting your product.

When you start connecting too many different tools to your project, you begin to risk unwanted outcomes that practically cancel out the investment you made in DevOps in the first place. If you try to automatically test things that automation can’t effectively measure (general user experience, for example), you’ll end up with worthless data. Your various automation tools can start to create more work than they’re resolving if you need to spend a great deal of effort in managing them.

That said, if you under-automate, you’ll be losing out on workflow efficiencies that your competitors are using, making your team less competitive. Thus, it’s necessary to try and balance the two. The first step to striking this balance is having a thorough understanding of your requirements vis-a-vis testing, development and deployment. If you have that under your belt, you can find the automation tools that work best for your goals. Once you have the right combination of automation tools, you’re golden.

Also, test automation doesn’t negate the need for manual testing—and it isn’t designed to. Of course, certain kinds of manual testing can be eliminated by automation (especially the repetitive kinds).

But you still need manual testers behind the wheel examining your product more thoughtfully and at a deeper level than an automated program. That deep-level variety of manual testing can often discover issues that automatic testing failed to see. It can also provide a more thorough level of insight into the user experience that automatic testing will seldom be able to provide.

Benefits of Test Automation

We’ve covered a lot of deep ideas in this piece. But at the end of the day, test automation is beneficial for a few simple reasons: it reduces human error, simplifies your tests, allows you to deliver products much more quickly and leads to a much more reliable quality assurance structure.

That said, test automation won’t be a panacea for all your team’s ills. It will work, but only if you’ve chosen the right tools and you have people on your team with the skills to use them effectively. Once again, don’t rely on continuous automated testing as the be-all and end-all of your quality assurance practice. Several QA questions show that a human presence is much better at resolving certain types of problems and over-automating can cause significant inefficiencies.

Test automation can be a wildly useful tool if you use it well. These tips will help you take your organization to the next level of efficiency and excellence.

January 19, 2022
Infrastructure as Code (IaC): Why Collaboration Is Key

Infrastructure as Code (IaC) is an essential DevOps practice that allows developers and operations teams to automatically manage and provision the infrastructure through code, instead of making configuration changes through a manual process. IaC provides transformational agility and can significantly speed delivery, reduce costs and help mitigate risks.

However, when people talk about IaC, sometimes they forget to mention its main ingredient: collaboration. The whole purpose of IaC is to enable infrastructure and software development teams to collaborate.

“It (IaC) is about making operations more developer-like,” said Rob Hirschfeld, co-founder and CEO at RackN, a software automation company that specializes in making IaC collaborative for teams, tools and tech.

Rob will be joining the Predict 2022 speaker lineup to talk about Infrastructure as Code and DevOps. During his session, “Adding IaC’s Missing Ingredient: Collaboration,” Rob will discuss how to help operations teams become more collaborative and a cohesive part of the business, and how IaC helps create and reuse automation within the system.

Rob will take a look at the future of IaC, what’s in store for infrastructure and operations teams in 2022 and share his own predictions.

During a quick interview with our very own Jackie Whetzel, Rob gave us a sneak peek of his session and shared one of his predictions for 2022.

“People are increasingly nervous about complexity but they can’t define it, that’s what makes it so cloudy,” said Rob. “The number one thing we really need to start doing is figuring out how to talk about complexity and how to manage and tame it. And I’ll give you a sneak peek. Come to my presentation, we’ll talk about using collaboration and teamwork and pipeline as ways to tame that complexity.”

Predict 2022, taking place Jan. 19-20, is a free virtual event featuring educational presentations that explore the trends, technologies and looming topics that could have the most impact on technology in this new year. Internationally recognized industry leaders, such as Rob, will share their speculations on what the future holds in the realms of DevOps, cybersecurity, digital transformation, cloud-native and IT.

To check out the full agenda and to register, please visit the Predict 2022 website.

January 17, 2022
EEEWW—Green iMessage Bubbles | ‘Great Resignation’ Redux | Faster Firefox 96

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: iMessage lock-in lessons, attrition-rate fixes, and more on Mozilla.

1. ‘Never Date a Green Texter’

First up this week: The weekend story getting the technorati chattering was about how Apple iMessage denizens pour scorn on Android users—identifying them by their “icky” green chat bubbles. An iPhone user’s message gets a “proper” blue background, y’see.

Amusing though the story was, the writer seemed to be hell-bent on proving some sort of Apple C-suite-led “conspiracy to lock in.” The reality is far more mundane—but it teaches important lessons for DevOps.

Analysis: Unintended consequences FTW

Could your DevOps team make a trivial engineering decision that pays unexpected dividends? While lock-in might be distasteful, seemingly irrelevant design or technical choices can have huge ramifications with users.

Tim Higgins: Why Apple’s iMessage Is Winning

[The] pressure to be a part of the blue text group is the product of decisions by Apple executives starting years ago that have … helped to cement the iPhone’s dominance among young smartphone users. [It] encourages people to pay the premium … and remain loyal to its brand.
…
Teens and college students said they dread the ostracism that comes with a green text. The social pressure is palpable. … Jeremy Cangiano, who just finished up his MBA, … tried to cash in on it last year by selling his own merchandise that touted, “Never Date a Green Texter.”
…
The blue iMessage bubble was born out of a simple engineering need, according to Justin Santamaria, a former Apple engineer who worked on the original feature. … The idea that it would keep users locked in to using Apple devices wasn’t even part of the conversation at the time, he said.

And then the other shoe dropped—via Ron Amadeo:

Google took to Twitter this weekend to complain that iMessage is just too darn influential with today’s kids. … The company is hoping this public-shaming campaign will get Apple to change its mind. [But it] probably has the least credibility of any tech company [because it] has released 13 half-hearted messaging products since iMessage launched in 2011.
…
Google … seems to have learned nothing from its years of messaging failure. Today … the situation is an incredible mess, and no single Google product is as good as Hangouts was in 2015.

Ouch. With a sociological perspective, here’s Christina “filmgirlcw” Warren:

iMessage is incredibly popular with certain demographics. … It’s an in-group signifier—the way teens have always had in-group signifiers (when I was in high school, it was AIM, a Nokia, and wearing Abercrombie). … It’s always fascinating for me to go to other countries and see a ton of iPhone users not using iMessage but something else because that app has become the in-group signifier. … Every teen I know uses Discord more than they use almost anything else.
…
It isn’t about lock-in or regulation or technology. It’s about fashion.

2. How’s your Attrition Rate?

A study published this week says DevOps orgs and other internet companies rank third for attrition in the 38 industries surveyed. And if you lump that category together with “enterprise software,” it would be in clear first place.

Analysis: We’re #1! Oh, wait …

But some companies get this right—how can you be one of them? Culture, innovation, recognition and remote work. It’s definitely not only about pay.

Donald Sull, Charles Sull and Ben Zweig report their fascinating study: Toxic Culture Is Driving the Great Resignation

Between April and September 2021, more than 24 million American employees left their jobs. [But] while resignation rates are high on average, they are not uniform … from less than 2% to more than 30%. … More-innovative companies … are experiencing higher attrition rates than their more staid competitors.
…
Pay has only a moderate impact on employee turnover. … A toxic corporate culture is by far the strongest predictor of … attrition and is 10 times more important than compensation. … Job insecurity and reorganizations are important predictors of how employees rate a company’s overall culture. … But it is surprising that … the more positively employees talked about innovation at their company, the more likely they were to quit. … Employees are more likely to leave companies that fail to distinguish between high performers and laggards [or] that tolerate underperformance.
…
Our analysis identified … actions that managers can take … to reduce attrition. … Lateral career opportunities are 12 times more predictive of employee retention than promotions [and] 2.5 times more powerful [than] compensation. … Company-organized social events, including happy hours, team-building excursions [and] potluck dinners … are a key element of a healthy corporate culture. … Unsurprisingly, when employees discussed remote work options in more positive terms, they were less likely to quit.

And the flipside of resignation? Hiring replacements. Let’s turn to the equilibrium of Nash Reilly:

It’s only gotten harder in recent months [and] I think I know why. … You need to offer engineers some combination of these three things to pique their interest: Cool stuff to work on, smart people to work with [and] some degree of repeatability.
…
You can’t really prove to an engineer that you can give them things like good management, minimal churn, and decision making authority [so] let them talk to your employees. … Also, figure out a way to let your team “backchannel” to the candidate. [If] your product is not that cool … play up the things you can offer them: smart coworkers, and a stable working environment. … You can afford to be honest about what it is that you do offer to a candidate, [so] pitch them the truth: that you want to do good work, sustainably, for as long as you can—ideally with them on your team.

Perhaps the smart money is already skating to where the puck will be? Here’s echelon:

Engineering salaries are … one of the biggest expenses. … Companies love that they can now hire remotely and pay adjusted cost of living. They’ll hire as many workers in middle America as they can, and once enough of the workforce is concentrated outside of expensive cities, you’ll see them stop hiring in SF and NY entirely. [And] startup capital is already beginning to shift to … emerging markets. Employment will eventually head there too.
…
Make your money now while the iron is still hot.

3. Say Something Nice About Firefox

After accusing Mozilla of jumping the shark last week, perhaps I owe the Firefox folks a positive inclusion this time? The release notes for Firefox 96 certainly sound good.

Analysis: Improved sound; better perf; stronger anti-CSRF

Outside the Apple walled garden, Firefox is about the only non-Chromium browser. A browser monoculture can’t be a good thing for anyone—not DevOps nor users.

Michael Gariffo: Firefox 96 update focuses on noise improvements, main thread efficiency

On the desktop side of things, Mozilla’s latest release made “significant improvements” to the browser’s built-in [sound] noise suppression and auto-gain-control features. These improvements are aimed at web-based video chat users.
…
The second tentpole feature in version 96 focuses on reducing main-thread load, which should help the browser function better on older, slower, or congested systems. [And] a new enforcement setting for cookies … will, by default, apply the “Same-Site=lax” policy. Mozilla claims this will help better defend users against Cross-Site Request Forgery (CSRF) attacks.
…
Mozilla also acknowledged that it is working on correcting the performance of detached videos being played in full screen on macOS devices. … No timeframe was mentioned for when it might be available again.

Okay. Sounds good. But not to Tetch:

Never mind all that fancy stuff. … Any reduction in crashes?
…
FF crashes for me several times a month. … I always take the trouble to fill in the “What were you doing immediately before the crash?” section of the crash submission dialog, and never hear another thing.

But more efficiency on the main thread? Tell me more. ksec:

Such an important detail that deserves at least few more sentences of marketing message or explanation. But the whole release note just feels like they couldn’t be bothered anymore.

The Moral of the Story: A weasel wishing Happy New Year to a chicken harbors no good intention.

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

Image: Moritz Knöringer (via Unsplash)

January 13, 2022
Continuous Delivery Challenge Looms Large in 2022

As 2022 kicks off, it’s becoming apparent that the major DevOps challenge organizations will face is mastering best practices that enable continuous delivery.

A global survey of more than 19,000 software development professionals conducted by the Continuous Delivery (CD) Foundation found 44% of respondents use either continuous integration or deployment. However, less than one in five (18%) use both practices to automate the entire software delivery life cycle. Continuous integration is currently the most popular DevOps-related activity (32%) followed by continuous deployment at 29%, the survey found.

The survey also found that only 14% of respondents said, on average, that they can go from code checked-in to successfully running that code in production in one day. Just 10% said they routinely deploy code to production each day. Nearly a third of respondents said they still manually approve code deployments to production.

Tracy Miranda, executive director for the CD Foundation, said it’s clear there is a need for a better understanding of continuous delivery as a distinct DevOps discipline that stands apart from continuous integration processes. While the two DevOps practices are complementary, she noted that continuous delivery requires a level of engineering expertise that many developers either lack or are simply not interested in gaining.

In fact, the survey found more than a quarter of respondents (26%) are not involved in DevOps-related activities at all. At the same time, however, the survey revealed that 80% of respondents that work for companies with two or more employees are involved in DevOps to some degree. Nearly 60% of enterprise developers that participated in the survey employ a continuous integration/continuous delivery (CI/CD) platform, as opposed to 48% of developers working in small businesses and 42% of contractors. However, it’s clear from the survey results that much of that activity is focused on continuous integration rather than continuous delivery.

The survey revealed, for example, that less than a quarter of respondents (23%) are involved in infrastructure provisioning and management at all. That compares to nearly a third (32%) that are involved in application and infrastructure monitoring. Only 20% are involved in creating automated tests, Collectively, the survey results make it clear there is still a long way to go in terms of shifting responsibility for DevOps practices further left toward developers.

One reason continuous delivery is so challenging is that automating deployments across platforms has never been especially easy. Each platform tends to be customized to the point where it is difficult to automate application deployments. In effect, each platform is its own unique type of “snowflake.”

However, with more attention focused on the integrity of software supply chains in the wake of a series of high-profile breaches, Miranda noted that automating software delivery will play a major role in achieving automation goals by reducing the need to rely on manual processes that are more easily compromised.

At the same time, more organizations are starting to embrace Kubernetes clusters—this can simplify automation of software delivery across a set of platforms that all share a common application programming interface (API), she noted.

The growing complexity of application development projects, coupled with increased reliance on software to drive digital business transformation initiatives, will also accelerate the adoption of continuous delivery best practices, added Miranda.

One way or another, application deployment in 2022 is shaping up to be a lot more automated than it was in previous years. The only thing left to be determined now is the degree to which that goal can be achieved.

January 12, 2022
Shift Left: Right or Wrong?

The term DevOps emerged into mainstream software development communities roughly 10 years ago. It represented a combination of tools and techniques which helped solve many pertinent issues of the time, namely responsibility for code in production and lack of a positive feedback loop. As of today, DevOps is a massive movement. It is considered the default way in which software development should be practiced. It has allowed even small teams to function with the same efficiency as much larger ones. Several engineering teams have adopted derivative approaches of the DevOps methods in order to suit their niche workflows.

The Dark Side Of DevOps

DevOps in practice presents a lot of tangible benefits to software engineering teams. Automation, transparency, and velocity are the chief advantages. From a business perspective, engineers are now more invested and accountable for the experience of users. The era of “Your Success Is Our Success” has finally arrived for engineers—and business teams couldn’t be happier.

For the individual developer, the number of things they were responsible for was piling up. More objects to monitor in production. As more features were getting built and deployed, alarms from internal systems kept going off more frequently. Individually, an engineer became responsible for the behavior, performance, security, compliance and so many other aspects of the application and underlying systems. Often, this became a distraction and began to defeat the very purpose of the DevOps methodology which meant to remove hurdles that were in the way of developers.

This is DevOps done wrong. Lack of maturity within software engineering teams has caused a lot of people to go down a DevOps path that is toxic and consequently forced engineers to burn out quickly. The core tenet of DevOps is to enable engineers to do more, but not to the point where they’re having to undertake enormous toil. DevOps still recognizes two distinct forms of specialized effort – software development and platform operations. The nature of services, scaling, and security may vary the degree to which dev and ops responsibilities converge.

Dev-Oops: It Goes Wrong Over Time

Interestingly, engineering teams view DevOps as development, and “everything else”. From the time a developer checks code into version control, there is a large assortment of workflows that kick in. Ideally, there is testing, integration, more testing, deployment and feedback. This is a large body of work, often underestimated and underrepresented. To pile this responsibility onto members responsible for development alone is where things begin to go wrong. Often, as a product ages, incident management, maintenance, and other engineering efforts pile up–resulting in fewer cycles being available for product development over time.

There is also the complementary case, where engineering teams are focused on product development and assign most free cycles to it. Platform operations are forced to become a watered-down effort and consist of the bare minimum it takes to keep the lights on, so to speak. This is a common observation in small teams and startups that typically have a new product release.

When implemented correctly, DevOps must allow engineers to take responsibility for all aspects of developing a feature and managing it in production. This means that programming the business logic, creating the declarative and non-declarative software, binding with services, building the artifact, and finally deploying to production all come under the gamut of a developer. In addition, a feedback loop—created by baking observability into the mix will provide insight into the health of the service (or feature)—will require the engineer to stay on top of the operational aspects of performance and reliability.

The current definition and practice of DevOps originated from Agile methodologies. They take off from the limitations of typically Agile teams which were released in “sprints”, still kept dev and ops efforts separate, and were agnostic of underlying tech. DevOps, on the other hand, is more tightly-coupled with the technology employed, for example: Microservices and automation. It facilitates continuous deployment and a high frequency of releases. Most importantly, it converges the notions of development and platform operations. We find that the interpretation of this “convergence” is what differentiates good implementations of DevOps from bad ones.

The Right Kind of Shift Left

At the heart of healthy DevOps adoption lies a technology shift complemented by a cultural shift. The fundamental principle that belies successful teams is a great developer experience. Irrespective of the infrastructure that powers the technical stack of a web application, software engineers who work on it need to be able to develop and deploy with ease. Let’s explore how.

Examples of tools that aid engineers during the development phase include IDEs, Source Control, TDD suites, documentation generators, and many more. Tremendous amounts of research and product development are currently underway in enabling developers to program better and facilitate more efficient development.

Different skill sets and focus areas are required to optimize different portions of the operations spectrum. In the case of large enterprise organizations, the dichotomy is clear. There are Platform Operations teams that are responsible for keeping all the systems running by providing automated means to set up and sustain reliable systems on the server side. Application Development teams are tasked with creating the applications, API endpoints, integrations and various other artifacts that will enable users to execute their tasks.

Because of the common underlying nature of both these functions–writing software–they tend to cross-pollinate. This coalescing is welcome, provided it is managed well. This is where abstractions come in handy. In particular, PaaS abstractions that provide in equal parts agility and intransigence. Pliant enough to accommodate custom workflows and bespoke needs of software products and teams, and yet preventing needless osmosis between Dev and Ops responsibilities, ultimately resulting in a superior developer experience as the nucleus of this atomic transformation.

PaaS With Flying Colors

The PaaS-low’s Hierarchy!

The perfect balance can only come from PaaS systems that comprise an architecture that is modular and offers the functionality of application build and deployment. The ability to work across multiple languages and frameworks combined with packaging and deployment best practices is a basic tenet. Abstracting the underlying infrastructure to favor support for container-based artifacts and orchestrating them at scale is the next most desirable component of a PaaS framework. A batteries-included approach to automating continuous delivery, security best practices, and other workflows goes a long way in ensuring that the PaaS substrate works for all kinds of developer needs. When using abstractions, the biggest opacity comes in the form of a lack of production parity. If the PaaS can be functional on all staging instances viz. dev, test, pre-production, prod, or any other remote instances, it would save tremendous toil arising from a lack of parity.

Bonus points for being open source and accommodating compliance, policy mandates, and customization to suit the dynamic needs of different organizations. An active community supporting the ecosystem and driving innovation and change management would make a more compelling case for PaaS tools.

January 12, 2022
NPMs Sabotaged as OSS Sustainability Crisis Continues

A long-simmering debate over the sustainability of smaller open source projects moved beyond the theoretical when two widely used open source node packaged modules (npm) were deliberately sabotaged this week, allegedly by a primary contributor.

Colors.js is an npm that has been downloaded more than 3.3 billion times, with more than 19,000 projects depending on it. Faker, meanwhile, has been retrieved 272 million times, with over 2,500 projects depending on it. Colors.js enables organizations to print colorful text messages on the console, while faker is used to generate fake data for testing applications. Developers that pulled a recently published Colors.js version found their applications caught in an infinite loop, printing ‘LIBERTY’ ‘LIBERTY’ ‘LIBERTY’ followed by a sequence of gibberish non-ASCII characters. Functional code, meanwhile, was also removed from Faker.

Ax Sharma, senior security researcher for Sonatype, a provider of an open source software security platform, noted these actions occurred in the wake of the series of zero-day vulnerabilities that impacted the widely used Log4j logging tool for Java applications. Sharma first reported the update issues with Color.js and Faker.

The small team of contributors that work on the Log4j project found themselves creating multiple updates to the package to address vulnerabilities of varying severity on the common vulnerabilities and exposures (CVE) list. There is some debate, however, over how many of those vulnerabilities warranted a CVE listing given their severity, said Sharma.

That issue has now emerged as a flashpoint for contributors to smaller open source projects. These contributors contend that larger organizations are taking advantage of their efforts without making any substantial contributions to a project in return, much less compensating any of the contributors for their time and effort. The recent updates made to the npms are, essentially, a protest statement, explained Sharma.

It’s not clear whether other contributors to small open source projects might follow suit, but the debate over the sustainability of these projects has become heated. Many contributors to open source software assume that the organizations who use the free software they created should assume responsibility for securing it. That “user beware” approach to security is understandable for contributors that are not compensated for their efforts. However, when asked to patch open source projects used by billion-dollar organizations—and do so on an urgent, emergency basis—the resentment among those volunteer contributors rises sharply.

Fortunately, some effort is being made to address these issues. The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, raised $10 million to help maintainers embrace best practices and better protect open source projects from malicious code. Google has pledged $1 million to help open source developers adhere to National Institute of Standards and Technology (NIST) guidelines in response to the Biden administration’s recent executive order on cybersecurity. Administered as a pilot program by the Linux Foundation, that effort is part of a larger $10 billion commitment that Google previously made to open source security.

White House national security adviser Jake Sullivan also recently sent a letter to major software companies and developers inviting them to discuss initiatives to improve open-source software security. The first step is a one-day discussion this month hosted by Anne Neuberger, the deputy national security advisor for cyber and emerging technology. In the letter, Sullivan specifically noted that while open source software has accelerated the pace of innovation, much of it is maintained by volunteers. This is now a key national security concern, he noted.

It’s not clear how this emerging open source sustainability crisis will play out. However, DevOps teams might want to consider how dependent they are on open source projects whose contributors might have issues with how their work is being exploited.

January 11, 2022
CNCF Takes LitmusChaos Platform to the Incubation Level

The technical oversight committee (TOC) for the Cloud Native Computing Foundation (CNCF) announced today it is elevating the open source LitmusChaos application testing platform to the incubation level.

LitmusChaos is a chaos engineering platform donated to the CNCF by ChaosNative in 2020. Since then, it has seen adoption within production environments by more than 25 organizations, including Intuit, Lenskart, Orange, Red Hat and VMware.

ChaosNative CEO Uma Mukkara says LitmusChaos was developed to provide DevOps teams with a chaos engineering platform built using containers that makes it easier to scale up and down than existing monolithic alternatives. The platform itself, however, can be used to test both monolithic and microservices-based applications.

The platform consists of a Chaos Operator based on a software development kit (SDK); a ChaosHub for hosting and sharing experiments; Litmus Workflows that declaratively chains experiments (either in sequence or parallel) to build a chaos scenario; a centralized control plane, dubbed ChaosCenter, to design, schedule and monitor Litmus Workflows; Litmus Probes for creating chaos scenarios that automate steady-state validation and remediation actions and a Chaos Observability tool to export Prometheus metrics.

In total, there are now more than 400 contributors to the LitmusChaos project and more than 4,000 pull requests have been made. Mukkara said since the beginning of this year, Litmus operator installations have grown to more than 2,000 per day. Going forward, the goal for 2022 is to significantly increase the number of LitmusChaos integrations there are for a wider range of DevOps platforms, added Mukkara. Additional sets of experiments for Kubernetes and non-Kubernetes targets, improved observability and integration with other platforms—via the open source OpenTelemetry agent software also being advanced by the CNCF—is also planned.

In general, it’s still early days as far as the adoption of chaos engineering with DevOps workflows is concerned. However, Mukkara said that as more organizations embrace observability to better understand IT processes, the number of organizations that also use chaos engineering to test IT resiliency should also increase. In fact, as IT environments become more complex—thanks mainly to the rise of microservices-based applications—chaos engineering approaches to testing may someday be required, noted Mukkara.

In the meantime, there are still a lot of IT professionals that are uncomfortable with chaos engineering approaches to testing that deliberately break underlying services to test the resiliency of an application. The core idea, however, is that no application should have a single point of failure that could lead to it becoming unavailable. In theory, a microservices-based application won’t fail because when a service becomes unavailable calls are automatically rerouted to another service. The performance of that application will degrade, but it won’t go offline. The challenge is that building an application that achieves that level of resiliency using microservices requires a significant amount of DevOps expertise.

Regardless of how an application is constructed, the one thing that is clear is how dependent organizations are on applications to drive revenue. As such, the tolerance for application failures—or performance degradation—has never been lower.

January 11, 2022
Step Aside, Monoliths: Meet the Composable Enterprise
A composable enterprise, defined by Gartner as “an organization that delivers business outcomes and adapts to the pace of business change”, relies on the assembly of interchangeable application building blocks. This architectural overhaul has largely been driven by a demand for more configurable application experiences, and the need to evolve existing application portfolios that are often too risky and costly to replace.

New business opportunities require agility from application portfolios; however, many enterprises are still limited in their ability to adapt. Why? They rely on monolithic ERP systems and cumbersome legacy applications with static processes and haphazard structures. A modular setup can enable a business to rearrange as required depending on external or internal factors, such as shifts in consumer attitudes or sudden supply chain disruptions. Organizations are experiencing these shifts now and require a new approach to enterprise applications to be able to adapt.

Bridge the CX Gap with Greater Composability

A composability approach is the best way to capture all the advantages of modern enterprise software. According to a recent Boomi report, by 2023 organizations that have adopted a composable approach will outpace the competition by 80% in the speed of new feature implementation. This shift requires enterprises to rethink how they architect their operations, harness a combination of packaged functions and technologies and successfully deliver seamless moments of service to their customers.

There are three key ways that businesses can make the composability shift:
- Adopting a service mindset
- Scaling the delivery of microservices
- Packaging business capabilities using Application Programming Interfaces (APIs).
1. Designing for Service: Compete on Outcomes, not on Products

A composable enterprise whose portfolio is made up of heterogeneous applications from a palette of best-of-breed solutions allows organizations to address key inflection points throughout every customer, product or service lifecycle.

As more consumers demand continuous value and reliability throughout an asset’s lifetime, businesses must shift to selling outcomes and experiences instead of products to meet these new expectations for quality service. This requires each part of an operation to align, not around immediate sales or revenue, but around delivering a quality Moment of Service™ — the inflection point where everything comes together to create better value and outcomes for customers.

Moving to a servitized model requires a composable stack to deliver services to order. At a systems level, this transformation requires organizations to adapt applications dynamically and deliver positive customer experiences with effective quality management, customer support, and access to complete information about the service offering. Unlike traditional enterprise software, this involves connecting data and applications that have often sat in separate silos. A composable enterprise can provide a service-orientated architecture, that enables businesses to become outcome-based and ready to quickly adapt to future disruptions.

2. Scale Component-based Architecture with Microservices

If applications are built as loosely coupled services, then companies can employ a composable architecture to capitalize on independently deployable modules that are organized around business capabilities. This allows organizations to swap modules in and out, to suit emergent needs and build a well-structured best-fit solution for their unique business.

In contrast to a monolithic architecture, businesses can easily add resources to the most needed microservice rather than having to scale the entire application as demand for an application increases. In practice, this allows businesses to simplify customizable workflows and optimize business processes while leveraging and applying tools such as robotic process automation, artificial intelligence, or the plethora of hyper-automation capabilities available today.

3. Embrace Open-ended APIs to Maximize Data-sharing Capabilities

Packaged business capabilities (PBC) assembled using APIs are the foundation of every composable enterprise. They are used by businesses to secure data across cloud services, business systems and mobile applications. Historically, APIs have been used in monolithic applications to exchange data between the entire application and external applications and services. In composable software, APIs exchange data from individual modules to external applications and within the application — from module to module. This has significant implications for how systems are designed and built.

APIs can provide a controlled and consumable method for connecting and sharing consumer and business data by creating experiences tailored to individual needs. For instance, an API-centric model can secure and manage data access to help businesses with faster decision-making and deliver relevant new services adaptable to market changes. In the future, there will be more automated continuous process improvements as machine learning models recommend, or even proactively make, process changes to improve outcomes for the business and end customer.

Opt-in to the Composability Evolution

To overcome the limitations of monolithic applications, businesses must rethink their approach to enterprise applications — starting with the business architecture and technology stack. A composable software architecture enables organizations to address the internal and external pressures that send shockwaves throughout the value chain.

As a composable enterprise, organizations can re-engineer their businesses to ensure customer touchpoints and stages come together for better moments of service, but companies must be certain that processes are optimized across each of these inflection points to mitigate issues and fuel growth. An IT architecture built on a foundation of composability will be essential to the successful delivery of a software-powered business development strategy that can provide continual value to customers and the business itself.
January 11, 2022
Crafting an Agile Enterprise Architecture
Digital transformation, business agility and enterprise architecture are frequently heard terms in this era of digital technologies and rapid change. The appropriation of digitalized applications, solutions and processes has enabled organizations to increase efficiencies. In turn, this allows them to respond to shifting customer needs and trends in a more flexible and agile manner.

Digital transformation, the rise in mobility and a remote workforce have created a shift in the business model paradigm. The adoption of a more agile approach has been gathering steam, and businesses that are building agility into their processes are seeing the payoffs. The results are greater productivity, faster time-to-market (TTM) and increased consumer satisfaction.

The Culture of Agile

Digital transformation succeeds in a business environment that embraces a more collaborative and flexible philosophy. Moving from simply doing agile business processes to being agile across the board requires a shift in the corporate mindset. When a business develops a truly agile architecture, everyone in the enterprise is involved in delivering solutions; from business operations and tech to marketing, finance, compliance and security. The agile culture moves from a company-oriented one to a people or customer-oriented culture, embracing the tenets of collaboration, co-creation, ownership, flexibility and communication.

Short-Term Cycles and Fluid Planning

Agility is redefining enterprise architecture from the traditional schematic of centralized governance, lengthy development cycles, scheduled quarterly reviews and reliance on a waterfall delivery method. Instead of long-term operating and strategy plans, agile enterprise architecture involves short-term cycles and fluid planning that is customer and market-centric. The language changes from top-down project mandates and management to continuous product development, experimentation, testing and monitoring within collaborative product teams.

Essentials for Crafting Your Agile Enterprise Architecture

The blueprint for a truly agile architecture requires fundamental shifts in the business dynamic. There are three essentials that stand out as requirements for attaining agility across the entire enterprise.
- Collaboration – The bedrock of successful enterprise-wide agility is collaboration. Innovation will flourish when it is decentralized, and isolated silos give way to cross-functional, agile and self-organizing teams. An isolated IT team leads to delayed projects, overrun budgets, productivity that is hard to measure and disconnects between business and operations. Every department must be involved in supporting and achieving key business goals.
Teams containing a mix of business line and IT professionals accelerate development and delivery, greatly reducing time to market. Based upon a shared customer-centric goal and vision, there is shared ownership of outcomes and a deeper level of engagement throughout the enterprise. Daily communication and collaborative feedback nurtures creativity, problem-solving, and drive continuous integration and continuous development. Collaborative input from colleagues, inside and outside the organization, is essential for enterprise, technology, and solution architects.
- Current state mapping – Adopting agile practices and principles throughout an enterprise entails potentially massive change. Without a clear roadmap for navigating the process, a business can flounder. Instead of achieving a leaner simplicity, there is increased complexity and a muddied vision. Before a business can successfully embrace an agile architecture, the current state of operations must be fully understood. Essentially, a blueprint of functionalities, capabilities, applications, and the tech stack must be crafted. Everything, from the data catalog to business process workflows must be mapped. Business leaders can ask the following questions to analyze the current state and assess impact points:
- Which projects should we prioritize and what capabilities will they require?
- Which processes rely upon what software applications?
- If we remove one or two apps, how will that impact processes?
Once the blueprint of the current state is mapped out, a business can work in a structured way to create the future state of its architecture with ease and at its own pace.
- Balance agile transformation with daily operations – Continuing to work with some of the current architecture for a time can allow the top level of the organization to ease into adopting the agile mindset and culture. In the iterative process of developing agile architecture, the architects, executives, and tech leaders will need to strike a balance between transforming initiatives and effectively maintaining daily operations. They will have to discern how much direction is needed versus support and how much they will set the pace.
If the focus is first on value delivered to customers, then the architecture will be prioritized according to the most strategic projects, capabilities and applications. An agile architecture will adopt a ‘just enough’ approach to project design and delivery.

Agile Architecture Optimizes Collaboration

Enterprise agility facilitates more direct communication and involvement of enterprise architects within the cross-functional teams. Through daily discussions and various touchpoints, architects can provide guidance, advice, and feedback on IT decisions and assist teams in jointly owning the solutions.

Working together, enterprise and solution architects can develop a complete view of the IT landscape and how it will need to be modified to fit into future needs; minimizing waste and optimizing resources. Solution architects can view the architectural map across all apps, solutions, and systems and collaborate on improvements. They can also help enterprise architects scale standardization across the entire business. That cornerstone of collaboration at the core of agile transformation enables architects and non-tech leaders alike to gain more clarity and alignment.

The Value of Agile

Business value is greatly improved when enterprise architecture combines agile practices. According to a report from McKinsey & Co., businesses transitioning to more agile models can improve financial performance by 20-30%, with 30-50% improving operational performance, TTM, and customer satisfaction scores. Embedding an agile model within processes, people, and technology will cultivate ongoing support for CI/CD, groundbreaking innovation, synergistic collaboration — and ultimately maximize customer outcomes.
January 7, 2022
Theranos’s Holmes VC Reverb | 5G C-Band Marches On | Mozilla Jumps Shark

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 conviction of Theranos CEO Elizabeth Holmes leads to greater scrutiny of startups, higher-frequency 5G NR is creeping towards reality, and Mozilla gets criticized for promoting climate-harming scams.

1. Holmes Case Causes Valley Rethink?

First up this week: Elizabeth Holmes has been found guilty of defrauding Theranos investors. But how will the affair change Silicon Valley’s startup-and-funding culture?

Analysis: Don’t fake it—just make it.

This could be a seminal moment, causing investors to look more closely at startup founders and their outlandish promises. On the other hand, key Theranos investors—e.g., Murdoch, Cox, DeVoss—hardly fit the mold of Silicon Valley VCs.

David Streitfeld: The Epic Rise and Fall

F. Scott Fitzgerald’s creation … Jay Gatsby … was a bootlegger [and] sold fake bonds. Ms. Holmes chose Silicon Valley, the last and greatest of all human dreams. [She] was a natural salesperson, as good at bending reality as Steve Jobs himself.
…
She and her deputy and boyfriend, Ramesh Balwani … thought they could brazen it out in the Silicon Valley tradition until they had something that actually worked. [But] the verdict signaled the end of an era. In Silicon Valley, where the line between talk and achievement is often vague, there is finally a limit. … It is an epic rise and fall that will be chewed over in the coffee shops and juice bars of Palo Alto, Calif., until the tech industry departs [for] off-world colonies.
…
So where does this conviction leave … her investors and former fans? Ripe for the next huckster that comes along, probably. Some Silicon Valley promises are so sweet we just can’t get enough of them. Immortality. Crypto. Flying cars. Mars. Digital harmony. Wealth beyond compare.

Think different, thinks DeanonymizedCoward:

[There’s a] fine line between bombastic marketing spam, “fake it ’til you make it” pitches, and outright fraud. … The first is repugnant and sometimes unethical, but generally legal.
…
[But] If your product requires bull**** to get funded—even if it ultimately works—you’re a fraud. … Regulatory reforms … and a sort of corporate death penalty … can fix a lot of this by making it less financially practical to engage in ****ty behavior.

Who else is to blame? Ask DS999:

I am sure some of her investors didn’t really care whether it worked. They just wanted to get in early, ride the hype train up, and sell before actual results mattered.

2. FAA and 5G Carriers Kiss and Make Up

Higher-frequency 5G NR is creeping towards reality in the U.S., thanks to the FAA backing down. After the aviation regulator had vetoed C-band deployment—based on precious little evidence—it looks like as much as 280 MHz of extra spectrum is now ready to switch on.

Analysis: Nomadic DevOps gets more bandwidth

While band 77 is nowhere near the much-vaunted “FR2” extremely high frequency bands, this is a useful chunk of extra spectrum for mobile and nomadic apps. Next stop: ubiquitous Ka-band.

Jon Brodkin: FAA agrees not to seek any more 5G delays

The Federal Aviation Administration tentatively agreed not to seek any more 5G delays from AT&T and Verizon, potentially ending a battle over the aviation industry’s unproven claim that 5G … will interfere with airplane altimeters. [Their] C-Band spectrum licenses are for the frequencies from 3.7 GHz to 3.98 GHz.
…
The deal incorporates voluntary commitments that AT&T and Verizon previously made, including “C-Band radio exclusion zones” around airports for six months. [They] modeled the exclusion zones after those used in France, which are 910×2100 meters.
…
Assuming there are no further problems, AT&T and Verizon would be able to use their spectrum licenses without extra restrictions after July 5. … President Biden applauded the agreement … calling it “a significant step in the right direction.”

In summary? Here’s Dieter Bohn:

The agency in charge of airplanes is mad about wireless things. But the agency in charge of wireless things and the companies that make them lost a game of chicken.
…
GREAT JOB AMERICA. … I always said I wanted Internet Service Providers to be Dumb Pipes, but I never expected them to be this dumb.

Has anyone read the FAA’s detailed report? bburdge has:

I can see why the FAA is backing down here now, it only makes sense when your key report could be paraphrased as: “We got a couple grad students to run some basic model comparisons … using altimeter data from the aviation industry (with a proven track record of lying to us) and then went golfing for eight months before publishing … but didn’t bother … to actually test anything.”

3. Mozilla Forgets its Values

Firefox custodian, the Mozilla Foundation, has angered many by promoting a “grossly irresponsible” “Ponzi scheme” that harms the environment. What is this awful thing? I hear you ask. It’s cryptocurrency.

Analysis: Imaginary money is bad—is this the last straw for Mozilla?

Less than a year ago, Mozilla said it wants to be carbon-neutral, but it’s already reneged on that promise: Distributed proof-of-work systems require … well, work. And that work uses ridiculous amounts of energy per DeFi transaction. Electricity production is a zero-sum game, so cryptocurrencies and NFTs cause climate change by emitting ridiculous amounts of CO₂e.

Liam Proven: Mozilla founder blasts browser maker

A few days ago, Mozilla Foundation invited netizens on Twitter to send in cryptocurrency donations. … This move by the Firefox browser maker rapidly drew criticism.
…
As recently as September, Moz’s web-standards lead Tantek Çelik slammed cryptocurrencies as being unsustainable, stating: “[They] are harmful for sustainability. … Their energy requirements grow without any discernible upper bound, which is grossly irresponsible given the global environmental crisis.”
…
Mozilla has accepted crypto-coin donations for years, perhaps as part of its long-ongoing efforts to alienate its own users: It’s only the payment provider that changed.

Chief among critics was Jamie “jwz” Zawinski:

I founded Mozilla and I’m here to say **** you and **** this. Everyone involved in the project should be witheringly ashamed of this decision to partner with planet-incinerating Ponzi grifters.
…
Stop saying you were promised flying cars. Unless you were born in 1935, you weren’t promised flying cars, you were promised a cyberpunk corporate dystopia.

It’s a shark-jump moment thinks Jeremy Keith:

The most convincing argument I’ve heard yet for switching away from Firefox as my main browser comes from Mozilla. I wasn’t expecting that plot twist.

The Moral of the Story: What is safety to one is not always safety to another.

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

Image: Benjamin Hayward (via Unsplash)

January 6, 2022