Cisco has announced new ways it is helping customers accelerate digital transformations as they move more resources to the cloud. The hyper-connected, distributed world we live in now relies on cloud more than ever, and IT teams are facing challenges to provide people with optimal digital experiences wherever and whenever they need access. As a result, businesses are migrating to a cloud-driven operational model based on speed, insight, and control to bridge the greater distribution of applications, users, and tech staff.

Enabling customers to realize better outcomes from the cloud

Cisco has made multibillion-dollar investments over the past six years to build cloud into every aspect of its business, focusing on helping customers develop complete cloud strategies with confidence across five key areas: Continuity, Insights, Security, Connectivity, and Operations.

During today’s virtual ‘Future Cloud’ event, the company will showcase how it is advancing its cloud strategy across several of these areas to help businesses connect, secure, and automate to deliver seamless digital experiences in today’s hybrid cloud world.

“User experience is key to success in a digital world,” said Todd Nightingale, SVP and GM, Enterprise Networking and Cloud, Cisco. “We are focused on empowering technology groups to securely deliver the best possible application experiences. Only Cisco can power the hybrid-cloud solutions, observability, insights and automation necessary to be truly cloud smart.”

New hybrid cloud innovations announced today include:

§ Hybrid Cloud Operations:

o Introducing the new Cisco UCS X-Series: Cisco’s Unified Computing System™ (UCS) is used in data centers by more than 50,000 customers worldwide. Fully integrated with Cisco Intersight, UCS X-Series is a first-of-its-kind system designed for hybrid operations from the cloud and across the clouds. Blending the best of rack and blade systems and featuring revolutionary UCS X-Fabric technology, it’s built for workload versatility today and comes future-ready for the next decade of industry innovation in processors, accelerators, and computing interconnects.

o Intersight Cloud Orchestrator: Provides a low-code, easy-to-use automation framework that simplifies complex workflows, so IT Ops can easily orchestrate infrastructure and workloads and accelerate delivery of services.

o Intersight Workload Engine: A powerful platform for modern, cloud native workloads. Built on an open-source Kubernetes and Kernel-based virtual machine (KVM) foundation using container-native virtualization, Intersight Workload Engine is a Cisco operating system for HyperFlex™, featuring consistent SaaS management.

o Cisco Service Mesh Manager: A new extension to the Intersight Kubernetes Service, bringing deep observability and simplified management with policy-based security and intuitive visualization of services topologies across K8s clusters on-prem and in the cloud.

o Cisco Cloud ACI: Available on AWS, Azure, and now on Google Cloud with general availability in the Fall of 2021. The Cloud ACI® common policy and operating model drastically reduces the cost and complexity of managing hybrid and multicloud deployments.
a

§ Observability and Insights:

o Integration of ThousandEyes Internet and Cloud Intelligence with the Cisco Catalyst® 8000 Edge Series for SD-WAN and Cisco Nexus® 9000 switches for data centers to provide customers with valuable insights on network health and application performance by monitoring across campus, branch, data centers, and every point of the WAN network between the user and applications.

o Nexus Dashboard Orchestrator acts a single pane of glass for configuring and managing common policies across multiple on-prem ACI sites, AWS and Microsoft Azure regions, and, announcing today, coming this fall to Google Cloud.

o Intersight Cloud Orchestrator: Provides a low-code, easy-to-use framework to create and automate complex workflows, so IT Ops can easily orchestrate infrastructure and workloads and accelerate delivery of services.

§ Customer Experience (CX) Services for Cloud

o CX Business Critical Services for Cloud provide advisory services plus expertise to architect, deploy, secure, and optimize digital transformations.

o CX Intersight Workload Optimizer Services enhance the resource consumption of applications in the cloud.

o CX Advanced Services for Thousand Eyes and SD-WAN deliver the best application experience for cloud solutions, providing expert design and integration to reduce project complexity and speed transformation.

o Custom Quick Start Solutions provide expert services for end-to-end automation and infrastructure-as-code (IaC).

In a recent ThinkLab Clubhouse session, Sascha Wagner, president and CEO of Huntsman Architectural Group, shared this insightful remark about the future of remote work: “We believe in the power of place. This speaks to the idea that space can do more than fulfill functional needs—it helps convey values, bring people together, and empower a sense of cohesion and belonging. What’s more, space can actually become part of the cultural manifest of an organization. So, while the past year has shown us that we can positively embrace remote work, we are confident that group activities, visual and tactical work, and work that relies on an in-person sense of connection will continue to thrive in the built environment.”

His sentiments are supported by a recent study by PWC, which shares that by July 2021, “75 percent of executives anticipate that at least half of office employees will be working in the office.” So, if the future is hybrid work, what will that look like? And how do we balance human connection with function—or, perhaps more accurately, flexibility—that comes with hybrid work? We sat down with Betsy Bula, all-remote evangelist at GitLab, to discuss why hybrid work can be one of the most difficult working arrangements, and to uncover tips on how best to make the transition successful.

Recognize that a hybrid policy is the hardest.

While few companies plan to require all workers back in the office five days per week, and few are ready to continue a fully remote model forever, hybrid is actually the toughest model to balance. Bula shares that hybrid work is that in-between zone that often times blurs the lines and rules of traditional office decorum. It is very easy to prioritize those in the office—to give them more senior leadership exposure, allow them more opportunities for mentorship, and think of them first when you’re looking to handle an impromptu job request.

As she explains, “Hybrid work takes more intentionality to do it well. You must realize that you are responsible for managing different employee experiences, while being cognizant to avoid a two-tier environment where people in the office are considered a different class than people working remote.”

So, to avoid this uneven playing field, Bula shares that asynchronous communication is key to success.

Leveraging asynchronous communication is key.

In telecommunications, asynchronous communication refers to transmitting data intermittently, instead of continuously. Usually, this takes place without the use of an external clock signal. Transitioning that logic to the working world, we liken the external clock signal to the ability to get information from anywhere. In a synchronous-communication work model, a lot of emphasis is placed on working in the same place at the same time. Team members are given information in a team meeting, and then they all break away to do their work.

But in an asynchronous-communication work model, all direction is properly documented so workers can accomplish tasks wherever they are, whenever they are there. In GitLab’s 2021 Remote Work Playbook, it explains asynchronous communication like this: “In a world dictated by calendars and schedules, people are used to working synchronously—meaning that they need to be in the same place (either physically or virtually) at the same time. Another word for synchronous work: ‘meetings.’ Asynchronous communication is the art of eliminating meetings and synchronous work, making it possible to get work done on a flexible schedule.”

And although asynchronous communication allows distributed teams to hand projects off across time zones—a distinct competitive advantage—and reduces disconnects and frustrations, it also takes a lot of intentionality to do so.

Bula explains that it’s important to “try to focus on how work will get done and how your team will work together. When doing so, try to remove the location from the equation as you are thinking through that. That way you will naturally build practices that can be used no matter where your work is getting done on any given day.”

Intentionally define your culture.

Our industry does a great job of defining culture through physical space, but do we ever document our own business culture? According to Bula, combining documentation with intentionality is crucial to a successful approach. She agrees with Wagner that the office is a great place for bringing people together and speaks about the value of a project kickoff or other team bonding experience that unites everyone. Then, when the work is transitioned to a hybrid team, these steps from GitLab can help make it successful:

1. Define a culture that supports equality between remote and in-person work. One of the best ways to do this is to have senior management experience working in the remote model. Do they have communication barriers? What documentation isn’t clear? Are there any access issues?

2. Don’t try to replicate an in-person experience remotely. There are some things that just can’t be done remotely. Hosting meeting after meeting over Zoom is a recipe for Zoom fatigue. Instead, try to be strategic about meetings—if they are needed for hands-on, tactical teamwork, consider coming in to the office. If not, ask yourself if the meeting is really necessary.

3. Place an emphasis on team building. Even teams working 100 percent remotely need to come together to foster team camaraderie. GitLab suggests planning events such as coworking excursions, setting a travel budget for team members to visit one another, and even hosting local coworking days.

The GitLab playbook offers more helpful suggestions. After all, at the end of the day, Bula reminds us that the past year and a half of remote work, while mostly successful, hasn’t been a true representation of authentic hybrid work.

