Redis Labs and Microsoft Form Strategic Partnership

Redis Labs announced a strategic agreement with Microsoft to deliver Redis Enterprise as new, fully integrated tiers of Azure Cache for Redis. The offering, initially available in Private Preview at the time of announcement, extends the standard Azure Cache for Redis service with enterprise-grade capabilities designed for mission-critical, large-scale workloads.

The partnership positions Redis Enterprise not as a separate product customers must manage independently, but as first-class tiers embedded directly within the Azure Cache for Redis experience — meaning procurement, billing, and management all flow through the familiar Azure portal.

What the Enterprise Tiers Add to Azure Cache for Redis

Standard Azure Cache for Redis is built on open-source Redis. The new enterprise tiers layer Redis Enterprise on top, unlocking capabilities that are not available in the open-source distribution:

• Redis on Flash: Extends the Redis dataset beyond DRAM by tiering data across NVMe SSDs, enabling terabyte-scale datasets at costs comparable to disk-based datastores.
• Redis Modules: Native support for purpose-built data models including probabilistic data structures, time-series, full-text search, and streams.
• Active geo-replication: Planned support for active-active, geo-redundant cache configurations suited to hybrid-cloud and multi-region architectures.
• Up-to-date Redis versions: Access to the latest Redis releases, including native data structures not yet available in older managed tiers.

Key Benefits for Azure Customers

Improved Developer Productivity

Because the enterprise tiers integrate directly into the Azure Cache for Redis interface, developers can provision a Redis Enterprise cluster within minutes using tools and workflows they already know. Native integration with other Azure services means applications can consume Redis Enterprise without requiring significant architectural changes.

Greater Resiliency, Security, and Compliance

The enterprise tiers come with stronger SLAs backed by Redis Enterprise’s active geo-replication technology, which maintains multiple active dataset replicas across regions. Network isolation support helps organizations meet security and compliance requirements for sensitive workloads.

Simplified Procurement and Lower Total Cost of Ownership

Redis Enterprise consumption is billed as part of the customer’s standard monthly Azure invoice, removing the need for a separate vendor relationship. Consumption-based pricing allows teams to scale their Redis footprint in real time, potentially reducing over-provisioning costs compared to fixed-capacity deployments.

Why This Matters: Moving Mission-Critical Workloads to Azure

For organizations migrating on-premises databases to the public cloud, a fully managed, enterprise-grade caching layer with strong SLAs and geo-redundancy addresses one of the most common concerns: data resilience and latency at scale. Redis on Flash in particular is relevant for teams whose datasets are too large to hold entirely in DRAM but still require low-latency access patterns that disk-based databases cannot match.

The active geo-replication roadmap item is especially significant for hybrid-cloud architectures, where a single cache cluster must serve both cloud-native and on-premises consumers with consistent, low-latency reads and writes.

What the Companies Said

“The new enterprise tiers of Azure Cache for Redis fulfills the desire we hear from customers for a fully managed cloud data store that provides significant cost savings for large datasets and the greatest simplicity to consume Redis Enterprise with the confidence and resilience they need from their data layer as they move to Azure.”

— Ofer Bengal, CEO and Co-founder, Redis Labs

“The integration with Redis Labs underscores Microsoft’s vision for a successful cloud and open source collaboration that serves the needs of developers and supports the open source ecosystem for continued innovation. We believe the new enterprise tiers of Azure Cache for Redis will help companies deliver their most critical applications with scale, high availability, and low latency.”

— Julia Liuson, Corporate Vice President, Developer Division, Microsoft

Availability

At the time of announcement in May 2020, the enterprise tiers of Azure Cache for Redis were available in Private Preview. Organizations interested in early access were directed to contact Redis Labs or Microsoft through their respective Azure and enterprise sales channels. General availability timelines were not disclosed in the original announcement.

Check the Azure Cache for Redis product page for current tier availability and pricing, as the service has continued to evolve since this announcement.

Overview

When COVID-19 lockdowns began in early 2020, IT professionals did not stop learning — they accelerated. According to data published by MeasureUp, a global provider of practice tests for ICT certifications and an official partner of Microsoft, VMware, and others, demand for digital skills training surged sharply in the weeks following national states of emergency. The leading areas of interest were cloud computing, cybersecurity, and web programming, alongside growing interest in artificial intelligence and big data.

