devopsy.kinsta.cloud

Category: DevOps in the Cloud

Survey Surfaces Multi-Cloud Computing and Cost Challenges

A survey of 360 CIOs and IT leaders in the U.S. and the United Kingdom found that, as the number of cloud platforms an organization employs expands, the number of tools they are required to deploy and master does, too.

The survey, published this week by Virtana, a provider of a platform for managing cloud migrations, found nearly two-thirds of respondents (63%) reported their organization relied on at least five separate tools for migration, cloud cost optimization, integrated performance monitoring, application performance management and cloud infrastructure monitoring. A full 83% are expending some level of manual effort to consolidate data from all of these tools, or are simply using them in isolation from one another. Only 17% said data integration is fully automated.

Nearly three-quarters (73%) also noted that siloed efforts limit their ability to realize the full potential of the cloud.

It appears that multi-cloud computing only makes managing IT more challenging. Not to mention the increased pressure a multi-cloud approach puts on DevOps and developers that already juggle an overwhelming number of tools for development, DevSecOps and more. And, of course, the risk of cloud misconfiguration grows alongside the number of cloud platforms an organization uses.

According to the Virtana survey, a total of 82% of respondents have a multi-cloud strategy, with more than three-quarters (78%) deploying workloads in more than three public clouds. A full 59% now run more than half of their workloads on public clouds. More than half (51%) also plan to increase the number of public cloud instances they support this year, with more than a third (34%) planning on using five or more cloud platforms.

More challenging still, more than three quarters (76%) are in the early stages of implementing serverless computing frameworks. Overall, more than half (52%) will continue to maintain a hybrid environment as part of their core IT strategy. A full 96% of respondents see value in workload portability, but only 71% are in the early stages of achieving that goal. Top benefits anticipated include maximized cost savings (58%), reduced cloud service provider risk (46%) and increased business agility (43%). However, nearly three-quarters (75%) have either no or few cloud governance capabilities (34%) or have stitched together disparate tools to achieve that goal (41%).

Jonathan Cyr, vice president of product management for Virtana, said that as the global economy becomes more challenging, it’s only a matter of time before sensitivity to cloud costs start to rise. Each time the overall IT environment expands, increases in complexity drive the total cost of IT higher.

It’s not clear to what degree that sensitivity to cloud cost might drive more IT organizations to centralize the management of IT environments. In theory, a single control plane could be employed to manage multiple cloud computing environments, but today most clouds are still managed in isolation from one another.

IT teams also find themselves inadvertently locked into a cloud platform. The more developers invoke proprietary application programming interfaces (API), the more difficult it becomes to migrate a workload from one cloud platform to another.

It’s all but certain there will be a cloud management reckoning in the months ahead. Development teams may prefer one cloud platform over another for many reasons but, as the cost of IT continues to increase, there will soon be tougher cloud cost questions emanating from the finance office.

May 20, 2022
Managing Hardcoded Secrets to Shrink Your Attack Surface

The practice of hardcoding secrets—such as authentication credentials, passwords, API tokens and SSH Keys—as non-encrypted plain text into source code or scripts has been common in software development for many years. It is an easy way to save time and labor, but it is also highly insecure. The issue is that anyone with access to the code also has access to these hardcoded (or embedded) credentials, meaning your code is supremely vulnerable to attack.

Of course, today’s DevOps-oriented software development life cycles are all about velocity and efficiency—the goal is to advance and launch products not in weeks or months, but in days or even hours. Anything that might slow that pipeline is to be avoided, which is why hardcoded secrets are not going anywhere. They are going to be with us for many years to come.

At the same time, cybersecurity experts are right to be alarmed about the growing problem of secrets sprawl, which occurs when an organization stores secrets in a variety of locations, including source code, text files and spreadsheets. In today’s multi-cloud DevOps environments, it is simple arithmetic: As the number of users grows, your attack surface grows, too, in many cases expanding exponentially.