She concludes, “What a lot of people thought they experienced as remote work was really forced working from home due to a global pandemic. Companies that weren’t already working remotely had to transition to a remote work strategy overnight. And while society did an amazing job of adapting, the intentionality and process that takes time to develop wasn’t there. So, as leaders determine what the future of work looks like for their teams, the key to success will be creating, documenting, and iterating on these practices to determine what works best for their organization.”

What does low-code mean, and who is it really for?

Over the last few years, I’ve seen many articles associating “low-code” with “citizen developers” or with people who don’t have deep development skills. Users can arrange visual elements, or fill in forms with key information and publish the result as an application.

But tools for citizen developers are only one part of the low-code story. There is also a growing number of tools for professional developers, and I want to talk about those, too.

Both citizen developers and professional developers have a role to play in application development and automation projects, and low-code has something to offer both of them.

Low-code is Not a Market, it’s an Approach
Low-code does mean providing visual and graphical tools and simple frameworks that mask more complex coded operations, so the application designer does not have to directly touch the code that performs desired operations. These apps are naturally limited, as the resulting application can’t be highly customized if you can’t touch the code.

With these kinds of visual tools, anyone can create a simple application within the limits of the tool. But when we pull back and look at what is needed to create larger, more complex applications – ones that need to communicate with other enterprise systems, or need extensive customization, or cross organizational boundaries, or need to pay attention to governance requirements, for example – the visual-only approach is frequently insufficient. In complex cases, developer expertise is often needed, and developers have to get “under the hood” to tinker with code.

There is no “low-code market.” We are bringing tools to people who need them to develop specific projects. A comprehensive low-code approach to application development and automation means offering both visual programming and coding capability. For usability reasons, these tools are clearly separated and presented to the development team in a way that allows citizen developers to work on certain elements and developers to work on others, all on the same platform.

We know that it’s possible to serve professional developers with low-code, too. A low-code approach also includes drag-and-drop tools that developers can use – for example, to develop APIs, or to integrate the application with other systems, or to customize front-end interfaces. Of course, when code is required, developers should be able to use their own tools and frameworks and not be limited by low-code tools. Platforms that offer a hybrid approach are likely to be most useful to mixed-skills development teams.

The Hybrid Approach
Strictly low-code tools can serve simple automation use cases. More broadly, automation platforms offer a hybrid of low-code and coding capabilities for more complex automation use cases.

For critical enterprise applications, both business and developer inputs are usually needed. Having tools for both of them means not leaving anyone out.

Low-code tools will continue to become more mainstream. Low-code is not a fad or a passing trend, but a quiet revolution that will see greater incorporation into more business tools.

As automation platforms and other low-code tools mature, a greater number of people are getting used to working with them. Developers are less hesitant about incorporating non-developers into their teams, as everyone gains a better understanding of the benefits of these platforms.

The younger generations entering the workplace today are digital natives. They are fearless about diving into technology and working hands-on. So, these low-code tools are ready for them, and they are ready to put them to work.

Low-code is breaking down technical barriers to work in the automation space, making smooth collaboration between business and development easier.

Low-Code Can Be a Double-Edged Sword
Automation and development teams are also becoming more aware of vulnerabilities and compliance issues as citizen developers roll up their sleeves and join the technical team.

Low-code tools are a double-edged sword. They facilitate teamwork, but issues with security and data governance may not be top-of-mind for non-developers. If you have a big team working on automation and/or application development and delivery, the need to build in governance becomes even more important.

Using a shared platform will help manage and mitigate these issues with security and governance. This will become even easier as the platform tools evolve and mature, so DevOps teams can use them to help mitigate some of these issues.

Does Low-Code Have a Place in DevOps?
We are definitely seeing the impact of low-code on development environments and DevOps. Remember, low-code started with small applications, and while DevOps-style teamwork and workflows may not be needed there, as the use of low-code platforms becomes the norm for critical enterprise projects, DevOps will be a necessary part of the mix. This is where low-code is having a more obvious impact; Agile methodologies using low code platforms for iteration, for continuous improvement and for continuous delivery. These applications aren’t one-and-done. They need to be maintained, improved and delivered, again and again.

Prolifics, a global digital transformation leader is proud to announce that we now can help enterprises manage their applications across multiple cloud environments with IBM Cloud Satellite. IBM Cloud Satellite, now generally available, enables clients to run IBM Cloud services on any cloud, on premises, in multicloud environments or at the edge – all delivered as a service. This flexibility will help bring cloud capabilities to where client data resides, in the environment of their choice, while focusing on consistency, user experience, and security.

With its open architecture, IBM Cloud Satellite builds on IBM’s deep industry expertise and can help enterprises across a variety of industries including telecommunications, healthcare, banking, insurance, travel and transportation, transform into digital-first organizations. The need to modernize mission-critical workloads is intensifying. According to a recent IBM Institute for Business Value report, 74% of CEOs interviewed during the COVID-19 pandemic believe cloud computing will most help their organization deliver these results over the next 2-3 years. We see a cornerstone of this transformation is in edge computing. The continued proliferation of edge devices is expected to shift the amount of data that resides at the edge compared to within central data centers. As this transition takes place, IBM Cloud Satellite is designed to bring cloud services to where clients’ data already resides — and help them bridge to where they want to go.

Prolifics is part of IBM’s ecosystem of partners fueling hybrid cloud deployments by helping clients modernize applications and manage workloads on infrastructure ranging from bare-metal to multicloud and everything in between using Red Hat OpenShift, the industry’s leading enterprise Kubernetes platform. IBM Cloud Satellite is engineered to give clients the flexibility to bring their applications to environments where their data resides while leveraging the security of IBM Cloud.

Satya Bolli, Prolifics Chairman & Managing Director, said, “Modernizing applications to enable our clients to become faster, more agile, and more creative is what we do. Deciding the right platform for the right application workloads is a critical part of the equation. We see IBM Cloud Satellite as a game changer for our clients who want an enterprise grade option to bring the convenience of a cloud experience into the control of their own data center.”

Greg Hodgkinson, Prolifics Chief Technology Officer, said, “In the Prolifics Innovation Center, we’ve crafted more than 20 of our solutions using OpenShift and the Cloud Paks as our solution platform, ensuring flexible deployment models and simplified operations across cloud infrastructure. These solutions span verticals such as healthcare and banking, and horizontals such as data science, Hyperautomation, data privacy, DevOps and testing. IBM Cloud Satellite can help us deliver this solution platform as a service across an infrastructure of our client’s choosing, enabling us to roll out our solutions with Cloud Paks quicker and more efficiently. We believe this will improve availability to users, free-up capacity in our client’s operations team, and lower long-term cost of ownership.”

Data security is significant for any college. Colleges regularly limit access to private information except if the users are approved. Simultaneously, in some cases, they need the flexibility to rapidly give certain offices access to the confidential information. At the point when the information is stored in a conventional, in-house datacenter, departments need IT’s support to change permissions for clients and groups. With the cloud, however, college administration can use user roles to rapidly give access to documents without calling the IT.

A few institutions intend to alleviate COVID-19 risks with abbreviated calendars and caps on class size, while others, similar to The California State University, say they’ll deliver the majority of its classes online. Whatever decision universities take, higher education seems ready to animate the speed of cloud adoption, both to support near-term activity and to build nimbleness to withstand future difficulties.

This into-the-cloud pattern is explored in another Forrester Consulting report, “HPC And AI in The Cloud: A Spotlight on Higher Education.” In this report covered by CIO, authorized by Dell Technologies and Intel, Forrester noticed that in a worldwide survey of IT decision-makers in higher education foundations, it discovered a developing interest in running HPC and AI workloads in hybrid cloud environments.

As of now, about a fourth of the respondents utilize public and private clouds to run HPC or AI workloads, Forrester says. Within the next year, there will be a reasonable move to the cloud. The survey reported that 31% of respondents intend to run HPC services in the public cloud and 35% of respondents intend to run AI and ML workloads in private clouds. This move is generally determined by a desire to improve overall infrastructure use and effectiveness, Forrester says.

A large part of the consideration on AI in higher ed education has been centered around its student-facing uses. That is mostly in light of the fact that schools have been able to utilize it to gain ground on a wide scope of objectives, from lessening summer melt through chatbots to teaching students Mandarin with AI-controlled simulations.