Why These Technologies Saw a Spike

The shift to remote work created immediate, practical demand for skills that support distributed infrastructure and digital operations:

• Cloud computing became essential for organisations moving workloads off-premises and enabling remote access to business systems.
• Cybersecurity grew in urgency as expanded attack surfaces — home networks, personal devices, VPNs — exposed organisations to greater risk.
• Web programming and digital presence became a lifeline for businesses that previously operated solely in physical spaces and needed to pivot online quickly.

Top Cloud Computing Certifications in Demand

Microsoft Azure certifications dominated MeasureUp’s best-seller lists during the lockdown period. The most popular titles included:

• Microsoft Azure Fundamentals (AZ-900) — an entry-level certification covering core cloud concepts, widely used as a starting point for professionals new to cloud platforms.
• Microsoft Azure Solutions Architect (AZ-300)
• Microsoft Azure Architect Design (AZ-301)
• Microsoft Azure DevOps Solutions (AZ-400)

Amazon Web Services (AWS) certifications also featured prominently:

• AWS Certified Solutions Architect
• AWS Certified Developer

The strong showing of AZ-900 in particular reflects how many professionals used the lockdown period to establish foundational cloud literacy before pursuing more advanced credentials.

Cybersecurity Certifications Gaining Traction

Alongside cloud skills, cybersecurity certification demand rose in direct response to the heightened threat environment of remote work. The most-requested cybersecurity exams on the MeasureUp platform included:

• CompTIA Cybersecurity Analyst (CySA+) — focused on threat detection, analysis, and response.
• CISSP (Certified Information Systems Security Professional) — a senior-level credential covering security architecture and management.
• CompTIA Security+ — an industry-standard entry-level security certification widely recognised by employers.

Web Programming: HTML, C#, and .NET

An emerging and somewhat unexpected trend in the lockdown data was increased demand for web programming skills. Technologies including HTML, C# (C-Sharp), and .NET saw notable upticks, driven by businesses that needed to rapidly build or improve their online presence. For many traditionally offline businesses — retail, hospitality, professional services — digital transformation went from a medium-term strategy to an immediate operational necessity.

AI and Big Data: A Growing but Secondary Trend

Practice tests related to Artificial Intelligence and Big Data also showed increased sales during the lockdown period. Microsoft technologies were noted as particularly prominent within this category, though specific certifications were not detailed in the original report.

Who Was Training? Learner Demographics

MeasureUp analysed the profiles of professionals who engaged in training activities during the COVID-19 crisis. Key findings from their platform data:

Age Distribution

• ~60% were professionals aged 25–44
• 16% were under 25 years old
• 4.61% were aged 65 and over — a notable segment, suggesting lockdown motivated older professionals and retirees to upskill

Gender Split

• 75% male
• 25% female

The gender imbalance reflects the broader demographic reality of the ICT certification market, though it also underscores the ongoing need for greater inclusivity in technical training pathways.

Geographic Origin (Top 10 Countries)

Learners from all five continents participated, reflecting MeasureUp’s global reach, though the English-speaking market dominated the figures.

Remote Exam Delivery: A Critical Enabler

A key factor enabling certification activity during lockdown was the widespread adoption of remote proctoring by major certification bodies. Vendors including Microsoft, Cisco, VMware, AWS, CompTIA, PMI, and Oracle all offered candidates the ability to sit official exams from home, removing the dependency on physical test centres that had temporarily closed. This made the complete training-to-certification pipeline accessible entirely online for the first time at scale.

About MeasureUp

MeasureUp is a product of Media Interactiva, a technology and educational content group headquartered in Tomares, Seville, Spain. The company reports training more than 400,000 people annually in digital skills. MeasureUp operates as the exclusive practice-test provider for Microsoft and also supports AWS, Cisco, CompTIA, Oracle, PMI, and VMware certification programmes, offering over 200 titles.

Practice tests on the platform can be used in two modes:

• Certification mode — simulates exam conditions as closely as possible.
• Practice mode — allows learners to review explanations and focus on weaker areas.

Media Interactiva has been listed in the Financial Times FT 1000 ranking of Europe’s fastest-growing companies and holds ISO-20000 certification for IT service management quality.

