devopsy.kinsta.cloud

Tag: cloud-first

The Cloud Reset: DevOps Brings Workloads Back to Private Clouds

Many DevOps teams are hitting the reset button and rebalancing their use of public versus private clouds after a decade of “public cloud-first” strategies.

Recent research reveals that 69% of enterprises are considering moving workloads from public cloud back to private environments. DevOps teams’ desire for greater control, security and cost predictability is largely driving this shift. Indeed, 92% of IT leaders say they trust private cloud more for security and compliance needs than public cloud

The shift to private cloud is very DevOps-driven. This is because all stakeholders can benefit. DevOps teams benefit from the private cloud’s stability and how existing or future investments in on-premises infrastructure are complemented and maintained. With the benefits cloud computing offers (automation, scalability and self-service), DevOps teams are better able to manage security and meet compliance needs, especially when data sovereignty is concerned. Additional benefits for the business DevOps stakeholders include how private cloud can help reduce rapidly rising public cloud costs.

Learning from a Decade of Public Cloud

The lessons learned in the public cloud space over the past few years are key. Public cloud platforms are agile and scalable, but they often present unpredictable costs and data governance issues. Most companies admit that at least some of their public cloud budget is wasted, and almost half believe that at least a quarter of their cloud spending is lost to inefficiencies.

Cost unpredictability has surfaced as a major concern. Most companies acknowledge that at least some of their public cloud budget is wasted, and nearly half believe that at least a quarter of their cloud spending is lost to inefficiencies. What began as a promise of “pay only for what you use” often led to surprise bills from unforeseen usage spikes, data transfer costs and complex pricing models that made budgeting nearly impossible.

Equally significant are concerns over security and data control. While public cloud providers offer robust security features, many organizations struggle to navigate the shared responsibility model and the complexities of managing security across multiple cloud environments. More leaders believe that private or hybrid cloud environments better meet stringent security requirements and provide them with direct oversight of critical data. For industries with strict compliance mandates, having complete control over data location and access has become non-negotiable.

The Evolution, Not Abandonment, of Cloud Strategy

This shift doesn’t signify a failure of cloud computing or a return to traditional on-premises infrastructure. Instead, it illustrates a maturation of cloud strategy. Organizations seek the same cloud benefits, such as automation, self-service provisioning and scalability, but within a more predictable and accountable operational model.

Private clouds have advanced considerably since the early days of virtualization. Modern private cloud platforms now provide the same cloud-native capabilities that made public clouds appealing: containerization, microservices architecture, DevOps tooling and infrastructure as code. The distinction lies in where these capabilities are deployed and who oversees them.

Strategic Workload Placement

The trend toward repatriation is fundamentally about strategic workload placement. Organizations are realizing that not all workloads are equal, and the “lift and shift everything to public cloud” strategy often fails to yield the expected benefits.

Workloads with predictable resource requirements, sensitive data, or stable performance needs are increasingly being transitioned back to private cloud environments, where they can be managed and controlled more effectively. Meanwhile, workloads that benefit from elastic scaling, global distribution, or specialized cloud services continue to reside in public clouds.

This hybrid approach enables organizations to optimize for different priorities, keeping mission-critical applications in private clouds for security and control, while utilizing public clouds for innovation and experimentation. It’s about selecting the right tool for each task rather than forcing all workloads into a single model.

Cost Governance and Predictability

In private cloud environments, IT departments can allocate resources per workload and precisely determine the cost of delivering those resources. This predictability encompasses not only infrastructure costs but also operational expenses, compliance costs and the total cost of ownership.

When a department’s application suddenly requires additional compute power in a private cloud, it prompts a conversation about capacity planning and budget allocation, but not an unexpected bill at the end of the month. This level of control enables organizations to more effectively align IT spending with business objectives and mitigate the “shadow IT” issue that often plagues public cloud deployments.

The Path Forward

In this era of cloud reset, DevOps teams are not abandoning the benefits of the cloud, but rather refining their approach. Our analysis at ReveCom shows the next phase in cloud computing for DevOps teams involves selecting the right environment for each workload while ensuring performance, interoperability and accountability are in alignment with DevOps.

For many organizations, this means developing sophisticated hybrid cloud strategies that leverage the best of both worlds. Private clouds offer the control, security and predictability required for core business applications, while public clouds provide the flexibility and innovation platform for new initiatives.

As DevOps teams continue to move to private and hybrid clouds, it’s a strategic shift in how they think about their infrastructure. It’s acknowledging that the cloud isn’t just a destination, but an operational approach that can be applied where it makes the most sense for business. As DevOps teams continue to refine their cloud strategies, the focus is shifting from “cloud-first” to “cloud-smart,” with private clouds increasingly playing a crucial role in delivering the promise of cloud computing while maintaining the governance and control that enterprises need.

October 21, 2025
Improvement Cycles and AI