To alleviate the financial hit from the pandemic, colleges are evaluating cloud solutions, especially Software as a Service, to wipe out duplications. For instance, one choice is to relocate out of a paid storage solution and into one that is free or accessible under the current agreement.

Simultaneously, leaders will gauge the number of changes they need to impose on staff and workforce who are as of now adapting to a radical digital transformation. If users are committed to a specific solution, leaders may decide to hold it.

Despite the fact that HPC and AI services are generally run on-premises today, next year there will be a move towards more public and private cloud use. Driven by a want to enhance infrastructure utilization and efficiency, most universities in the future will work with an environment that includes on-premises and cloud options.

Adoption of the cloud is likewise acquiring speed in research. Google and Amazon Web Services (AWS) each dedicated $20 million worth of credits for researchers examining COVID-19, and Microsoft has pledged cloud computing resources to test and vaccine development initiatives.

It’s not just that teams are deciding to keep a few applications on a non-cloud foundation. IT teams are settling on infrastructure choices dependent on a bunch of business and application prerequisites. Furthermore, the reality is that HPC and AI workloads running in hybrid environments will prompt a huge number of business benefits that can assist companies with conquering the difficulties inborn in cloud relocation, while additionally giving profits for initial investments.

With everything taken into account, it bodes well for colleges to join the cloud revolution as they acquire huge flexibility, effectiveness, and financial benefits in doing as such. Colleges who haven’t yet made the transition can gain so much from the institutions who have. Harvard University is another illustration of how one of the world’s top learning and research foundations saw that it was so risky to depend on on-premise infrastructure. They chose to move to AWS, tackled their migration challenges and guaranteed uptime with 100% certainty.

Today, many companies are facing a strong push towards the cloud, especially in light of this year’s events. However, organisations are often finding that the pure-play public cloud is not the panacea that they thought it would be.

In practice, they find that they have to juggle working across multiple public cloud providers, along with their own private cloud solutions. In particular, the growing need to put computational capacity near the edge has spurred many companies to realise that they require more than a simple pure-play public or private cloud and instead need to embrace a hybrid cloud environment.

The hybrid cloud is well suited for the complex and often messy world of today’s business operations, as it allows businesses to harness the benefits of public, private and on-premises capabilities.

However, in virtue of the fact that a hybrid environment potentially has to integrate and coordinate public, private and on-premise components, it also happens to be a much more complex infrastructure for teams to manage than a pure-play public or private cloud.

To ensure that the constituent parts of a hybrid cloud interface can communicate with one another, many IT teams will need technical training know-how. However, to make the hybrid cloud work in the long run, teams often also need to be trained in an entirely new way of thinking.

A DevOps culture may be essential to delivering on the promise of the hybrid cloud, and it’s crucial to cultivate it among a team and secure buy-in. So, what is a DevOps culture, how does it relate to the hybrid cloud, and what can you do to help educate and train your team in adopting it?

The DevOps paradigm
Adopting the hybrid cloud should coincide with a transition to DevOps. That is, the combining of development and operations teams within an organisation, and automating the processes that traditionally occur between these teams.

DevOps lends itself well to the hybrid cloud because it helps ensure IT teams can rapidly adapt and change their application delivery so as to reflect developments in hardware, software and best architectural practices that affect their public and private infrastructure and the way business applications are delivered.

The efficiency that comes with DevOps is particularly fitting for a hybrid cloud context. According to a 2016 report, DevOps teams experience 200 times more deployments, 2,555 times faster lead times, and spend 22pc less time redoing work.

These improvements drive a continuous integration/continuous delivery (CI/CD) pipeline, which sees multiple teams of developers continually iterate on software in parallel, which cuts down on errors and further speeds up deployment time. And so, a virtuous cycle is created, where efficiencies among the team adopting DevOps drive up CI/CD, which in turn increases the team’s efficiency.

The transition to DevOps – including educating and securing buy-in for it – will be somewhat disruptive, as it means ending the siloed processes that some team members have grown accustomed to.

However, the result is that you have a team that is much better prepared to deal with changes in the technology behind your public, private and on-premises facilities. This will bolster your resilience in the face of disruptions or sudden changes, while also meaning that iterations and improvements in your services and infrastructure are far more efficiently delivered.

Bringing in new technologies with DevOps
Transitioning to DevOps drives adoption of new technologies and architectural designs, such as microservices, to assist in the automation of processes and speed up the iteration time it takes to deliver new services.

Dismantling monolithic applications and breaking them down into constituent microservices helps create a common language and set of tools between development and operations teams, which will prove vital for handling the complex environment of the hybrid cloud.

This is in addition to all the other new technical know-how that has to be done to make a hybrid cloud transition work, so a well-developed training programme should be developed in conjunction with vendors that know the hybrid cloud and have worked with many other teams who’ve made this transition.

Approaching the culture of DevOps
As much as DevOps is a set of processes and systems, it’s also a new cultural paradigm. Taking culture seriously and changing it where appropriate is a virtual prerequisite for DevOps – many organisations that try to switch to DevOps without changing their culture and structure will fail.

Organisations need to open up communications between teams, and encourage them to harmonise their processes. This relies on encouraging the free flow of information among teams so they can break down their silos and adjust to frequent collaboration with one another.

When it comes to helping teams break down the silos for DevOps, the best place to start is encouraging your development and operations teams to see how the other works. Encourage your developers to spend a few days working with the operations team, learning the processes they go through and watching a production roll-out.

Then encourage your operations team to take stock of how many steps or service tickets it takes for a developer to request a new virtual system, so they have a realistic appraisal of how easy it is for developers to build or tweak new systems. This process will help both teams understand how the other works in situ and see outside of their particular silos.

When it comes to adopting the hybrid cloud, the DevOps transition is one that has to be approached through taking incremental steps. Throughout this process, educating and training your teams to make this change should always be framed in terms of the benefits it provides to them – quicker deployments, fewer errors and a more resilient infrastructure.

Securing buy-in throughout this process relies on making sure that they have the confidence that after the disruption of the transition, the infrastructure that they’re working on will be more robust than ever. When it comes to making the leap to the world of the hybrid cloud, your team will likely ultimately find that the DevOps culture that you’ve inculcated hasn’t just improved service delivery for end users, but it has also made the IT team’s lives much easier.

Technologists might do any number of things with their spare time, but as GitHub’s latest State of the Octoverse report makes clear, many of them choose to spend their nights and weekends working on open-source projects.

GitHub’s administrators, having analyzed millions of repositories for the report, suggest that enterprise-related developer activity drops on weekends and holidays (just as you’d expect), replaced by a surge of activity related to open-source development. Of course, GitHub suggests that employers encourage their developers’ urge to contribute to whatever projects they might find interesting: “Organizations should examine policies around external work and technology to ensure they allow time to engage with learning programs and that moonlighting policies allow for external projects.”

With technologists stuck at home during the COVID-19 pandemic, engagement with open source has increased—GitHub notes that open-source project creation has risen by 25 percent since April (year over year). For technologists, starting and participating in open-source projects confers another benefit: The chance to collaborate and make connections with others who share similar interests. Building out your network is an invaluable part of growing your career (and perhaps finding your next gig), and contributing to repositories allows you to do that even if you’re stuck at home.

After the pandemic ends, GitHub assumes that “remote and hybrid environments are likely to be the norm” as teams return to the office. It asks employers to provide “flexible solutions” so that developers can create schedules that make work sustainable; if the long months of remote work have taught the tech industry anything, it’s that workloads and schedules can quickly expand unless there’s a conscious, concerted effort to balance out work and life.

Or as the Octoverse report puts it: “Our analysis on work timing and work volume shows that developers benefit from flexibility that allows them to do their work by spreading it out. “

As we close in on 2021, and you consider updating your résumé and other materials for the new year (whether or not you’re actually looking for a new opportunity), highlighting your participation in open-source projects can boost your appeal to employers. Not only does contributing to projects show that you have the technical chops necessary for whatever position you want; it also highlights how your passion for technology extends beyond the workplace. When a developer uses their free time to contribute to a project they feel passionate about, they’re not just having fun—they’re also boosting their career.

Thales has announced a new collaboration with Google Cloud that will accelerate the ability of enterprises to safely migrate sensitive data between public cloud, hybrid and private IT infrastructures.