Key Takeaways for IT Professionals and Training Teams

• The pandemic accelerated pre-existing trends toward cloud and security certification — not created them from scratch.
• Entry-level cloud credentials (such as AZ-900) saw strong uptake, indicating many professionals used the period to formalise existing knowledge or begin a cloud learning path.
• Remote proctoring removed a significant barrier to certification and is likely to remain a standard option post-pandemic.
• Demand for web development skills alongside infrastructure and security credentials signals that full-stack digital capability is increasingly valued across roles.
• The 65+ age group engaging with ICT certification training, while small, is a meaningful signal about the broadening appeal of lifelong technical learning.

Overview

As COVID-19 forced millions of knowledge workers into remote work arrangements in early 2020, GitHub’s data science team examined how the shift was affecting developer behavior on the platform. Their analysis of activity during the first quarter of 2020 revealed patterns that have significant implications for engineering teams, engineering managers, and DevOps practitioners thinking about sustainable delivery practices.

Overall Activity Held Steady — or Increased

Despite the disruption caused by shelter-in-place orders and sudden transitions to remote work, GitHub’s data showed that developer activity during the first three months of 2020 was “largely consistent or increased” compared to the same period in 2019. On the surface, this might suggest business as usual. But a deeper look at the data reveals important nuances in how that work was getting done.

Enterprise Issue Activity Tracked Outbreak Timelines

One of the more striking findings was the correlation between COVID-19 outbreak timelines and GitHub issue activity in enterprise repositories. According to the report:

“Our analysis shows that GitHub issues in enterprise repositories rise and fall around COVID-19 outbreaks and shelter-in-place orders. The flux seen in issues is likely due to the move to distributed work, which disrupted the ceremony, structure, and coordination of enterprise software development. On GitHub, that coordination is often done with issues, where teams track enhancements, tasks, and bugs.”

This is a meaningful signal for DevOps teams. Issue trackers serve as a coordination layer for distributed teams. Spikes and drops in issue activity can indicate teams struggling to establish new remote communication norms — or, conversely, teams adapting to async collaboration tools more effectively over time.

Work Days Got Longer

GitHub’s analysis also found that developers’ working days had grown — by up to an hour per day, on both weekdays and weekends. The report acknowledged that longer days are not purely a measure of increased productivity:

“Longer days may also be a result of non-work interruptions (like family or childcare) now that many are working from home.”

This is a critical distinction. Raw commit volume or hours logged does not necessarily translate to productive engineering output. Interruptions from caregiving responsibilities, anxiety about the pandemic, and blurred home-office boundaries all fragment concentration and inflate wall-clock time without proportionally increasing meaningful work.

The Pressure Behind the Numbers

GitHub’s report identified several factors that may have been driving the increased push frequency observed in the data, particularly in March 2020:

• Economic uncertainty: Fear of layoffs or reduced hours may have prompted developers to signal productivity through higher commit volume.
• Work as distraction: Staying busy with coding as a coping mechanism during an anxiety-inducing lockdown period.
• Management pressure: Organizational urgency to ship products in a volatile market.
• Team delivery norms: Expectations around frequent commits as a marker of a healthy, fast CI/CD pipeline.

Understanding these motivations matters for engineering leadership. If increased commit frequency is driven by fear rather than improved process, it can mask underlying team health problems and inflate metrics that teams use to evaluate delivery performance.

Burnout Was Already Rising

GitHub’s findings aligned with concurrent survey data on burnout in the technology workforce. A survey by Blind conducted around the same period found that 73 percent of technologists reported burnout by the end of April 2020, up from 61 percent in mid-February. Among those reporting burnout:

• Approximately 20.5 percent attributed it to an unmanageable workload.
• Approximately 19 percent attributed it to concerns about job security.

It is worth noting that remote work and burnout had a documented relationship even before the pandemic. A 2019 DigitalOcean survey found that 66 percent of technologists working from home reported burnout, compared to 64 percent who worked regularly in an office — a gap that, while small, pointed to additional stressors unique to remote work arrangements.

GitHub’s Own Caution: Longer Hours May Not Be Sustainable

The GitHub report itself included a direct warning about the sustainability of the trend:

“If additional work is happening at the expense of personal time and breaks to replenish, ponder, and maintain healthy separation, we caution this tradeoff may not be sustainable in the long run.”

This is a point well worth heeding for engineering managers designing team processes during distributed work. Delivery velocity metrics like deployment frequency and commit rate can improve in the short term even as engineer wellbeing deteriorates — until attrition, quality issues, or health events force a correction.

Practical Takeaways for DevOps and Engineering Teams

While the GitHub report was a snapshot of early 2020 conditions, the questions it raises remain relevant for any team managing distributed engineering work:

• Monitor leading indicators of burnout, not just delivery metrics. Cycle time, PR review lag, and unplanned work can surface team stress before it becomes a retention problem.
• Distinguish coordination overhead from productivity loss. A spike in GitHub issues may reflect teams adjusting to async communication, not failing to deliver.
• Protect psychological safety. If engineers feel that longer hours are expected or that commit frequency signals job security, engineering culture — not individual discipline — is the thing to address.
• Re-evaluate meeting and ceremony cadences for distributed teams. The pandemic forced many teams to redesign standups, retrospectives, and planning sessions; those lessons remain applicable to any remote-first or hybrid team.
• Use DORA metrics thoughtfully. Deployment frequency and change failure rate are better health indicators than raw commit volume or hours online.

Context and Limitations

GitHub’s analysis covered only the first quarter of 2020 — the very beginning of pandemic-era disruption. At that point, many businesses in the United States and elsewhere were only just implementing work-from-home policies. The longer-term effects on developer workflows, team culture, and software delivery quality would only become visible over subsequent quarters.

Additionally, GitHub’s data reflects activity on its platform specifically and may over-represent open source contributors and enterprise teams using GitHub as their primary development platform. Teams using GitLab, Bitbucket, or internal source control systems would not appear in this data.

Nonetheless, the 2020 GitHub analysis remains a useful reference point for understanding how large-scale external disruptions propagate into observable patterns in software development activity — and why engineering leaders need measurement strategies that go beyond raw throughput.

The Security Gap That Containers and Kubernetes Are Creating

The rapid adoption of containers and orchestration platforms like Kubernetes is outpacing the security practices designed to protect them. According to research from the Cloud Security Alliance (CSA) presented at RSA Conference 2020, development and operations teams are deploying containerized workloads at scale — but many organizations have not yet adapted their security models to match the complexity this creates.

John Yeoh, Global Vice President of Research at the CSA, summed up the core tension: segmenting applications into containers and microservices delivers clear functional and scalability benefits, but it simultaneously multiplies the number of components that must be secured and made compliant.

“As we have seen with the use of containers and micro-services and compliance, when you further segment things off, there’s a functionality benefit from that. But you also have a lot more pieces to secure or to make compliant. So the challenge is how do we grant proper access control to containers and micro-services? How do we make these environments compliant?”

— John Yeoh, Global VP of Research, Cloud Security Alliance

Why Access Control Is the Central Problem

Containers are designed to be lightweight, portable, and numerous. In a busy Kubernetes cluster, dozens or hundreds of containers may run simultaneously across many nodes. This creates a sprawling attack surface where default configurations — including default security settings and default access controls — may be far more permissive than the sensitivity of the data being handled requires.

Yeoh points to a specific and well-documented attack pattern: an adversary compromises one container and then pivots laterally to others within the same cluster. Over-provisioned permissions — whether through misconfigured Role-Based Access Control (RBAC) policies, exposed Kubernetes API servers, or overly broad service account tokens — are frequently the enabler.

“We see breaches and incidents all the time when it’s compromised credentials or something really silly like, ‘Why does the attacker have that much access when they penetrate one environment?’ If we can address that and limit that, we’re going to be much better off.”

— John Yeoh, Cloud Security Alliance

Common Access Control Failures in Container Environments

• Overpermissive RBAC policies: Granting cluster-admin or broad namespace access when narrower roles would suffice.
• Default service account tokens auto-mounted: Kubernetes mounts service account tokens by default; many workloads that don’t need API access still receive it.
• Unrestricted inter-pod communication: Without Network Policies, every pod can reach every other pod in a namespace.
• Exposed Kubernetes API server: Publicly reachable API endpoints without strong authentication have been exploited in documented incidents.
• Secrets stored in plain text: Credentials embedded in container images or environment variables rather than managed through a secrets manager.