The Right Tools to Manage Secrets

According to Gartner, “Hard-coded secrets embedded in source code and scattered throughout the DevOps pipeline pose significant risk. Technical professionals responsible for DevSecOps must introduce tools that securely store and manage secrets and enforce access controls without disrupting automated DevOps workflows.”

What has come to the fore as many organizations have adopted cloud infrastructure, containerization and microservices architecture—especially regarding the software development life cycle (SDLC)—is that conventional technologies for secrets governance and entitlements management are not at all adequate in the cloud. Vault technology for static secrets is a well-understood set of capabilities that has been a cornerstone of cybersecurity best practices for many years. SecOps and DevOps teams realize that they need to adapt vaulting to cloud environments, but progress toward effective cloud secrets governance has been held back by several challenges.

Just-In-Time For the Cloud

First, as noted above, disrupting continuous integration/continuous delivery (CI/CD) processes is not seen as an acceptable practice. DevSecOps teams very much expect to deploy secrets management capabilities without slowing or otherwise impeding the development process and without having to expend additional resources. Yet many standalone vaulting services are cost-prohibitive for most SMBs. Further, in many cases, conventional approaches to secrets management cannot deliver full governance capabilities, including clear visibility and attestation, across multiple vaults or within cross-cloud environments.

The good news is that today’s advanced dynamic permissioning platforms incorporate just-in-time (JIT) secrets provisioning capabilities and zero standing privilege (ZSP) enforcement mechanisms and can overcome these obstacles. The automated granting and revocation or expiring of permissions—JIT privilege grants—is highly effective at minimizing attack surfaces. These solutions—increasingly grouped under the banner of cloud infrastructure entitlement management (CIEM)—work based on the concept of zero-trust, which means no one and nothing is trusted with standing access to your cloud accounts and data.

With JIT, elevated privileges can extend either for the duration of a session or task, for a set amount of time or when the user checks the profile back in manually. Once the task is complete, those elevated privileges are automatically revoked—all without sysadmin involvement. Where a user previously had standing access privileges potentially extending around the clock for months or years at a time, converting to JIT granting compresses that attack surface to several hours per month.

Even better, as cloud-native entities, these solutions can support highly effective secrets governance initiatives for SMBs and enterprises alike. CIOs, engineering managers, CISOs and other IT security officers looking to better protect their multi-cloud DevOps environments should be looking to adopt an automated secrets governance platform that enables them to deliver on these four priorities: Visibility, enforcement, automation and investigation.

Visibility

Cross-vault visibility into all your secrets, secrets owners and secrets users is a must-have. You need to be aware, at any given time, of every human and machine user that has access to a secret, and you need to be able to uncover and monitor your highest-risk secrets or accounts across vaults.

Enforcement

You need to be able to enforce your secrets policies across vaults, which necessarily includes the ability to automatically rotate your static secrets across all vaults based on organizational policy. JIT permissioning is key here because it enables users to generate temporary credentials on the fly, and necessarily incorporates the automated granting and expiring or revocation of permissions—JIT privilege grants—which is highly effective at minimizing attack surfaces.

Automation

You need to be able to manage the identity life cycle for your secrets—preferably through an automated joiner/mover/leaver process. Consider, for example, if several people have access to a shared secret. Sharing accounts is not a best practice from a security standpoint, but it is common (and becoming more so) with the growing use of cloud resources within DevOps organizations. If one of those individuals in the shared secrets group leaves the organization, that permission/privilege then becomes a potential vulnerability. Automated shared secrets rotation that is invoked by policy directly addresses this issue.

Investigation

Security incidents are an inevitable eventuality in any organization. When an incident occurs—data breach, lost device, ransomware attack—you need to be able to tie secrets back to identities for proactive monitoring and post-incident investigation. Understanding which identities or individuals were exploited—and how—is essential for addressing vulnerabilities or bad practices. Analysis and reporting are also a critical capability for looking into access changes, addressing policy drift and identifying risky behaviors.