Together, the two companies will offer new capabilities that enable security teams to own and control their encryption keys while helping to fulfill heightened regulatory requirements amidst today’s highly-distributed workforce.

Building on a multi-year history of innovation around a variety of cloud security initiatives, Thales and Google Cloud will now empower customers to leverage the full potential of Google Cloud technology for sensitive workloads while gaining the external key management needed to control and secure data across hybrid cloud IT environments.

Securing the new IT frontier

This collaboration marks a significant moment for organisations to finally seize full control of their data and encryption keys, especially as they pursue hybrid, multi-cloud strategies. Addressing both private and public cloud environments, Thales and Google Cloud will provide a turnkey solution that manages, brokers and stores encryption keys completely controlled by the customer, effectively enabling companies to move data assets to the cloud with confidence. As uncovered in the Thales 2020 Data Threat Report-Global Edition, this is increasingly becoming more critical as greater than half of the world’s corporate data – of which 48% is sensitive – is stored in the cloud.

“New capabilities are critical to cloud migration and security, especially with such accelerated growth in this area,” said Sunil Potti, VP and GM of Google Cloud Security. “True to our mission, we have forged this deeper relationship with Thales to further protect our customer’s most sensitive information. Companies of all shapes and sizes are dealing with an extremely fluid and dynamic business environment where even the best lines of defence are constantly being battle tested. Together with Thales, we acknowledge the current set of circumstances and remain vigilant to provide customers with the most advanced solutions that address today’s cybersecurity needs as well as those that are emerging on the horizon.”

This collaboration greatly simplifies the security of moving to multi-cloud, hybrid cloud and edge-cloud environments – a journey more companies are making today to address the post-pandemic remote world.

According to 451 Research, 62% of enterprises today are pursuing a hybrid IT strategy. In addition, by working with Thales to handle application and data security in the cloud, Google Cloud customers can now maintain strong data sovereignty with encryption key visibility and lifecycle management. Customers also can address heightened regulatory requirements stemming from recent data and privacy regulations.

“Our collaboration with Google Cloud truly embodies the technology leadership needed to place the control of data directly into the hands of our customers,” said Sebastien Cano, SVP for Cloud Protection and Licensing at Thales. “Companies no longer need to put their sensitive data in untrusted environments and relinquish control of their coveted encryption keys. It has become abundantly clear that an evolution in data protection is taking place at a global level as security professionals work together to build a shared-responsibility security model between enterprise customers and providers. With this joint innovation effort, we’re supporting organisations as they move to the cloud with confidence.”

Microsoft on Thursday announced the general availability of its Azure Hybrid Benefit solution for Linux customers in India.

Azure Hybrid Benefit is a licensing benefit that helps organisations to cut the costs of running workloads in the cloud, Microsoft said.

It helps customers “seamlessly” migrate to on-premises Windows Server and SQL Server licenses, Red Hat Enterprise Linux (RHEL), and SUSE Linux Enterprise Server (SLES) virtual machines (VMs) to Microsoft Azure.

The solution enables significant reduction in cost of running workloads on-the-cloud by converting existing PAYG (pay-as-you-go) virtual machines (VMs) to bring-your-own-subscription (BYOS) billing, Microsoft said.

The solution gains significance in view of the fact that businesses face challenges in migrating workload to public cloud due to regulatory and data sovereignty related issues.

This is common in highly regulated industries such as financial services, healthcare, and government.

Also, some workloads, especially those related to edge, require low latency.

Additionally, many organisations have significant on-premises investments that they want to maximise so they choose to modernise on-location datacenters and traditional apps.

This includes in on-premises licenses and subscriptions, and the inability to migrate them to cloud often affects the return on investment and total cost of ownership.

Azure solves this by acknowledging this investment and not charging for subscriptions or licenses again when customers move to the cloud, Microsoft said.

Globally, over 1,500 Linux virtual machines were migrated during the preview period to Azure using the new Azure Hybrid Benefit capabilities, enabling significant cost reduction for enterprise running Linux workloads in Azure, the company added.

VMware, Inc. (NYSE: VMW) today announced that global market research firm Forrester has named VMware a leader in both The Forrester Wave„¢: Cloud Cost Management and Optimization (CCMO), Q4 20201 and The Forrester Wave„¢: Hybrid Cloud Management, Q4 20202.

Were honored to be a leader in both of these Forrester Wave reports, said Ajay Singh, senior vice president and general manager, Cloud Management Business Unit, VMware. We believe it reflects our dedication to helping customers unlock the full potential of a transformative, multi-cloud strategy. Wherever customers are on their multi-cloud journey, VMware delivers management solutions that help them address their needs.

Named a Leader in Cloud Cost Management and Optimization with CloudHealth by VMware

CloudHealth is a leader in the Forrester Cloud Cost Management and Optimization Wave and received the highest score in each of the three main categories of the eight evaluated vendors. The report analyzes and scores the top eight providers helping infrastructure and operations (I&O) professionals select the right solution for their needs. For vendors with CCMO offerings, according to the Forrester report, Container support, accurate billing, and cost optimization are key differentiators. The Forrester report further states, [CloudHealth by] VMware offers a leading platform for cloud-native and traditional enterprises.

The report notes, Reference customers gave high marks for CloudHealths customer support and openness to adding new features. They also appreciated the teams quarterly business review, which provides benchmark comparisons with other customers of similar size and cloud spend ¦ CloudHealth also includes visibility support for VMware [Cloud] on AWS, Oracle (beta), and [VMware] vSphere and other VMware Cloud Provider Program (VCPP) clouds, in addition to AWS, Azure, and GCP.

The report adds: VMwares success in the enterprise data center makes the CloudHealth offering attractive for existing VMware customers and partners. Since VMware acquired CloudHealth Technologies in 2018, CloudHealth has expanded its channel and partnerships, grown its integrations to enterprise software, and has more than 10,000 customers, including some of the largest cloud consumers in the world.

A Hybrid Cloud Management Leader with VMware vRealize Cloud Management

Demand for hybrid cloud management solutions continues to grow rapidly. Organizations seek to work with vendors offering comprehensive solutions that deliver key functionality including end user consumption, automated provisioning, performance, capacity, cost, and compliance management as well as unified monitoring and troubleshooting. As stated in the report, The Forrester Wave„¢: Hybrid Cloud Management, Q4 2020, VMware offers a leading platform that extends management from private to public¦[VMware vRealize Suites] focus is on providing app-aware multicloud management. The Forrester evaluation also states, Also notable is its code and experience consistency between its classic on-premises and software-as-a-service (SaaS)-based offerings.

VMware vRealize cloud management offerings help customers consistently deploy and operate applications, infrastructure and platform services across hybrid clouds so that they can modernize IT, accelerate cloud adoption and assure developer productivity. VMware vRealize includes automation, operations, log analytics and network monitoring capabilities to provide consistent operations and governance for a hybrid cloud environment.

The VMware vRealize Suite combines vRealize Automation, vRealize Operations, vRealize Log Insight, and vRealize Lifecycle Manager in a single package for on-premises deployments. VMware vRealize Cloud Universal combines SaaS and on-premises capabilities into one flexible subscription that enables customers cloud-first initiatives, with the flexibility to deploy vRealize cloud management on-premises or SaaS as needed.

VMware software powers the worlds complex digital infrastructure. The companys cloud, app modernization, networking, security, and digital workspace offerings help customers deliver any application on any cloud across any device. Headquartered in Palo Alto, California, VMware is committed to being a force for good, from its breakthrough technology innovations to its global impact. For more information, please visit

Technology has enabled businesses to continue operating this year, and the cloud has taken center stage — going forward, it will only play a larger role in the enterprise.

According to CloudTech, public cloud spending is expected to grow from US$229 billion in 2019 to US$500 billion in 2023, with a compound annual growth rate (CAGR) of 22.3%.

Key players Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Alibaba, and are expected to grow yet bigger, and by the end of 2021, 60% of companies will leverage containers on public cloud platforms and 25% of developers will use serverless.

As this market continues its growth and evolution, here are three trends to watch in 2021.

Serverless computing
A cloudless server is a technology that implements functions in the cloud on a necessary basis. Enterprises rely on serverless computing because it provides space to work on core products without the pressure to operate or manage servers. Microsoft CEO Satya Nadella favors serverless cloud and he believes serverless computing can not only respond and focus on back-end computing but also become key to the imminent future for distributed computing.