Shifting Security Left: Building It Into the Development Cycle

The CSA’s position — consistent with the broader DevSecOps movement — is that security must be addressed as early as possible in the software development lifecycle, not bolted on after deployment. Yeoh describes a model where automated checks are embedded directly into CI/CD pipelines, and where code with security problems can be rolled back before it ever reaches production.

“You are also able to automate a lot of these [checks] as well, and you can almost create a self-healing architecture, where it rolls back, is fixed and then moves forward. We’re seeing more and more people do that in cloud environments. It’s a way to make sure that developers are held accountable.”

— John Yeoh, Cloud Security Alliance

In practical terms, this means integrating tooling at several stages of the pipeline:

• Image scanning: Scanning container images for known CVEs before they are pushed to a registry (tools such as Trivy, Clair, or Snyk Container).
• Static analysis: Linting Kubernetes manifests and Dockerfiles for security misconfigurations (tools such as kube-score, Checkov, or Kubesec).
• Admission controllers: Using Kubernetes admission webhooks (e.g., OPA/Gatekeeper, Kyverno) to block non-compliant workloads from being deployed to the cluster at all.
• Runtime security: Monitoring container behaviour at runtime to detect anomalous system calls (tools such as Falco).
• Automated rollback: GitOps workflows that can detect a failed or insecure deployment and roll back to a known-good state automatically.

Compliance in a Containerized World

Container environments present compliance teams with a challenge that traditional VM-based infrastructure did not: workloads are ephemeral. A container may run for seconds or minutes and leave no persistent audit trail unless that logging is explicitly configured. This makes meeting the audit and data-residency requirements of regulations such as the California Consumer Privacy Act (CCPA) and the New York SHIELD Act — both discussed at the CSA’s RSA 2020 sessions — significantly more complex.

Attorney Aravind Swaminathan, Global Co-Chair of the cyber, privacy and data innovation practice at Orrick Herrington & Sutcliffe LLP, highlighted a broader issue for organizations moving to cloud: users and organizations do not own the underlying infrastructure, which changes the risk model fundamentally.

“There’s tons of value in the cloud, but you have to understand the risks. We have recently seen individuals compromise the cloud environment when we thought we had protections like multifactor authentication and certain controls, and attackers were able to make end-runs around those. And that’s the challenge.”

— Aravind Swaminathan, Orrick Herrington & Sutcliffe LLP

Practical Recommendations for DevOps and Security Teams

Based on the challenges identified by the CSA and the speakers at RSA 2020, the following practices reflect the direction the industry is moving:

1. Apply least-privilege RBAC: Audit every Kubernetes role and cluster role binding. Grant only the permissions a workload genuinely needs.
2. Disable auto-mounting of service account tokens on pods that do not need to communicate with the Kubernetes API.
3. Implement Network Policies: Default-deny all ingress and egress traffic, then explicitly allow only required flows.
4. Scan images before deployment: Block images with critical or high CVEs from reaching production registries.
5. Use a secrets management solution: Avoid embedding credentials in images or manifests; use a dedicated secrets store integrated with your cluster.
6. Enable audit logging: Kubernetes audit logs and container runtime logs should be shipped to a centralized, tamper-resistant store for compliance and incident response.
7. Adopt a DevSecOps pipeline: Make security gates part of CI/CD so that developers receive fast feedback and policy is enforced consistently.
8. Plan for regulatory requirements early: Map data flows through your containerized architecture to understand where regulated data lives and how ephemeral workloads affect audit trails.

The Road Ahead

The security challenges that containers and Kubernetes introduce are not insurmountable, but they do require a deliberate shift in how security is resourced and when it is applied. The CSA’s research presented at RSA 2020 reflects a consensus view that is still relevant today: security teams must evolve from gatekeepers who review finished applications to engineers who build security requirements directly into the development process. Self-healing pipelines, automated compliance checks, and granular access control are no longer aspirational — they are operational requirements for any organization running containerized workloads in production.

Original reporting by BankInfoSecurity. Cloud Security Alliance research was presented at RSA Conference 2020, San Francisco.