There’s no question that secrets governance in cloud environments requires rethinking and retooling established vault technologies and best practices for securing static secrets. JIT permissioning and secrets grants based on ZSP precepts provides an effective path forward. Consider that with JIT and ZSP, elevated privileges are circumscribed, and time-limited to minimize the permissioning and privilege threat surface. Taken together, these capabilities can deliver highly effective secrets governance to secure your entire organizations, without slowing or otherwise impacting your DevOps teams.

May 20, 2022
Creating Automated GitHub Bots in Go

Events management requires quick responses, which can be challenging since there is typically an incredibly large volume of events that take place every day. Therefore, relying on humans to respond to these events quickly is error-prone, messy and often frustrating. These events have easily reproducible steps that can be codified and are perfect reasons for a bot to exist.

Creating a bot reduces the daily noise of events so that important humans can focus on important human activities—such as programming, innovating or, most importantly, sleeping. There are already many bots that exist and that can solve numerous problems. For example, Dependabot helps keep your GitHub dependencies updated with automatic pull requests. Google Calendar has a Slack bot that reminds you when a meeting is about to start. Of course, there are also situations where there isn’t a pre-made bot yet, which provides the perfect opportunity for developers to create their own!

My preferred programming language is Go, and I’ve used it to create multiple bots. A favorite bot I created helps to manage a large open source project called Telegraf, which I discuss in more detail at the end of this article. Bots are not limited to open source projects; another bot I created proved valuable when I worked for a larger enterprise company. It was a Slack bot that could run commands on Amazon EC2 Windows instances and help teams quickly perform actions for customers, such as resetting passwords in seconds as opposed to days.

Creating Your Own Bot for GitHub

Let‘s look at how you can get started creating a bot written in Go that can interact with GitHub. The package google/go-github lets you interact with the GitHub API and makes creating a bot for GitHub easy. Tools like these are your first step in developing your own bot. Using this package, you could create something similar to what Dependabot does. In order to begin receiving GitHub events for you to react to (such as someone creating a pull request), you need to create a GitHub App.

The GitHub documentation does a great job describing how you can do this, but the important piece to be aware of is a callback URL. The callback URL will be a publicly available address associated with your Go program so that GitHub can route events to it. I use AWS Lambda functions to host the bots I’ve created and managed by using Serverless Framework, but you could use anything you want as long as you get a public URL. If you are interested in using a Lambda function as well, your “main.go” can be as simple as just calling “lambda.Start” and passing in the function that will hold the business logic.

Because you are using a public URL, security is important. Once you have created the GitHub App, you will be given a secret token that you can use to help validate incoming requests. The google/go-github package makes this easy; all you have to do is call github.ValidatePayload and pass it your secret token and incoming HTTP request to ensure the payload is valid. If successfully validated, the function will return the JSON payload that defines the event you just received. You can parse the payload by using the function github.ParseWebhook, which will return to you an empty interface and can hold any value. Therefore, you will need to use type assertion to access the underlying type to see what event you have received.

Depending on the event type, you might want to take different actions. Perhaps if someone made a new issue you would receive the type github.IssuesEvent, which would be good to perform initial triage such as adding the appropriate labels. It is also possible to receive the event type github.CommitcommentEvent, which would indicate someone had just made a comment that you could check for special commands such as automatically restarting the build system. You could, for example, also create a welcome comment whenever someone creates a new issue, as seen in the code snippet below.

Creating a Slack Bot

These examples have focused on interacting with GitHub, but can be replicated to create a Slack bot similar to the Google Calendar bot. The package slack-go/slack allows you to interact with the Slack API with which you can post messages or create “modals” that allow users to interact with custom buttons and lists.