Serverless was among the top five fastest-growing PaaS cloud services for 2020, according to the Flexera 2020 State of the Cloud report.

Hybrid cloud joins providers
Choosing between public, private, or hybrid cloud environments, has proved challenging for some organizations — each offers advantages and disadvantages when it comes to flexibility, performance, security, and compliance.

According to Gartner, in 2019, the actual number of companies using hybrid cloud was 58%, up 6% from 2018. Hybrid cloud benefits include speed, control, and security. In terms of speed, it optimizes the network to reduce the latency and speeds up the data so that it can reach where it needs to be. For control, companies can customize the end of their hybrid cloud model, optimize it, and adjust it according to their needs rather than trusting a third-party cloud provider.

The continued demand for hybrid cloud could lead the world’s biggest providers to partially break out from their walled garden approach. By collaborating and introducing some interoperability, they can continue to satisfy multi-cloud demands. This will enable better data sharing and access between partners, who may be working across diverse applications and standards.

Virtual Cloud Desktops
A virtual cloud desktop refers to the software requirements of a device being fully managed by cloud service providers. The user just needs to have a screen and some basic hardware while the rest of the processing power will be seamlessly handled by cloud-based services.

Virtual cloud desktop users only pay on cloud usage, eliminating costs associated with acquiring powerful new hardware, updating the existing hardware, and the disposal of redundant computing equipment.

Sometimes known as desktop-as-a-service, this model of computing is offered by Amazon via the Workspaces platform and Microsoft with Windows Virtual Desktop. Google also offers functionality through its Chromebook devices. In practice, this can increase efficiency across a workforce by ensuring everyone is using up-to-date, synchronized technology.

RALEIGH, N.C.–(BUSINESS WIRE)–Red Hat, Inc., the world’s leading provider of open source solutions, today announced several upgrades to its enterprise automation platform, including the latest version of Red Hat Ansible Automation Platform with new Red Hat Certified Ansible Content Collections, automation services catalog and private Automation Hub.

With dynamic global challenges requiring rapid adjustments in operational domains and environments, automation projects have helped mitigate the complexity that these conditions produced and provides faster responses to changing business requirements. Bringing together teams for improved collaboration, these new services and offerings ultimately connect business managers with automation leaders to better align automation strategies with the needs of the business and expand how automation can be invoked.

In a related announcement, Red Hat previewed an integration between Red Hat Advanced Cluster Management and Ansible Automation Platform, bridging the divide between traditional IT environments and cloud native, container-based solutions. This integration unites two of Red Hat’s industry-leading platforms, Red Hat OpenShift and Ansible Automation Platform, to drive automation across the open hybrid cloud.

Additional Certified Content Collections: in-demand automation code made more readily available

Introduced in 2019, Ansible Content Collections provide a standardized method for automation developers to build and package automation content, and for implementers to consume them in a portable and scalable way. Ansible Content Collections bring guardrails and structure to automation content, packaging Collections into categories based on automation domain or platform. Collections delivered in Ansible Automation Hub are certified by the Ansible partner network and are tested, validated and fully supported for enterprise-class production environments.

The newest version of Ansible Automation Platform is slated to include newly certified Ansible Content Collections for Red Hat OpenShift, Kubernetes Core and VMware vSphere REST API. These Collections showcase Red Hat’s continued commitment to automating cloud and Kubernetes platforms for modern IT. Hybrid cloud use cases have pressed forward, whether it’s utilizing native Kubernetes or Red Hat OpenShift, these Certified Content Collections enable automation for various container management systems.

With the addition of these new Collections, there are now more than 60 Ansible Content Collections available from Red Hat and its partners in Automation Hub; you can view a full list of supported and certified Ansible Content Collections.

Building internal automation content communities with private Automation Hub

Ansible Automation Hub is a managed cloud service to provide easy access to certified Ansible content for customers, maintained by Red Hat and our partners. As automation efforts expand across organizations, individual teams often look to integrate automation as part of their overall IT strategy, while IT leaders want the ability to ensure security and manageability of unsupported content. Private Automation Hub delivers a central location for internal automation communities to manage and curate their Ansible content privately, using trusted content from Red Hat, its partners and internal developers.

Private Automation Hub enables content creators as part of enterprises to collaborate and publish trusted, verified resources from a single source, helping to streamline Ansible code within an organization and create a knowledge guide for automation newcomers. More advanced teams can still use this content as a basis for automation, while the organization as a whole gains the ability to manage and control the lifecycle of Ansible automation content as needs scale across the hybrid cloud.

Driving customized automation for the open hybrid cloud

Announced at Red Hat Summit 2020, the automation services catalog makes enterprise-specific, pre-approved, curated automation available to infrastructure and application teams, as well as to business users. This capability helps provide IT administrators and security operations teams with greater visibility over what is being automated while not slowing down organization-wide automation practices. With the addition of the connector technology in the automation services catalog, customers can now bring the automation services catalog directly and more securely to their own private infrastructure, enhancing control over what automation practices are being used.

The connector technology also enables organizations to maintain business-specific controls and compliance mechanisms, while developers can still access the information they need, faster. New integrations for Information Technology Service Management (ITSM) also extends the automation services catalog to platforms like BMC Remedy and ServiceNow, reducing friction in proactively completing ITSM rulesets and standards tasks. This can help drive greater efficiency for teams that are seeking to make Ansible automation a key part of their overall business strategy and not simply a siloed IT component.

Automation as an enterprise imperative

Red Hat acquired Ansible in 2015, and since then, the world of IT has changed.

Organizations now understand that automation can provide faster responses to changing business requirements, and provides the capability to automate more aspects of a business as a driver for future plans. According to a 2020 Forrester report commissioned by Red Hat, automation is a necessity; three out of five respondents reported automation as one of their firms’ top initiatives, even amid competing priorities like adoption of cloud, containers and security management. This imperative for automation has fueled momentum around Ansible, making it a leader in infrastructure automation platforms today:

More than 87% of U.S. executive departments and 83% of airlines in the Fortune 500 use Ansible Automation Platform
Organizations across industries are running Ansible Automation Platform to manage global operations, freeing up IT teams to focus on digital transformation and business-level innovations.
IT automation knowledge is now frequently cited amongst the most in-demand job skills.
Ansible Automation Platform enables customers to move away from do-it-yourself, siloed approaches and to improve ROI. These customers are automating millions of nodes with Ansible as part of a modernization of management approach.

Availability

The latest version of Red Hat Ansible Automation Platform is slated for November release, including private Automation Hub on-premise or in the cloud of your choice. The connector technology in the automation services catalog will also be available next month for technology preview. The new Ansible Content Collections are available now on cloud.redhat.com, with additional Collections released on a rolling basis.

Supporting Quotes

Joe Fitzgerald, vice president, Management, Red Hat
“Ansible has evolved into a defacto standard for automation and became one of the top 10 open source projects in the world, according to a most recent study. Red Hat has built an automation platform for enterprises to more easily access, consume and share Ansible content to significantly reduce the time-to-automation. As customers continue down the path of digital transformation, these pre-integrated resources can address common use cases while advancing the management and innovation of traditional and cloud-native infrastructure.”

Microsoft Expands Hybrid and Multi-Cloud Capabilities at Ignite 2020

At its Ignite 2020 virtual conference, Microsoft announced a broad set of updates to its Azure hybrid and edge portfolio. The announcements spanned security improvements, new Kubernetes support, edge hardware, and IoT integrations — reinforcing Microsoft’s long-standing strategy of making Azure hybrid by design, capable of running workloads across on-premises data centers, multiple public clouds, and edge devices.

Azure Arc: Managing Infrastructure Across Any Cloud

Azure Arc, launched at Ignite 2019, allows enterprises to project Azure management and services onto any infrastructure — including AWS, Google Cloud, and on-premises servers. At Ignite 2020, Microsoft announced two significant updates:

• Azure Arc enabled data services (preview): Extends Azure data capabilities — such as Azure SQL Managed Instance and PostgreSQL Hyperscale — to any Kubernetes cluster, regardless of where it runs.
• Azure Arc enabled servers (generally available): Organizations can now manage Windows and Linux machines hosted outside of Azure using the same Azure control plane used for native Azure VMs, including policy enforcement, inventory, and update management.