It’s that time of year when pundits start to crank out their predictions for the next twelve months! I’ve been asked to contribute to a private group (and occasionally, Techstrong Group asks me to contribute to their annual list), so I won’t thrill you with my predictions just yet; but I will discuss the cycles and trends that previous predictions have shown.

Back when I was testing physical servers, we thought of throughput bottlenecks in terms of where the problem was. The circle would go disk->memory-> CPU, and in the case of things like NAS, insert network in there somewhere, too. When one bottleneck was resolved, another would crop up. And users will always seem to be pushed to the next bottleneck.

We see similar cycles in DevOps. First, Agile made development faster, and that caused us issues throughout the rest of the process. Then, DevOps helped with the build and a little with the testing and deployment steps, but in the early days it was more standardization than speeding up. And since then, we have been in that cycle. We’re seeing GitOps speed up and automate deployment and upgrades—based upon the automation that came before—we’re seeing test and security tools feeding directly into the IDE to speed resolution, we’re seeing container automation cause “cloud-first development” (I hate that name; Kubernetes has cloud-like interfaces, but is not precisely cloud) to be fully automated, and thus faster.

And we’re looking at that cycle continuing. No doubt you will hear a lot of predictions that start with “AI …” For the most part, AI is a tool and/or technique. Listen for what it is improving because it is doing very little that’s actually new. (Delete list of things that sounded alarmingly like those predictions I said I wouldn’t make.)

All in all, we are still living in a very cool technological time. We can have a tool generate code snippets of the dull work for us so we can focus on the important bits. Some shy away from this use of “AI,” but honestly, we already use libraries to do the grunt work—I haven’t written to a screen buffer in forever—because we don’t have to. Same story—use the tools that make you productive. Some of the more obscure bits of Linux command lines are far better dealt with by asking an AI to give me examples than searching through tons of docs across several platforms. Never was much of a fan of man output for complex commands, this makes it easier. The nice bit is that bash and UNIX utilities don’t change much over time, so answers can be a bit dated and perfectly accurate. That’s not true for much of IT.

The environment has consistently gotten more complex, while the building blocks have gotten easier to use. This allows things to keep moving and changing while it offers us better ways to serve the organization’s needs. This does change at some point—infinite change is indeed a thing, but any technology does have its limits—but I honestly can’t see the point at which we are content with our IT tools and stop looking for more. Oh, most organizations go through those cycles—organizationally, once an infrastructure and process works correctly, it is likely to hang around until better is found—but the industry will keep changing.

And you’ll keep learning and changing. That’s one prediction I will make for next year. Teams and IT staff will grow and learn new things, because at its heart, that is what we do. We learn new things and keep the lights on. In good years, we offer sweet new tools and functionality to the company or our customers. But either way, we keep things online. Year after year. You all rock, so that’s an easy prediction.

November 1, 2023
It Is Time for DevOps to Focus on Ops

The advent of both Agile development and DevOps were great steps in improving an IT process that had become ossified, with policies that alternated between resistance to change and trying to do things better/faster. Between them, Agile and DevOps broke the cycle of resistance … but only for development.

The confusion around CI/CD is a great example. CD is both continuous delivery and continuous deployment. Do you know why? Because up to that point (and even recently), DevOps included Ops in the name but did little with or for operations. I have no doubt that it was originally intended to include everything from build testing to full-on deployment, and we are finally getting there.

You have no doubt noticed that both operations and security are finally getting DevOps’ attention at critical points. I have been chatting with coworkers about value stream mapping and, if you map the value stream of a software delivery process, you will find that all of the weak points have shifted right. Thankfully, we are also paying attention to them these days.

From GitOps to infrastructure-as-code (IaC); from cloud-first to policy-as-code (PaC), we are finally approaching the operations side with some level of seriousness. And it is generating results for those involved.

My two areas of attention these days are DevOps and application security (AppSec). As I’ve written elsewhere, both are benefitting massively from things like policy-as-code. The ability to apply corporate deployment policies, security policies and compliance policies from a centralized location is massive. It is early days, but community contributions to PaC libraries are already massive, making it easier to deploy without recreating that big old list of generally useful policies.

Given a project, a set of tools and a timeline, you could fully automate the process from the first line of code to running in production, with stops for approval and the specialized steps that still require human interaction (no matter how many public policies are out there, someone with knowledge of your network still has to set up IPs or ranges, for example. Or someone still needs to write the code). Someday, it may be possible to say, “We need a phone app that targets both major platforms and is hosted on Linux that does X, Y, Z,” and it just happens … but we are not there yet, and, IMO, the domain knowledge will be a roadblock for a while. But you can take advantage of what we have to work smarter, not harder. And the organization will be better off for your efforts.

So keep at it, start to evaluate your processes and consider placing any of the great new DevOps technologies into your path. Let them do some of the grunt work so you can focus on adding value. And for all those coworkers that still don’t get it, thank you. You are keeping them in a job, whether they admit it or not.

June 14, 2023