Creating a Slack bot is a similar process to creating a GitHub App. Slack provides a user interface to register a bot, and similar to GitHub, the main thing it needs from you is a public URL so it can send your bot events. You can then also verify incoming events by using the function slack.NewSecretsVerifier using the secret token provided by Slack. As an example, once these steps are completed, your bot can then begin sending messages to channels to help you answer questions.

Bringing it to Life

An example of a bot can be found in the Telegraf project, which is InfluxData’s open source data collection agent. We have a bot written in Go helping us maintain the repository named “telegraf-tiger.” One of the first interactions users have with the bot is when they submit a new pull request. When the request is made, the bot will chime in with a friendly reminder to sign our contributor’s license agreement (CLA).

Once signed, the bot can be asked to verify if the CLA has been signed by adding a comment “!signed-cla” and give the pull request a shiny green checkmark to let the maintainers know everything is ready.

Another area our Tiger bot supports is sharing the artifacts that our continuous integration (CI) system builds for each pull request with a helpful comment that links to each type. This helps spread awareness of the artifacts so that anyone can easily help test the new feature or bug fix without having to set up a local developer environment themselves.

The Big Takeaway

Bots are an exciting developer tool that can automate mundane assignments and allow engineers to focus on bigger, more engaging tasks. Resources such as GitHub also make it easy to develop bots using Go in various ways. Bots are commonly found across interfaces, with some simply reminding us of upcoming meetings, and others ensuring that important license agreements are signed.

The use cases for bots are endless, and with the right tools, bots can help engineers focus on more significant tasks at hand. Developers can rest easy knowing their bots are automating tasks and responding to the endless alerts they don’t want to deal with. Instead, they’re able to focus on important human activities, like sleep, so they can dream up the next big thing.

May 18, 2022
Apple Allows 50% Fee Rise | @ElonMusk Fans: 70% Fake | Microsoft Salaries up by 100%?

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: Apple lets devs increase subscriptions “without consent,” Twitter has more than 19% spam accounts, and we dig into the claim that Microsoft is about to double salaries. (more…)

May 17, 2022
Increasing Use of SLOs to Enable Observability
Observability is a growing discipline among most IT and operations departments. To release stable software faster, operators need continuous visibility into metrics like performance, uptime and availability. As a result, engineers are increasing their use of service-level objectives (SLOs) across the board—a recent study found that 82% of companies are increasing their use of SLOs.

SLOs enable deep visibility into specific applications’ performance and are often used by site reliability engineers (SREs) to ensure quality and avoid service interruptions. Not only that, but various teams are correlating SLOs to aspects of the business to reduce cost and help direct decision-making. But while many environments have visibility, there are still gaps present.

Nobl9 recently released a global survey of IT professionals and executives that tracked the state of service-level objectives in 2022. Below, we’ll look at the key findings from the report and consider what they mean for the state of SLOs and observability in general.

State of Observability and SRE

In general, site reliability engineering is still maturing across organizations. Though only 31% of companies have adopted SRE, it’s slated for much future growth, as 46% said they plan to embrace SRE in the future.

These operators are now faced with many cloud-native observability tools, which are producing a sea of data in the form of metrics, logs and traces. A full 39% of companies use anywhere from six to 10 observability and monitoring tools and 35% use more than 11.

With so many tools now deployed, who is using this observability and monitoring data? Namely, at 74% of companies, observability data support operational requirements. Operations teams are the ones most likely to use SLOs to monitor uptime, performance and overall efficiency. After operations teams, security teams also use this observability data (71%), which makes sense as SLOs can inform incident response. Other areas that follow are customer support, compliance and capacity planning.

One interesting finding is that only 42% of companies use SLOs for service-level agreement (SLA) adherence. This indicates that SLOs are most often applied to internal optimizations and decision-making.

Hybrid Environments Complicate Visibility

Companies are mostly tracking SLOs to increase their visibility into networks (83%), databases (76%) and applications (75%). Other top areas include private cloud environments and legacy computing arrangements. But although observability is trending, organizations still lack complete visibility across the entire stack.