Earlier in 2020, Azure Arc also gained support for Kubernetes, enabling teams to attach and configure Kubernetes clusters running anywhere and apply GitOps-based configuration management.

Azure Stack: On-Premises Cloud for Compliance and Disconnected Scenarios

Azure Stack — Microsoft’s family of products for running Azure services in customer-owned data centers — has been available for more than three years. It is aimed at organizations with regulatory requirements that prevent certain data from leaving their facilities, or that need to operate in disconnected or partially connected environments.

At Ignite 2020, Microsoft announced two new capabilities for Azure Stack:

• Azure Kubernetes Service (AKS) on Azure Stack HCI (preview): Enables customers to deploy and manage containerized applications at scale on Azure Stack HCI infrastructure, using the same AKS tooling and experience available in the public cloud.
• Azure Stack Hub with GPU support (generally available): Customers can now run compute-intensive machine learning workloads in disconnected or partially connected environments using NVIDIA V100 Tensor Core GPUs. A less compute-intensive option using the NVIDIA T4 Tensor Core GPU is also available, enabling GPU sharing across workloads.

New Edge Capabilities: Devices, Data, and IoT

Microsoft also announced a set of new edge offerings designed to bring compute and AI capabilities closer to IoT devices and remote locations:

Azure SQL Edge — Generally Available

Azure SQL Edge brings Microsoft’s SQL data engine to IoT gateways and edge devices. It is optimized for IoT scenarios, supporting time-series data streaming, and can run in connected or disconnected states. Its general availability makes it a production-ready option for organizations looking to process and query data at the edge before forwarding it to the cloud.

New Azure Stack Edge Hardware

Microsoft announced two new rugged Azure Stack Edge devices suited for challenging field environments:

• Azure Stack Edge Pro R: A ruggedized device powered by an NVIDIA T4 GPU, designed for machine learning inferencing and quick insights at the edge in harsh environments.
• Azure Stack Edge Mini R: A lightweight, portable device intended for highly mobile or space-constrained deployments.

In addition, the Azure Stack Edge Pro series with GPU support became available, enabling customers to run visualization, inferencing, and machine learning workloads at the edge using the NVIDIA T4 Tensor Core GPU.

AT&T and Microsoft: Cellular Connectivity for Azure Sphere

Microsoft and AT&T announced a partnership to help enterprise customers connect industrial machines and equipment to the cloud securely. Using Azure Sphere guardian devices — which are designed to add connectivity and security to existing, often legacy, equipment — customers can route traffic through AT&T’s cellular network. This removes the dependency on local Wi-Fi infrastructure, which is often impractical or unavailable in industrial and manufacturing settings.

What This Means for DevOps and Platform Engineers

These announcements collectively reflect a consistent Microsoft strategy: converge cloud, on-premises, and edge environments under a single management and developer experience. For DevOps and platform engineering teams, the practical implications are significant:

• Unified control plane: Azure Arc enables policy, RBAC, and observability across heterogeneous environments — reducing the operational overhead of managing multi-cloud and hybrid setups.
• Kubernetes everywhere: AKS on Azure Stack HCI means the same container orchestration workflows apply on-premises as in the cloud, simplifying CI/CD pipelines for regulated industries.
• Edge ML pipelines: GPU-equipped edge devices and Azure SQL Edge make it feasible to push machine learning inference workloads to remote locations with limited or no connectivity.
• IoT security at scale: Azure Sphere with cellular connectivity addresses the longstanding challenge of securely connecting legacy industrial equipment without relying on shared enterprise Wi-Fi.

For teams evaluating hybrid cloud architectures, these Ignite 2020 announcements mark a meaningful maturation of Microsoft’s multi-cloud and edge story — moving several key capabilities from preview to general availability and extending the ecosystem to new hardware and partner integrations.

Overview

Google Cloud announced a series of new security capabilities aimed at enterprise customers. The centerpiece of the announcement was a significant expansion of Chronicle’s security analytics platform, including a new threat-detection rules language and a unified event timeline data model. Google also moved two additional security services — Web Risk API and reCAPTCHA Enterprise — into general availability.

Chronicle Joins Google Cloud

Chronicle was originally incubated inside Alphabet’s X moonshot division as a standalone cybersecurity company. Google subsequently folded Chronicle into Google Cloud, positioning it as the foundation of the company’s enterprise security analytics story. The integration gave Google Cloud a purpose-built platform for ingesting, indexing, and analyzing large volumes of security telemetry.

YARA-L: A Threat Detection Language Built for Modern Attacks

The most technically significant announcement was YARA-L, a new rules language designed specifically for detecting threats in security logs and telemetry data.

Background: What Is YARA?

YARA is a widely adopted, open-source pattern-matching language originally designed for identifying and classifying malware samples based on file characteristics. Security researchers and analysts use YARA rules extensively to describe malware families and detect malicious binaries.

What YARA-L Adds

The Chronicle team extended the YARA concept to cover log-based detection use cases — hence the “L” suffix. YARA-L allows security analysts to write detection rules that operate on:

• Security log data (authentication logs, firewall logs, etc.)
• Endpoint Detection and Response (EDR) telemetry
• Network traffic metadata

Critically, YARA-L rules are designed to map to the tactics and techniques catalogued in the MITRE ATT&CK framework — an industry-standard knowledge base that organizes the methods adversaries use during an attack lifecycle. This alignment means analysts can write detection logic that directly corresponds to known adversary behaviors rather than only looking for specific file signatures.

Google stated that the new threat detection offering supports massively scalable rule execution in both real-time and retroactive modes — meaning analysts can run new rules against historical data to find threats that may have gone undetected previously.

Unified Event Timeline: Automatic Attack Chain Correlation

Chronicle also introduced a new data structure that combines an updated data model with the ability to automatically link multiple security events into a single, coherent timeline.

To illustrate the value: imagine an employee who receives a phishing email containing a malicious link, then visits a credential-harvesting site, and finally downloads a malware payload. These three actions generate logs in three separate systems — email gateway, proxy or DNS logs, and endpoint telemetry. Traditionally, a security analyst investigating a breach would need to manually correlate these logs to reconstruct the attack chain.

Chronicle’s new data structure automates this correlation, stitching together seemingly unrelated events into a single timeline automatically. This reduces investigation time and lowers the risk that an analyst misses a critical link in an attack sequence.

Palo Alto Networks Cortex XSOAR was announced as the first Google Cloud partner to integrate with this new data structure.

Web Risk API and reCAPTCHA Enterprise Reach General Availability

Two additional Google Cloud security services moved from preview into general availability as part of the same announcement.

Web Risk API

The Web Risk API gives organizations programmatic access to Google’s database of known malicious URLs and domains. Practical use cases include:

• Warning users before they follow a suspicious link on your platform
• Blocking user-submitted content that contains links to known malicious pages
• Scanning URLs at ingestion time to flag high-risk content

reCAPTCHA Enterprise

reCAPTCHA Enterprise is aimed at protecting web applications and user accounts from automated abuse. It targets threats such as:

• Credential stuffing and misuse — automated login attempts using leaked username/password pairs
• Web scraping — automated harvesting of site content at scale
• Fake account creation — bot-driven registration of fraudulent accounts

Unlike the consumer-facing reCAPTCHA product, the Enterprise tier is designed for integration into business-critical workflows with more granular risk scoring and policy controls.

Context: Google Cloud’s Enterprise Security Push

These announcements came as Google Cloud was actively working to close the gap on AWS and Microsoft Azure in the enterprise market. At the time of the announcement, Google Cloud had disclosed an annual revenue run rate of $10 billion. Security capabilities are a key differentiator for enterprise cloud buyers, and absorbing Chronicle gave Google a credible enterprise security analytics story to compete alongside native offerings from its rivals.

In December 2019, Google Cloud had also announced new partnerships with external cybersecurity firms, further broadening its security ecosystem ahead of this February 2020 product wave.

Summary

Hybrid cloud and multi-cloud have become two of the most discussed infrastructure patterns in DevOps. Despite frequent confusion between the two terms, they describe fundamentally different architectural approaches — and understanding that difference matters when you are deciding how to run production workloads. What both approaches share, however, is a dependency on containers and container orchestration. This post explains why.

Defining the Terms: Hybrid Cloud vs. Multi-Cloud