Of note is that nearly half (46%) of respondents said their monitoring and observability tools don’t provide full visibility into all of their company’s IT assets. For example, only 45% of companies have visibility into their containers and just 35% have visibility into their microservices architecture.

A lack of full-stack visibility may be complicated due to rising hybrid and multi-cloud conditions, as 78% say a hybrid cloud environment makes monitoring infrastructure more difficult.

Benefits of Tracking SLOs

The report defined SLO as “a performance and availability target set for a given system, application [or] service over time.” And the benefits are readily apparent for organizations following such targets—they can help increase performances, direct decision-making and help avoid outages.

As a result, 70% of companies are currently using SLOs in some fashion. Here are some benefits of tracking SLOs:
- Increase microservice performance: 87% said using SLOs for microservices architecture would improve service performance.
- Enable full-stack observability: 58% said some of their company SLOs are mapped to business operations.
- Improve business decision-making: 91% agreed using SLOs can help drive better business decisions.
- Prevent service interruption: 67% said their company prevented business interruptions thanks to SLO thresholds alerts.
- Reduce expenses: 90% indicated SLOs saved their company money.
Final Thoughts

More teams are tracking service-level objectives than ever before. And most companies (71%) that aren’t using SLOs now plan on adopting them soon. The data demonstrated that the observability market is an evolving area with room to grow. And, the same can be said about the SRE role.

Yet, it’s good to point out that not all companies will adopt precisely the same roles or monitoring procedures. Therefore, there will likely continue to be variance in who is using SLOs and how they are applied. Regardless, the study suggested that investigating SLOs has the potential to benefit the software life cycle in many ways.

The study, “Adoption of SLOs Grow to Increase Visibility and Drive Business Improvements” surveyed 309 participants around the globe in various sectors. The study was sponsored by Nobl9 and conducted by Dimensional Research. For more information, you can download the report here.
May 17, 2022
Progress Expands Scope of Compliance-as-Code Capabilities

Progress this week extended its DevSecOps portfolio—built atop the Chef automation framework it acquired in 2020—to now include the ability to programmatically address compliance mandates.

At the same time, Progress has updated the Progress Chef InSpec framework for automating the discovery of compliance issues to add support for SAP ASE, IBM DB2, Mongo, Cassandra, Oracle, MS SQL platforms along with RHEL, CentOS, Ubuntu and macOS Monterey.

Progress has also updated the Progress Chef Enterprise Automation Stack (EAS) to add the ability to combine infrastructure configuration processing with compliance audits within a single consolidated policy definition along with a high availability capability that makes certain the platform is always accessible.

Prashanth Nanjundappa, vice president of product management for Progress, said Progress Chef Cloud Security enables DevOps teams to take advantage of a single policy-as-code platform to consistently implement compliance policies alongside security controls across both multiple public clouds and on-premises IT environments.

Progress Chef Cloud Security leverages certified industry benchmarks, such as the Center for Internet Security (CIS) benchmark, to continually scan and automatically detect security configuration issues at multiple stages within a DevOps pipeline. Progress has now expanded CIS benchmark profile coverage for Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) to include more than 100 customizable pre-built service and resource templates. DevOps teams can take advantage of automated creation of code, test and documentation artifacts for those resources. Finally, visibility into the status and expected completion time for compliance scans has been added along with advanced Shell command support for control and testing without file output.

In general, the ability to address compliance requirements within a DevSecOps workflow has become crucial because the number of misconfigurations that occur in the cloud has exploded. Developers that often have little to no security or compliance expertise are programmatically provisioning cloud infrastructure in a way that, for example, leaves ports wide open. As IT organizations embrace more cloud computing platforms, that security issue only compounds, noted Nanjundappa.

More challenging still, cloud computing environments are becoming more complex with the rise of cloud-native applications based on platforms such as Kubernetes. The odds a developer is going to make a mistake only increase with each microservice deployed.

Progress is betting that, as cloud computing evolves, responsibility for security and compliance will increasingly shift left toward DevOps teams; they’ll be responsible for implementing polices defined by cybersecurity and compliance specialists. The goal is to provide a set of guardrails that make configuration mistakes less likely because policies are being tested within the context of a DevSecOps workflow, said Nanjundappa.

It’s only a matter of time before software supply chain security reviews that are occurring in the wake of a series of high-profile breaches force the DevSecOps issue within more organizations. The goal, of course, should be to eliminate the need to identify DevSecOps as separate from a DevOps workflow. Regardless of the approach, however, the one good thing about all this attention is that application environments will inevitably become a lot more secure.

May 12, 2022
Container Storage for DevOps: New Options With NVMe
The DevOps world is ripe for a storage paradigm change, both in how it operates within the enterprise and how it implements applications.

NVMe, especially NVMe-over-fabrics (NVMeoF), is both a tool and a host target that can provide such a change—especially in the new world of microservices and containerization. NVMe can drastically improve application performance over classic implementations and, given the right tools, transform the process of writing those implementations to be faster, more robust and more flexible.

I/O-Intensive Work

A quick recap shows why this is so. The DevOps build toolchain, especially for large codebases, has always been heavily I/O-dependent and storage access has classically been the biggest bottleneck for building an image. The ability to cluster small, inexpensive Linux x86 servers connected to SANs twenty years ago was a first step in separating storage hardware from compute, but I/O latency was pretty awful. Build/link operations could actually take longer than the compilation of object files.

Virtualization helped make hardware utilization better and cheaper but didn’t really improve throughput. Cloud infrastructures such as OpenStack and CloudStack made those infrastructures simpler and more elastic to manage but, again, the IOPs bottleneck remained.

Containerization for DevOps made it even simpler from the applications level—just deploy the app and ramp up container instances as needed—no more dedicated infrastructure needed. And it’s cheaper for incremental functions.

However, not much was done to clear the I/O bottlenecks for largescale storage and increasing overall performance.

When the new nonvolatile memory technology of NVMe came to market in 2014 for the single server world, it delivered two game-changing capabilities.
1. An increase of 5x disk access I/O speed. This was, arguably, the biggest single performance improvement since multicore processors with onboard cache (think Opteron) emerged. With Linux adding support for standard, open source NVMe drivers in 2021, the options increased beyond Windows and Mac users.However, SANs and their protocol stack were still an issue. SATA- and SCSI-based SANS performance was gated to the 1.2GB limitations of those technologies and big iron to head-end the SAN still dictated high-cost infrastructure.
2. Unlike SATA or iSCSI, NVMe has the native capability for TCP/IP or fibre channel addressing. This allows NVMeoF to be an autonomous point for data storage in a normal network. A user can now keep control of their data but use network-attached compute as a utility with roughly 6Gb speed for I/O—greatly lessening the big penalty for disk I/O.
Applying Containers

The dramatic uptick in container deployments and the debut of container attached storage (CAS)—software that includes microservices-based storage controllers that are orchestrated by Kubernetes—represented another industry milestone. These storage controllers can run anywhere that Kubernetes can run, which means any cloud or even bare metal servers or on top of a traditional shared storage system. Critically, the data itself is also accessed via containers as opposed to being stored in an off-platform, shared scale-out storage system.

Since container-attached, cloud-native storage enables the use of small, disaggregated architecture without the need for large-scale SANs or storage controllers dovetails nicely with DevOps work.

Container-based applications can benefit enormously from NVMe-based storage. As experts have pointed out, since DevOps applications are all about scalability, the parallelism embedded in the NVMe spec fits nicely to support them.

While SANs are good for large-scale contiguous operations, they’re expensive chunks of capacity and not nimble to deploy. They’re also bound to the slower I/O storage protocols, which can negate performance gains possible by adding NVMe to that array (as opposed to discretely).