Before discussing tradeoffs, it helps to pin down what each term actually means:

• Hybrid cloud combines public and private cloud infrastructure. Resources in a corporate data center or private cloud are connected to one or more public cloud providers. The word “hybrid” reflects two different deployment models working together.
• Multi-cloud is 100% public cloud, but workloads are spread across two or more cloud providers — or across multiple regions of the same provider. There is no private infrastructure involved.

The distinction is more than semantic. Hybrid cloud introduces significant security and compliance considerations because traffic and data must cross the boundary between private and public environments. Multi-cloud simplifies the security boundary but introduces more dynamic operational complexity as workloads move between providers.

Why Run More Than One Cloud at All?

Neither hybrid nor multi-cloud architecture exists for its own sake. There are practical reasons organizations adopt each model:

1. Regulated workloads alongside modern apps. Hybrid cloud lets organizations keep sensitive or tightly governed workloads on private infrastructure while still adopting modern application development practices on public cloud. Without a hybrid model, these organizations risk falling behind on developer experience and deployment velocity.
2. Resilience and vendor independence. Public cloud providers offer high availability within their platforms, but a major outage or a deteriorating commercial relationship can strand teams. Spreading workloads across providers — or designing for portability between them — gives organizations an exit option that does not require a heroic re-engineering effort.
3. Access to best-of-breed services. No single cloud provider leads in every service category. Locking all workloads to one provider means accepting that provider’s capabilities across the board. Multi-cloud lets teams choose the right service for each job — a managed database from one provider, a machine-learning platform from another, object storage from a third.

Maturity and History

Hybrid cloud is the more mature pattern. It gained significant traction around 2015, driven largely by enterprise vendors framing it as a cornerstone of digital transformation. Many large organizations have been running some form of hybrid cloud for years, and substantial tooling exists to support it.

Multi-cloud, by contrast, became a practical reality alongside the rise of container orchestration. Containers made it genuinely feasible to package and move workloads between providers without rebuilding application infrastructure from scratch. In that sense, Kubernetes and the container ecosystem did not just benefit multi-cloud — they arguably made it a viable production strategy in the first place.

Why Containers and Kubernetes Are Essential to Both

It is technically possible to build a hybrid or multi-cloud environment without containers. You can template virtual machine images, use infrastructure-as-code tools, and stitch clouds together with VPNs and shared DNS. But without containers, you give up the portability that is the central value proposition of either architecture.

Consider two specific reasons why containers and orchestration are effectively mandatory:

1. Portability requires abstraction. Connecting multiple clouds introduces rigidity by default. Each provider has its own networking model, storage primitives, and IAM system. Without an abstraction layer that decouples application runtime from the underlying infrastructure, moving workloads between environments is expensive and error-prone. Containers provide that abstraction at the application level; Kubernetes provides it at the orchestration level. Together, they allow workloads to be defined once and scheduled wherever the base infrastructure supports the container runtime.
2. Modern applications are not just containers. A realistic multi-cloud or hybrid architecture includes managed databases, object storage, serverless functions, and PaaS services alongside containerized workloads. Kubernetes does not manage all of these directly, but it provides the control plane that ties compute workloads together, and its ecosystem — through operators, service meshes, and external-secrets tooling — increasingly integrates with managed cloud services. Ignoring the container orchestration layer means losing the unified operational model that makes running across clouds coherent.

How Multi-Cloud Benefits Most from the Container Model

Software engineering has always favored abstraction and componentization. Applications are only as portable as their least portable dependency — and historically, that dependency has been the cloud platform itself. Abstracting cloud configuration away from any single provider so that the cloud becomes just another pluggable layer is the logical extension of the same principle that drove microservices, APIs, and package managers.

This matters especially for complex application architectures. In a microservices system, each service has its own independent stack, deployment lifecycle, and performance profile. Some services may need to run close to end users at the network edge; others may need to co-locate with specific managed data services. Multi-cloud, combined with container orchestration, gives platform teams the flexibility to place each component where it runs best — without rewriting that component for each environment.

As user expectations for real-time, low-latency experiences increase, infrastructure placement decisions become performance decisions. The ability to schedule workloads dynamically across providers and regions — something Kubernetes is designed to support — directly affects the quality of the application delivered to end users.

The Cloud Management Plane: Where Tooling Still Falls Short

Cloud management tooling matured reasonably well for hybrid cloud scenarios. A number of platforms offer a unified view of on-premises and public cloud resources, templated infrastructure provisioning, and policy enforcement across environments.

Multi-cloud is a harder problem for these tools. Several gaps remain common:

• Loose coupling between clouds. Most cloud management tools treat each cloud as a separate entity and model the connection between them, rather than presenting a single unified cloud abstraction. Operators end up managing individual cloud implementations and their connection points rather than a coherent whole.
• Tooling lock-in. Some cloud management platforms introduce their own proprietary configuration formats or template schemas. This can simplify operations within the platform but creates a new form of vendor dependency separate from the underlying cloud providers.
• Observability gaps. Visibility in a single dashboard is a minimum requirement. What teams actually need is unified monitoring and observability across cloud environments — consistent alerting, tracing, and log aggregation regardless of which provider is running a given workload. This remains an area where tooling is still catching up.

The ideal cloud management plane would allow an organization to define a cloud implementation as a templatized, deployable unit and push it to any environment where the base infrastructure supports it — with the same operational visibility in every location. That vision exists in partial form today across several tools and platforms, but no single solution delivers it completely.

Summary

Hybrid cloud and multi-cloud are meaningfully different patterns serving different organizational needs. Hybrid cloud bridges private and public infrastructure for organizations that cannot fully abandon on-premises control. Multi-cloud distributes workloads across public providers to maximize resilience, access best-of-breed services, and avoid lock-in.

Both patterns promise portability. Neither delivers on that promise without containers and container orchestration. Kubernetes has become the de facto standard for that orchestration layer precisely because it provides the infrastructure abstraction that multi-cloud and hybrid cloud require. Building either architecture without it is possible — but it means designing in rigidity from the start and paying for it every time you need to move a workload.

If portability is the goal, containers are not optional. They are the mechanism by which the goal becomes achievable.

The Problem: Waterfall Accountability vs. DevOps Agility

In traditional IT project management, handoffs are the formal transfer of a task or deliverable from one individual, team, or department to the next. In waterfall-style projects, these handoffs serve two critical functions:

• Traceability: They create a clear record of when work moved between stages.
• Accountability: They peg responsibility to a named individual or function at each stage.

Project managers rely on these handoffs to assess progress, identify blockers, and report status to stakeholders. Without them, it becomes difficult to answer basic questions: Who owns this task right now? Is it done? What is blocking it?

DevOps, by design, challenges this model. Cross-functional teams collaborate continuously across requirements, development, QA, and deployment — often without formal handoffs between distinct roles or departments. This fluidity accelerates delivery, but it can also obscure ownership and make it harder for a project manager to assess completion or readiness for production.

If you are an IT project manager moving from waterfall to DevOps, the key question is: What do you keep, and what do you leave behind?

The Case for a Hybrid Approach

Rather than treating DevOps and traditional project management as mutually exclusive, a hybrid model lets you retain what works best from each:

• From DevOps: Collaborative, cross-functional teams; continuous feedback loops; flexibility to incorporate change mid-project.
• From waterfall: Explicit task ownership; tracked handoffs; a defined endpoint that marks the transition to production.

The result is a model where teams move fast and collaborate openly, but where a project manager can still answer: who is responsible for each task, where is it in the workflow, and is the project on track to deliver its intended business value?

Six Practical Steps for a Hybrid DevOps Project Management Model

1. Start Small and Demonstrate Value Early

If you are introducing DevOps practices to an organisation accustomed to waterfall, begin with a small, well-scoped project that produces visible business value quickly. A successful, tangible outcome builds organisational trust in DevOps methods and makes it easier to secure support for larger initiatives.

2. Choose the Right Business Partners

DevOps depends on strong working relationships between IT and the business. Start your DevOps collaborations with departments that are already comfortable engaging with IT — those with technically literate staff who understand system constraints and can participate meaningfully in requirements and testing. Weak IT-business relationships are a common reason DevOps adoption stalls.

3. Assign a Single Project Manager