Container-based storage with NVMe gives DevOps teams the opportunity to add storage at low cost with deterministic management of that stateful storage—in theory, of course. In practice, the temptation to add like infrastructure to current infrastructure is powerful, even with all its limitations.

To make that theory a reality, a control plane with the fast data plane is necessary—and the market is beginning to address this need.

As one example, OpenEBS recently introduced an upgraded engine, MayaStor (now part of DataCore Software), which enables use of NVMeoF at impressive speed: Benchmarks with Intel SPDK architecture show a 5x read/write speed improvement over SATA.

OpenEBS debuted a few years back as a containerized storage solution for Kubernetes-based applications. With an optimized storage engine, Kubernetes has the opportunity to perform like other, more specialized hosting and development solutions.

Impact for DevOps

What does this mean for DevOps teams? Firstly, using NVMe in containerized DevOps applications speeds up the time required for large builds, thereby speeding iterations of writing software. It also removes the need for complex and expensive SANs to host build environments. This double whammy of benefits means that development is quicker and cheaper and, in turn, applications can deploy faster while using more flexible tools.

Second, NVMe greatly mitigates I/O concerns for how application code is designed and how environments are implemented. No more being beholden to the storage trunk—NVMeoF drops the performance penalty for I/O ops and distributes traffic across a normal TCP/IP network. This is now a triple whammy—faster, cheaper and more flexible containers built atop a fast, flexible virtualized infrastructure.

Backed by innovations in container-attached storage, DevOps teams can achieve the agility and flexibility that are paramount to its mission—and act as a proving ground for the rest of the IT team to consider alternative paths to greater efficiency and performance.

Join us for KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain (and virtual) from May 16-20—the first in-person European event in three years!
May 12, 2022
The COVID-19 Pandemic’s Lasting Impact on Tech

The COVID-19 pandemic created major opportunities for innovation and ushered in new technology solutions, but even as the danger subsides, this tech may still serve a purpose.

Whether it be face mask detection, temperature checks, facial recognition or AI surveillance, technology crafted to combat COVID-19 is here to stay. This may present a number of benefits, but there are ethical issues that persist.

Throughout the pandemic, school districts sought ways to mitigate the risk of outbreaks and ensure students were complying with safety regulations. AI-empowered cameras, for example, were one of the first pieces of technology implemented, allowing schools to monitor which students weren’t wearing masks.

“I think it’s helpful for COVID-19 stuff, but it seems a little intrusive,” said Noa Young, a 16-year-old junior from Atlanta’s Fulton County school district. “I think it’s strange that we were not aware of that.”

Although students knew cameras were monitoring them, they weren’t informed about the extent of the surveillance. The cameras have the capability to scan for body temperature and can also determine if a student is wearing their mask correctly.

In addition to monitoring for compliance, these cameras have the ability to assist with contact tracing. They can scan students’ faces and determine who they’ve been in contact with, enabling schools to retrace the steps of someone who contracts COVID-19. This is just one example of pandemic tech’s continued development, but as adoption and use spreads to other sectors and it’s used for other purposes, security and privacy concerns begin to pile up.

Courtenay Brown, 31, works in an Amazon warehouse and explained the scrutiny she is under throughout her workdays. Amazon uses similar AI surveillance to keep tabs on worker productivity, notifying management if someone deviates from their assigned task for too long. Many believe this level of surveillance creates an inhumane work environment.

“They basically can see everything you do, and it’s all to their benefit,” said Brown. “They don’t value you as a human being. It’s demeaning.”

The implementation of this technology is one of the factors pushing Amazon workers to take a stand through unionization efforts.

“There’s no way we’re going to stop or let this bring us down,” said Derrick Palmer, co-founder of the Amazon Labor Union. “It’s going to do the complete opposite. We’re going to go 10 times harder.”