Even when a project is co-sponsored between IT and a business unit, assign one project manager with clear overall responsibility. Dual ownership at the project management level creates confusion about escalation paths and reporting lines. The PM does not need to be an expert in every technical domain, but they do need full visibility across all workstreams and the authority to resolve cross-team conflicts.

4. Use Project Tracking Software to Maintain Visibility

In a DevOps project, work moves quickly and task ownership can shift. Use project tracking tools — such as Jira, Azure DevOps, or similar platforms — to ensure that every task has a named owner and a current status. Require team members to update their tasks independently so the project manager always has an accurate picture of progress without relying on status meetings alone.

Key things to track explicitly:

• Who owns each task right now
• When a task was handed off from one person or sub-team to another
• Whether a task is blocked, and who is responsible for resolving the blocker

5. Maintain Sub-Group Accountabilities Within Cross-Functional Teams

DevOps cross-functional teams typically span requirements, development, QA, and deployment. While collaboration across these disciplines is the point, that does not mean accountability disappears. Organise the team into sub-groups with clearly defined responsibilities at each phase, and track handoffs between those sub-groups just as you would in a traditional project.

For example, when the development sub-group completes a feature build, a tracked handoff to the QA sub-group creates a clear record that the build is ready for testing, who accepted it, and when. This preserves the traceability that project managers and auditors need without sacrificing collaboration.

6. Define a Clear Project Endpoint

One of the risks in continuous-delivery DevOps projects is that scope creep becomes institutionalised — the project never ends because there is always another feature or improvement to add. Establish a defined production deployment target upfront. This represents the ultimate handoff: from the development team to the live production environment and the business users who depend on it.

A defined endpoint does not prevent future iterations. It simply ensures that the project delivers a concrete, deployable outcome that justifies the investment made so far.

Why This Hybrid Model Works

The hybrid approach succeeds because it addresses the practical needs of both technical teams and organisational stakeholders:

• Technical teams retain the collaborative, flexible working style that makes DevOps effective.
• Project managers retain the visibility and accountability mechanisms they need to report status and manage risk.
• Business stakeholders get regular, demonstrable progress toward a production outcome tied to real business goals.

Neither pure waterfall nor unstructured DevOps is well-suited to most enterprise IT environments. A hybrid model, with deliberate handoffs embedded in a collaborative DevOps workflow, gives engineering teams and project managers a practical middle ground.

Key Takeaways

• Task handoffs are not incompatible with DevOps — they can be adapted to provide traceability within a collaborative model.
• A single, empowered project manager is essential even when teams are cross-functional and co-sponsored.
• Project tracking tools must be actively maintained by team members to give the PM reliable visibility.
• Sub-group accountability within DevOps teams bridges the gap between collaborative execution and individual ownership.
• Every DevOps project needs a defined production endpoint to avoid perpetual scope expansion.

The Open Source Promise — and Its Limits

The FOSS acronym — Free and Open Source Software — has been a rallying cry since the open source movement gained mainstream momentum. Yet the term itself reflects a long-standing tension. In 1998, a group of technologists and business leaders convened specifically to reframe “free software” in more commercially oriented terms, partly out of concern that the original concept was being co-opted for political ends. The effort clarified something important: open source code is still someone’s intellectual property, even if it is freely available.

Today, the most common driver for adopting open source remains the desire to avoid licence fees charged by proprietary vendors. But reducing the decision to a simple cost-avoidance argument misses the full picture — and can lead organisations into costly mistakes.

Open Source Is Not Free — It Has a Different Cost Structure

Linux is the canonical success story of open source software. Its dominance in server and cloud environments has nothing to do with its zero licence cost. Linux succeeded because it is technically excellent, and because a mature ecosystem of hardware and software vendors provides professional, paid support for it. The “free” in FOSS refers to freedom, not price.

Every open source deployment carries costs. Organisations typically face one of two paths:

• Self-managed deployment: The organisation installs, operates, and maintains the software internally. Costs are driven primarily by the skilled staff required. For widely adopted, mature projects (Linux, PostgreSQL, Kubernetes), community resources are plentiful and support costs are relatively manageable. For niche or specialised tools, internal expertise can be expensive to build and retain.
• Professionally supported deployment: The organisation contracts with a vendor (Red Hat, Canonical, SUSE, and others) for enterprise support. This model trades unpredictability for a structured cost — but that cost often ends up comparable to a commercial proprietary licence plus maintenance.

Quocirca, the analyst firm, has documented at least one organisation that pursued an open-source-only IT strategy and found, after three years, that its total cost of ownership was approximately three times higher than the proprietary environment it replaced. The lesson: open source economics are not uniform, and a one-size-fits-all approach does not work.

Open Source and the Hybrid Cloud: A Plausible but Incomplete Answer

Open source platforms have become central to hybrid cloud architectures. OpenStack, for example, underpins many private cloud deployments and is present in several public cloud offerings. The Open Compute Project — initiated by Facebook and now an independent industry consortium — extends the principle to hardware design. Google has positioned itself as a prominent supporter of open source cloud infrastructure, including Kubernetes, which originated as an internal Google project.

Given this landscape, the argument for an “open source first” hybrid cloud strategy sounds compelling. But the argument breaks down at the edges.

Consider a hypothetical organisation that needs to run a specialised, computationally intensive workload. It chooses Linux and OpenStack as the foundation — both mature, well-supported platforms. It then adds a niche open source application for the actual number-crunching task. Support for Linux and OpenStack is easy to find. But the niche tool was written by a single developer who no longer has time to maintain it. No community has formed around it. The organisation is now solely responsible for maintaining, debugging, and extending code it did not write, with no prospect of commercial support and — depending on the licence — limited ability to monetise any improvements.

Worse, if that application has tight, undocumented dependencies on a specific database version or uses proprietary API calls, any upstream update to that database can silently break the application. These are not edge cases; they are routine risks in real-world open source deployments.

Security Considerations Cannot Be Ignored

Open source adoption also raises security governance questions. When a system administrator searches a community forum for a solution and finds several competing answers, how does the team evaluate which is safe to apply? Unvetted code pulled from community repositories can introduce vulnerabilities. The original article cited the WannaCry ransomware outbreak as a contemporary example of how quickly malicious code can propagate — a reminder that no software ecosystem, open or proprietary, is inherently immune to supply-chain or vulnerability risks. Open source projects vary enormously in their security review processes, and the burden of due diligence falls on the adopting organisation.

The Real Priority: Open Standards Over Open Source Ideology

The most durable insight from this analysis is a shift in emphasis: the debate should not centre on open source versus proprietary software, but on open standards versus proprietary lock-in.

In an API-driven world, interoperability is the critical property. A hybrid cloud environment that spans on-premises infrastructure, public cloud providers, and edge deployments must allow workloads, data, and management tooling to move and communicate across boundaries. Whether the underlying software is open source or commercially licensed matters far less than whether it adheres to open, well-documented standards.

Open standards — such as the Open Container Initiative (OCI) for container formats, OpenAPI for API description, or cloud-agnostic identity protocols — provide portability and vendor negotiating leverage regardless of the licensing model of the software that implements them. A proprietary product that implements open standards is often a better architectural choice than an open source tool that creates its own de facto lock-in through proprietary data formats or undocumented APIs.

A Pragmatic Framework for Open Source Decisions

Rather than adopting an ideological stance, DevOps and platform engineering teams should evaluate open source tools against a practical checklist:

• Community health: Is the project actively maintained? How many contributors does it have? What is the release cadence?
• Commercial support availability: Is there a vendor offering paid support, and at what cost?
• Licence compatibility: Does the licence permit the use case, including any internal distribution or SaaS delivery?
• Standards conformance: Does the tool implement recognised open standards, or does it create its own interfaces?
• Dependency risk: What upstream dependencies does it carry, and how stable are they?
• Security posture: Does the project have a published security policy, a CVE disclosure process, and a history of timely patches?
• Total cost of ownership: What is the realistic staffing, training, and support cost over the expected deployment lifetime?

Conclusion

Open source software is a powerful tool in a hybrid cloud strategy, but it is not a strategy in itself. The organisations that benefit most from it are those that treat open source as one option in a broader evaluation process — not a default answer. The more important architectural principle is commitment to open standards, which provides genuine flexibility, portability, and long-term vendor independence regardless of whether the software carrying those standards is open source or commercially licensed.

Open source is an approach. Open standards are the goal.