Another byproduct of the pandemic was the shift to remote work in organizations across the country and in every industry. This shift created the need for remote access to an organization’s tools, information, data and assets, which didn’t come without inherent security risks—especially since such access often needed to happen literally overnight.

One way companies adjusted was through adoption of identity and access management (IAM) solutions. IAM can be used to identify, record and grant access in the cloud, an integral part of secure functionality in hybrid or remote workplaces.

“In the game of cybercrime cat and mouse, one could argue there is no such thing as being over-resourced. A major breach can bring down a company,” said World Wide Worx CEO Arthur Goldstuck.

Although IAM proved to be a workable solution to the challenge of remote access management, cybersecurity threats are ever-changing and now cyberattackers have shifted focus—they may be attacking IAM solutions.

“Sophisticated threat actors are actively targeting identity and access management infrastructure, and credential misuse is now a primary attack vector,” Gartner described in its Top Security and Risk Management Trends 2022 report.

To keep data safe, companies will have to be ready for an even wider range of cyberattacks, including threats to IAM.

These are just two examples of technological breakthroughs that were originally seen as innovative solutions but which have evolved to have their own set of problems.

May 11, 2022
Red Hat Adds Managed Ansible Service on Azure

Red Hat today announced general availability of a managed instance of the Red Hat Ansible Automation Platform on the Microsoft Azure cloud.

Announced at the Red Hat Summit 2022 event, this offering makes it possible to deploy the control plane for Ansible on the Microsoft Azure cloud as an alternative to existing support for Amazon Web Services (AWS) or an on-premises IT environment.

In addition, in version 2.2 of the Ansible Automation platform, Red Hat is previewing support for content signing technology that automatically validates content to improve overall security.

Thomas Anderson, vice president of Ansible for Red Hat, said this managed service enables IT teams to take advantage of integrated Microsoft billing in addition to the latest features and content provided for the platform and other capabilities that have been added to optimize Microsoft Azure environments.

The open source Ansible platform has been gaining traction as an automation framework that enables IT teams to declaratively automate tasks. It requires less programming expertise than rival automation frameworks, which Anderson said is the primary reason so many third-party vendors have adopted Ansible to automate a range of IT tasks.

The challenge many organizations encounter today is managing multiple islands of automation across multiple clouds and on-premises IT environments. Ansible presents IT teams with the ability to begin unifying all those islands under a single framework, said Anderson.

It’s not clear to what degree DevOps teams that have embraced rival automation frameworks might be willing to replace them with Ansible. However, as more IT teams embrace automation to make up for shortages of IT personnel, it’s apparent that Ansible is being used across a wide range of IT disciplines spanning everything from DevOps to network management.

Regardless of the approach, the need to automate as many tasks as possible is becoming critical as IT environments grow increasingly more complex. Many of the scripts that IT teams created on their own simply don’t scale. More challenging still, they are not often documented, so every time the IT professional that created that script leaves the organization it becomes difficult to maintain that scripting code.

In the longer term, of course, automation frameworks will be increasingly infused with machine learning algorithms capable of learning the unique nuances of individual IT environments. It’s not likely those algorithms will replace the need for IT professionals any time soon. However, rather than resisting automation, more IT professionals have concluded that the tasks required are simply too challenging to manually perform. Many will conclude they simply prefer to work for organizations that have a consistent approach to IT automation that makes it feasible for them to manage a wide range of IT tasks.

One way or another, IT automation is becoming a standard capability that now goes well beyond the scope of a few isolated DevOps workflows. The issue is finding a way for IT professionals with varying skill levels to collaborate across a common framework that is both easily accessible and highly extensible.

May 10, 2022
Twitter/Bluesky ADX Algorithm | Cloud Energy Use ‘Tripled’ | Apple Staff are Revolting

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: Bluesky—Twitter’s research spinout—opens its ADX algorithm, Irish data center electricity worries grow, and Apple employees are the latest to rise up against hybrid working. (more…)

May 5, 2022