devopsy.kinsta.cloud

Tag: governance

  • Secure Governance and Scalable Management for AI Models

    Secure Governance and Scalable Management for AI Models

    At swampUP 2025, Yuval Fernbach, vice president and CTO of MLOps at JFrog, and Adel El Hallak, senior director of product for NVIDIA AI Enterprise, discuss how JFrog is integrating machine learning operations (MLOps) into its platform strategy. Fernbach, who joined JFrog through its acquisition of Qwak, outlined how JFrog is extending its mission beyond artifact management to embrace AI-driven software supply chain automation. The goal, he noted, is to enable developers to build, deploy, and govern AI models with the same level of trust and traceability that JFrog has long brought to binary and container management.

    They discussed the rapid convergence of MLOps and DevOps, a shift that is redefining how teams manage the entire software and model delivery lifecycle. As organizations accelerate their adoption of generative AI and large language models (LLMs), the challenge is no longer just building or training models—it’s governing and managing them at scale. AI introduces new forms of technical debt, compliance requirements, and operational risk that traditional software management frameworks were never designed to handle. Every model carries dependencies, training data, and inference patterns that must be tracked, versioned, and secured across environments. Without unified governance, enterprises risk exposing sensitive data, violating regulations, or deploying unverified models that behave unpredictably in production.

    The energy at swampUP reflects an industry in transition—where every team, from developers to platform engineers, is rethinking their toolchains for the AI era. As Fernbach and others shared, JFrog’s latest innovations are designed to bridge that gap, ensuring that software—and now models—move from experimentation to production with speed, security, and confidence.

  • Policy-Based Governance: Modernizing Authorization for the Enterprise

    Policy-Based Governance: Modernizing Authorization for the Enterprise

    As we’ve moved away from on-prem environments to cloud-based ones and policy managed via code, we’ve inadvertently changed the way the infrastructure is managed. The infrastructure that used to be managed by IT/security teams has now shifted to being managed by the engineering operations teams. With that shift, engineering teams have found themselves now in control of new environments, including the access management part. This new change of control and management of access in the privileged environment requires a new approach to the solutions we use for privileged access governance.

    Shift to Cloud-Based Environments

    Cloud adoption has grown rapidly in the past few years, and while many organizations were already moving to the cloud from on-prem, the COVID-19 pandemic accelerated the transition, causing remote working to become the norm and changing the way responsibilities are managed.

    These organizations found they needed to adopt new ways of working to be able to support and provide critical services to off-site workers. As a result, more than 90% of organizations have adopted some form of cloud-based infrastructure, changing the way they work.

    The cloud is prevailing for tech stacks that need to elevate access governance over the cloud infrastructure. In fact, a whopping 94% of enterprises report they are using cloud services today, and 75% say security is a top concern.

    Cloud Shift, Worldwide, 2019 – 2025

    “The shift to the cloud has only accelerated over the past two years due to COVID-19, as organizations responded to a new business and social dynamic,” said Michael Warrilow, research vice president at Gartner.

    Shift to a Fast-Paced, Customer-Value Mindset

    Since switching to a new agile working environment, customers have gotten used to expecting very fast service. Instead of having a change management process that deploys to production once every few weeks, it’s now common to deploy hundreds of times to production every day.

    Access: required more often, more dynamically.

    Dynamic Changes: With the shift to the agile pace in which the new company works, access has been complicated a hundredfold. (Being able to support customers, fix bugs and being able to move very quickly. Needs to support these hundreds of changes to the customer’s product in their hand.

    Scale of Access has Increased: With the shift to cloud-based infrastructure, it’s now possible to create 5000 databases, for example, with a click of a button. All of them require access management because each one requires an understanding of who needs access and in what way.

    New Solutions are Needed

    The cloud providers, AWS, Azure and GCP, are now the way that people work. And most resources, whether databases or the machines that are running are doing so in the cloud environment. However, companies that shifted to the cloud are dissatisfied with what their legacy PAM solutions can provide them for the cloud resources. These solutions are ill-suited for their new needs. Instead, they need a solution that is agile and scalable to match their new working environment.

    With a perceived lack of options, companies are choosing to have the engineering team put in time to create new solutions. These solutions are meant to provide the following benefits: A frictionless way to gain permissions, an easy way to integrate with the tools their team uses today, and instead of manual provisioning and manual access requests, these solutions should automate those tasks.

    They are creating these in a variety of ways, including the following examples:

    1. Dev Portals: Dev portals are internal developer portals that act as a storehouse of information for the developers in a company. They work by centralizing the data in an internal portal, which offers developers and managers the ability to construct a system that facilitates monitoring of the software ecosystem, receiving alerts about alterations, and visually representing interconnected details. This portal additionally simplifies the task of overseeing diverse facets of the software development lifecycle, encompassing aspects like microservices interconnections, ownership statuses, dependencies, resource allocation, and beyond. By utilizing these, companies are delivering and gaining permissions to cloud environments.

    2. Slack Bots: Many times, a developer will need elevated access to resources or databases, so they need an easy way to request and be granted the permissions they need when they need them.

    3. Terraform Automation: Terraform is an infrastructure-as-code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. Terraform policies and infrastructure code/policies could also be leveraged to define access control policies. The way it works is that engineers or support teams are required to request a change in the Terraform code in order to gain the access they need. If there is a Terraform code in place describing the policy of groups to role access to the relevant infrastructure they would like to gain access to, they can request that access by requesting a Terraform code change. They would need to understand which parts of the code to change and submit a “pull request” to make the desired change which will resolve in the permissions change. Once a Terraform code change is approved, it changes the policy of access to that infrastructure which will change the permissions that the group has.

    (a) Static: The Terraform state is static, meaning that permissions granted in this way are essentially meant to be long-lasting, standing permissions. In addition, these permissions are usually granted to a role and are very coarse-grained(not granularly defined, as they need to suit the whole role’s needs). This creates an environment of over-privileges. That is why, in many cases where the permissions should be granted to a specific task or person or for a limited time, teams choose to use one-off permission granting to manually grant the permissions. However, these one-off permissions create drifts in the environment essentially if they are not revoked. And since there is no process in place for these one-off just-in-time (JIT) permissions, the revocation needs to also be manual and needs to be remembered to be done.

    (b) “Drifts”: (A drift in Terraform is when the environment isn’t accurately reflected in the Terraform policy). Therefore, by changing the access outside of Terraform, you’re creating a drift because it doesn’t match up correctly, making it a poor answer to one-off permissions. For anything needing high privileges, you want it to be dynamic instead of remaining as part of Terraform.

    4. Jira Service Management With Your Cloud Provider: Integrating Jira with GCP (as a cloud provider example), allows the IT security team the ability to automate servicing access tickets by creating forms where teams can request a certain role or be granted access to a certain project.

    5. Manual JIT Cloud Role: This is a method that allows self-serve permissions to engineers to get the permissions they need on demand. The role needs to be predefined, and essentially, as long as the engineer is part of the group, he or she will be able to gain those privileges on-demand. This reduces the standing privileges in the environment at any given point; however, roles granted are usually for a generic cloud admin rather than being granular, as it’s hard to determine ahead of time exactly what permissions will be needed.

    Problems With DIY Solutions

    Because of the lack of the right tool, companies are spending expensive resources creating their own solutions for access control. Team members know they need something that leverages cloud capabilities rather than their PAM for on-premises. These solutions are time-consuming; companies need to build then maintain the infrastructure. They are also very limited in what they can do since they are not the company’s main concern.

    Policy-Based Governance

    With the growing adoption of cloud-based tools, it’s more important than ever that companies learn to adapt. Engineers have now found themselves in control of permissions in new environments they were not looking to manage. It’s clear that a new approach to access governance is necessary.

    The quickest and most sure-fire way to do this is by utilizing tools deliberately made for the new cloud-based era that address the challenge in a way that is suited to the new, fast-paced, dynamic cloud environment. These new solutions are policy-based and leverage the fact that with the shift to new ways of managing infrastructure, it’s necessary to give the IT and Operations teams more control, granularity and automation.

    Platforms such as Apono for cloud-based permissions management allow organizations to benefit from centralized permissions management, enforce dynamic role-based access controls, monitor and audit privileged user activities and mitigate security risks effectively.

    Final Thoughts

    In addition to the shift we have witnessed in the control of the environment and access governance, organizations are also shifting to delegating more ownership to the engineers themselves. This means providing engineering teams more control of their code — all the way to production. However, with that comes the need to give them only granular control over the environment and provide access management to their specific scope without creating a burden on the teams in managing/granting the access. This leads the operations teams to search for solutions to address the need for access management delegation in the environment. New solutions and platforms addressing the new environment’s privileged permissions management challenge need to take that into consideration as well.

    As a final note, I believe the shift in mindset occurred a few years ago already. However, we are only now realizing some of its effects. One of them is the shift in privileged access challenges and all that comes with that. Seeing the many internal solutions that small-to-large companies have created for themselves gives us an understanding of how this evolved market isn’t being addressed with the same platforms that have existed for well over a decade.

  • Myth Busting: 5 Misconceptions About FinOps

    Myth Busting: 5 Misconceptions About FinOps

    Over the years, moves to the cloud have happened in several different ways and at various speeds. The reality is that today most enterprises are spending massive amounts on their cloud environments, and many teams are struggling to contend with the governance implications of this reality.

    Fundamentally, teams struggle with an either-or proposition: Either they give development and engineering teams free rein in terms of how they use cloud models, and, in the process, they leave the business exposed to a wide range of risks or they try to enforce central controls and restrictions on cloud usage and, in the process, stifle speed, flexibility and innovation.

    FinOps is a Necessary Discipline

    Teams are struggling with cloud governance in general, and one particularly vexing aspect of governance relates to cloud cost management. Quite simply, the procurement models and approaches that worked in the days of on-premises data centers simply don’t cut it today. At all.

    For these reasons, FinOps is emerging as a necessary discipline. At its root, FinOps is about establishing the people, process, and technology for establishing financial accountability in pay-as-you-go cloud environments.

    Here’s how the FinOps Foundation defines it:

    “FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.”

    Recently, I started preparing for the FinOps certification, and in the process, I have had the chance to talk with quite a few practitioners. Along the way, I’ve heard several misconceptions about the discipline. I’ll list and dispel a few of the most common myths in the following sections.

    Myth: FinOps is a Buzzword, not a Discipline
    While the term may still be new to some, the need for FinOps is clear, real, and not going anywhere. Consider that in a survey of more than 800 professionals, the FinOps Foundation found FinOps team sizes grew 75% in the last 12 months, and respondents are expecting 50% more growth in the next year. Today, the FinOps Foundation has more than 5,300 members. Further, on any given day, a search on career sites for roles specifically referencing FinOps will typically yield hundreds of opportunities.

    Myth: The Sole Goal of FinOps is Saving Money
    More than just tracking and controlling spending, FinOps offers a way to optimize spending, so each dollar invested ultimately yields the most business value. Rather than simply helping save money, FinOps is about making money.
    FinOps teams should advocate and lead with value-based discussions rather than focusing on cost. For example, if additional spending on a certain cloud service increases marginal value, FinOps teams help justify that additional investment.
    FinOps helps teams reduce wasted spending, but it also enables teams to invest more in services that allow the business to innovate, adapt, and scale. Ultimately, it offers teams a way to capitalize more fully on the advantages of cloud pricing models.

    Myth: FinOps Teams are Responsible for FinOps
    To be successful, organizations need to build a central FinOps team. These teams establish guidelines and best practices and facilitate unified reporting and visibility. However, FinOps doesn’t start and end with a single team.

    Those that succeed with FinOps are the ones that effectively break down silos. Individuals from leadership, finance, operations, development, and more all have a role to play. In a FinOps-driven organization, a range of teams collaborate, and in the process, they all benefit. For example, development teams can innovate more quickly and make more intelligent, data-driven decisions around balancing speed, quality, and cost.

    Through FinOps, everyone takes ownership of cloud usage. Cross-functional teams work together to establish more effective management of cloud vendors and rates. Ultimately, rather than creating conflict, friction is reduced. The end goal is to establish alignment around business objectives.

    Myth: FinOps Teams Stifle Innovation

    With traditional procurement models, central teams retained visibility and control over expenditures. While this would add layers of time and effort to purchases, this was accepted as a worthwhile tradeoff.

    Part of the reason for FinOps has come into existence is that it enables teams to break away from the rigid, centrally controlled procurement models that used to be the norm.

    Rather than having a finance team that acts as a central gatekeeper and bottleneck, FinOps enables teams to fully leverage opportunities available for automation in the cloud. Compared to rigid, monthly, or quarterly budget cycles—and being blindsided by cost overruns long after the fact—teams move to continuous optimization.

    Real-time reporting and just-in-time processes are two of the core principles of FinOps. Fundamentally, FinOps is about removing obstacles, and the focus is on enabling development teams to speed up their ability to deliver new features and capabilities.

    In the cloud, the reality is that teams can spin up a cloud resource with the click of a mouse. FinOps is about bringing real-time visibility to teams so, along with this instant access, there can also be informed decision making and ultimately accountability—all while fostering agility.

    Myth: FinOps is Only for the Largest Enterprises With the Biggest Cloud Budgets

    Clearly, the larger the business’ cloud investments, the larger the stakes. In addition, the larger investments, the bigger the problems that silos between technology, finance, and procurement can create.

    The goal for FinOps is to establish the people, processes, and technologies that enable more intelligent decisions about cloud investments. Ultimately, FinOps enables teams to ensure that each dollar spent in the cloud is delivering the most business value. Given that context, it is clear FinOps is invaluable for any organization making investments in cloud services. This is particularly true as organizations become more reliant on more cloud vendors and service types and more internal teams begin to access services.

    Establishing a strong FinOps practice can support growth in cloud investments while equipping teams to ensure better those bigger investments will yield maximum business value.

    In my experience, it seems that most organizations take on the creation of a FinOps practice after encountering significant issues, such as massive cost overruns or major snafus that impede operations. It is far better to make this move proactively before issues and obstacles arise. Further, the sooner the move is made, the sooner the business benefits.

    Conclusion

    As organizations’ investments in cloud services continue to grow, FinOps is becoming an increasingly vital discipline. FinOps offers teams a way to make more informed cloud investments and ultimately ensure those investments yield maximum business value. Consequently, FinOps represents a key aspect of cloud governance, which also requires teams to ensure security, compliance, and operational policies are constantly adhered to.

  • FinOps Cloud Cost Optimization via Governance-as-Code 

    FinOps Cloud Cost Optimization via Governance-as-Code 

    Cloud implementations continue to grow in scope and complexity. Too often, this expansion also means costs keep spiraling out of control. In this article, we’ll examine why the emerging practice of cloud financial management (FinOps) is so essential to containing costs in the cloud. We’ll then discuss the challenges teams encounter as they start to apply FinOps approaches. Finally, we’ll reveal the opportunity presented by employing governance-as-code to establish continuous cloud cost optimization—and how this approach makes it practical for teams to put the theory of FinOps into practice so they can keep cloud costs in check.

    The Emergence of FinOps

    For many organizations, there’s been a race to leverage cloud services, with teams seeking to realize advantages in flexibility, agility and efficiency. Within an organization, it’s not only a matter of more workloads running in the cloud, it’s a matter of more distinct deployment models being used, more teams using cloud services and leveraging multiple service providers.

    In the process, teams have had to contend with rapid growth in the size and diversity of the implementations that have to be managed—and paid for. It is this latter aspect that has been a rude awakening to those responsible for managing budgets. Left unchecked, this growth in cloud use has led to spiraling costs and predicting, managing and controlling these costs only grows more difficult as deployments get more complex and more frequent.

    This need for improved cost management has given rise to a new discipline: Cloud financial management; or FinOps. In short, FinOps is a way of bringing financial discipline and accountability to the variable-cost paradigm found in the cloud. FinOps brings together a combination of technologies, processes and teams, including professionals from technology, finance and business. By gaining an improved ability to understand, track and manage cloud costs, teams can begin to maximize the value realized through their cloud expenditures. Given the strategic and urgent nature of cloud cost management, it’s not surprising that FinOps teams are growing. According to research conducted by the FinOps Foundation, FinOps teams expanded 47% over last year, and these professionals are expecting their teams to grow 75% in the next year.

    Challenges in Establishing FinOps

    While there’s a lot of promise behind the establishment of FinOps practices, there are also many obstacles standing in the way for teams. When the FinOps Foundation queried respondents about top challenges, these were the top five responses:

    • Getting engineers to take action (39%)
    • Dealing with shared costs (33%)
    • Accurate forecasting (26%)
    • Reducing waste or unused resources (25%)
    • Full allocation of costs (23%)

    Lacking comprehensive control and visibility over multi-cloud environments means these teams can’t proactively manage costs—and too often find out about wasted expenditures and high costs of underutilized resources after the fact. Because stretched teams are reliant upon manual follow-ups and tactics, it is difficult to get engineers to respond as quickly and effectively as needed.

    Compounding these challenges is the fact that across teams, different tools and processes are used. For example, different development teams might be using different provider services along with varying deployment tools, such as AWS Cloud Formation, HashiCorp Terraform, Kubernetes and so on. This inconsistency introduces inefficiencies and miscommunication and stifles team productivity.

    While the cloud offers a range of benefits compared to legacy, on-premises infrastructure, without proper governance, cloud costs can quickly spiral out of control. In fact, Gartner analysts report that in the next few years, 60% of organizations will encounter cost overruns in public clouds.

    Rethinking Cost Management

    For all the reasons articulated above, teams are being asked to take a new approach to cloud cost management, one that aligns with the principles of FinOps. For many, this means embracing the concept of governance-as-code to optimize cloud costs. Cloud governance-as-code represents a way to automatically and dynamically apply policies, including for cost optimization, in fast-changing cloud environments.

    With governance-as-code approaches, policies are defined using a standard language. Code associated with cost policies is created, deployed and maintained in much the same way developers manage application or infrastructure code. Developers don’t have to worry about tracking or managing costs. Cost policies are continuously evaluated against current state, utilization and configuration of cloud infrastructure. If any violations occur, automated notifications and workflows can be triggered. Here are the key requirements for using governance-as-code to establish continuous cloud cost optimization:

    Cost Policies are Defined via an Intuitive Language

    Traditionally, development, operations and financial groups worked in silos. Each team had its own tools, workflows and policies, and even fundamental terminology could vary substantially.

    To maximize the potential of continuous cloud cost optimization via governance-as-code, solutions need to enable teams to define, manage and revise policies using an easy-to-understand, consistent language. This makes it much easier for different teams to collaborate and gain alignment on key cost management policies and best practices.

    Finally, to be effective in establishing continuous cloud cost optimization, governance-as-code offerings need to employ a language that is independent of any specific programming languages that application developers may use. Further, these languages should be applicable to the broadest set of applications, cloud services, development tools and so on. This is vital to ensure that development teams retain maximum flexibility in the tools and services they can use.

    Cost Policies are Managed and Deployed via Git Within CI/CD Workflows

    Once policies are reviewed and finalized, teams must be able to apply these policies within the development organization’s existing continuous integration/continuous delivery (CI/CD) workflows.

    Through robust governance-as-code approaches, teams can create cost policies as code artifacts and deploy them via open source version control systems like Git. Through this approach, teams can apply policies in a manner consistent with their software development and delivery life cycles.

    By codifying cost governance in this way, cost controls can be deployed via Git within a CI/CD pipeline. This approach enables teams to avoid complex manual processes associated with tasks like managing tickets, requesting changes and so on. This also helps teams keep up with the accelerating pace of today’s dynamic cloud and development environments. Further, this approach means governance code can be traced through various state changes, rolled back if needed and so on, just like application code.

    Cost Policy Violations are Detected and Addressed in Real-Time

    Through continuous cloud cost optimization via governance-as-code, teams are  empowered to institute not only continuous detection but also immediate action. Policies can be employed at regularly scheduled intervals or they can be triggered based on certain events.  This approach enables enforcement of workflows and actions that may be required. If policy violations occur, notifications to relevant teams or team members can happen automatically and advanced workflows can be triggered. For example, a policy could identify RDS instances greater than 30 days old that have had no connections in the last 14 days. It would then notify the owners of these instances. If they don’t take action in seven days, the instances could automatically be stopped.

    Cost Policy is Continuously Enforced and Refined

    Continuous cloud cost governance-as-code has a never-ending life cycle, just like the team’s software development life cycle. Cost governance code is built, deployed, tested and released, and the process continues as new policies are developed and refined over time. As requirements change, teams need to be able to periodically analyze cost data and update policies as needed.

    As organizations continue to invest larger sums in their cloud implementations, the need to establish strong FinOps capabilities will only grow more critical. However, as these cloud deployments continue to grow more complex, it can get increasingly difficult to realize the promise of FinOps. For these reasons, employing governance-as-code to establish continuous cost management is emerging as a key approach. With this approach, teams can achieve sustained compliance and minimize waste.

  • Rethinking Your Approach to Ops Governance

    Rethinking Your Approach to Ops Governance

    The “You build it, you run it” approach has changed the mindset of modern organizations that are increasingly adopting DevOps practices. No longer completely beholden to the requirements of operations, engineering teams are continually acquiring more autonomy to deliver rapid innovation. At the same time, more organizations are adopting platform teams to accelerate development, empowering teams with easier access to services without requiring them to understand the underlying complexity. While this approach is helping teams build, scale and ship software faster, it’s also resurfacing previous areas of tension around operational governance. 

    Organizations are generally choosing between two governance approaches: Mandated or paved path. Each has a different perspective on the appropriate level of autonomy to grant development teams and where governance should sit within the development life cycle. But there’s a third approach—the “trust and verify” approach—that can provide both high levels of autonomy for development teams and the sophisticated governance that operations teams need to ensure compliance and security.

    What is a Platform Team and Why are Organizations Adopting the Model?

    A platform team provides a foundation of self-service APIs, tools, services, workflows and support that accelerates the delivery of digital services and products. Platform teams operate similarly to any R&D team; employing customer support, operations, development, SRE, product managers and other personnel. They use research, customer feedback and usage data to iteratively improve their services.

    Rather than each development team reinventing the wheel, the platform team builds shared services that shield developers from the underlying complexity of infrastructure and enable self-serve access to services. As engineering resources become even more in-demand and scarce, organizations are using platform teams to optimize resources and share outputs.

    Two Platform Governance Approaches: Mandated Vs. Paved Path

    Organizations today typically are using one of two approaches to platform governance: Mandated or paved path.

    A mandated approach solves the governance problem by mandating that all engineering teams use the platform. However, this approach puts the onus on the platform team to keep up with the changing demands of engineering. Organizations must invest in a platform team that can keep up with engineering requirements so they still feel like they can innovate and use the best tools.

    The second approach is a paved path, popularized by Jeff Lawson of Twilio. This allows for engineers to go outside the platform if they are willing to take on the SLAs the platform provides and are responsible for all the costs of maintaining their own alternatives. Lawson said in this McKinsey interview, “What you do is you create the incentive structure for teams to take the paved path. But if they really have to go a different route, you make it possible for them to do that.”  

    While the paved path approach offers more autonomy for engineering teams, it requires teams that veer off the path to maintain the integrity of their software. Without guardrails, operations must put full trust in teams to keep their services secure and compliant. It can often be difficult for operations teams to maintain visibility into the services and infrastructure that fall outside the core platform.

    So, given that a mandated approach restricts autonomy and a paved path can make compliance more difficult, what is the middle ground?

    Bridging the Gap Between Mandated and Paved Path

    First, it’s important to understand that governance is not synonymous with command and control. Instead, operations teams should think of governance as the practice of maintaining visibility and providing best practices. Rather than a mandated platform approach, organizations can choose an approach that offers more autonomy to engineering teams (similar to paved path) while also maintaining operational governance. This is a trust and verify approach. 

    Using the trust and verify approach, organizations should focus their efforts on technology, not people, to maintain compliance. The goal would be to have a platform that could easily connect to the entire toolchain any product team uses for complete visibility and context. In this way, operations can gain governance without adding friction for product teams. This requires a top-down approach within organizations: I&O leaders investing in engineering resources or an off-the-shelf platform that can enable this technology. Both engineering and operations can flourish in this modern environment. Approaching governance from a trust and verify perspective will expand access to innovation while ensuring compliance and security standards. 

    Governance Should be Over Technology, not People

    Creating a bridge to a trust and verify approach means placing the responsibility for governance on technology rather than people to maintain detailed audit trails of human and machine actions tied to identity and reduce the potential for human error through automation. This approach provides autonomy for engineering teams while also ensuring governance through visibility and process controls embedded into workflows and tooling. 

    Shellie Miller, senior manager, technology governance and compliance at Hulu, believes technology can support DevOps practices. “To have a successful DevOps organization, we don’t need to have command and control or have this clear line of separation between dev and operations. It’s putting the responsibility on the infrastructure, the platform and the tooling and the policies and the processes that you have to enable those self-serve capabilities,” Miller said. 

    Mitigating Human Error Through Automation

    This investment in technology should focus on automation and process controls that fit within teams’ current processes. “What auditors are really trying to do is mitigate human error,” said Miller. “Teams should really focus on automating controls, building those security practices and those best practices into the platform. That way, dev teams are just subscribing to that offering.” 

    Changes to applications, systems, data and code—one of the biggest culprits with regard to risk—is where automation and process controls embedded into platform offerings can make a huge impact. “From an engineering perspective, constant change is needed to support rapidly changing consumer demands,” Miller added. “However, from an audit perspective, these activities increase risk of material impact to viewer experience, revenue and/or financial reporting.”

    Investment in Governance Comes From the Top

    While technology holds the key to better governance and compliance standards, there’s an investment that must be made, whether that’s investing engineering resources in building automation or investing in an off-the-shelf platform that can enable automation.

    “Leadership and organizational backing is absolutely key,” said Miller. “You can’t get to compliance or governance or any kind of operational maturity, for that matter, when you’re doing a bottom-up approach.”

    Building a compliance and security program around technology and not people means having the proper skills and mindsets. A bottom-up approach could create friction, especially due to a lack of education and understanding of the why and how. A top-down approach ensures there are resources to both implement the technology and to foster a culture of understanding and education. 

    The most common question I get asked is, ‘Why can’t we trust our people?’” Miller said. “Compliance requirements don’t generally start with the thought that our people are being malicious. We should run an organization of trust, and through automated monitoring and governance, we can verify and govern without being intrusive and disruptive. Lack of training and the demand on teams is what drives the perception that there’s no trust. Security and compliance is intended to mitigate risk and prevent threats to the systems that enable the business.”

    Building on a “Trust and Verify” Platform Approach

    When it comes to governance, technology is our greatest asset. Of course, this investment can be substantial for many organizations that don’t have the engineering resources to build in-house. Today, new open source or off-the-shelf platforms enable operations teams to build self-service capabilities that provide guardrails against human error, an audit trail of human and machine actions and visibility across disparate tools and services. 

    No-code solutions that also provide a developer platform for deeper customization enable teams to build out these core requirements of governance without consuming considerable engineering resources. The door to a future where operations teams can provide more autonomy to development teams while maintaining governance is now open. Every organization has the ability to attain a “trust and verify” approach and meet the needs of both dev and ops.

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021

  • IT Modernization Yields Business Benefits Even in Early Stages

    IT Modernization Yields Business Benefits Even in Early Stages

    In recent years, with the emergence of newer technologies ranging from the cloud to machine learning, IT modernization has evolved from a replacement of end-of-life infrastructure to an enabler of innovation and business value. It is a complex process that can take months or even years, but a recent survey shows that the effort begins to deliver measurable results almost as soon as an organization executes the first steps on its roadmap.

    In The State of IT Modernization 2020, an IDG Research Services survey of 200 IT executives commissioned last December by Insight Enterprises’ Cloud + Data Center Transformation team, respondents that had completed 25% or less of their initial modernization objectives reported achieving business improvements in each of the eight categories measured. Sixty-five percent had already achieved better quality of service. Significant progress had also been made in improving customer experience/satisfaction (52%), cost savings (50%), uptime (44%) and the ability to create new revenue-generating products and services (42%). 

    Organizations that had completed their initial modernization objectives reported even better outcomes on all eight measures, notably including the ability to extract business value from data (56%) and faster time to market for new products and services (50%). 

    The findings clearly demonstrate that a modernized IT ecosystem is a core building block of business transformation. Whether it’s spinning up a new service or application quickly, doing a deep data dive to identify new market opportunities or using artificial intelligence to improve sales forecasts or warehouse operations, it’s essential to have the horsepower, agility and advanced data analysis capabilities to do the job.

    The survey of CIOs, CTOs, CSOs and IT directors working at organizations with an average of 29,294 employees also revealed a wide range of details about the status of IT modernization efforts. Let’s look at some examples.

    Progress Made

    Fifty-six percent of the enterprises surveyed have either achieved initial IT modernization objectives or have made significant progress toward doing so, while 19% have made moderate progress and 26% are in the beginning stages. Interestingly, even those in the earliest stages are pursuing emerging technologies such as AI, machine and/or deep learning (43%), automation to support scale-out and other cloud strategies (37%), cloud native application development (35%) and public cloud container services (35%). 

    Projects Derailed 

    Despite this progress, the road to IT modernization can be bumpy. Forty-one percent of survey respondents reported having delayed or abandoned some of their 2019 IT modernization initiatives. The top reasons cited were competing priorities (46%) and lack of a clear roadmap or strategy (45%). Other causes included data security concerns (39%), inadequate in-house expertise (38%), poor preparation (29%) and outdated processes or tools (27%). 

    Shifting Cloud Strategy

    Whether they have just embarked on their IT modernization journey or have made significant progress on their roadmap, organizations continue to grapple with optimizing their cloud strategy. The survey showed that:

    • Ninety-two percent of survey respondents increased workloads deployed in the public cloud and 91% in the private cloud in 2019, reflecting the ongoing increase in cloud adoption as well as migration from one platform to another.  
    • Eighty-nine percent switched or planned to switch from an all-private or all-public cloud strategy to a hybrid cloud approach – and 87% adopted a multicloud approach using more than one public cloud provider – as they attempted to find the right path for their cloud needs.
    • Eighty-four percent moved select workloads from a public cloud to an alternative cloud or non-cloud location, suggesting a failure to perform appropriate cost modeling, workload/platform alignment and other due diligence before the initial move.

    Poor Public Cloud Cost Controls

    More than two-thirds of survey respondents reported that public cloud costs exceeded their expectations, with cost overruns for roughly half that group ranging from 51% to 100%. Most of the causes can be traced to inadequate due diligence, governance or cloud optimization efforts, often due to a lack of in-house expertise in these areas. Examples include: unexpected data egress charges, subscribing to more cloud resources than required, failure to take advantage of vendor volume discounts, lack of knowledge to analyze monthly cloud costs and failure to optimize cloud workloads to extract maximum value from cloud platforms.

    Managed Services

    Adoption of managed services is widespread at every stage of the IT modernization journey, with an average of 95% of respondents outsourcing one or more IT operating environment functions to a managed services provider and 84% outsourcing cloud management. 

    Top Challenges Faced

    Governance is the number one modernization challenge in 2020, according to survey respondents, with new strategies and processes required to ensure control over areas ranging from cloud deployments to continuous integration and continuous delivery (CI/CD), automation and orchestration, and infrastructure as code. Optimizing and managing the centers of data that are replacing the traditional data center ranks as number two, with workloads located on-premises and in multiple clouds as well as on the edge.

    At the same time, most IT organizations have long-standing cultural and technological norms that need to change in order to move modernization initiatives forward. Hurdles cited elsewhere in the survey range from IT silos to outdated processes and tools, understaffed or underskilled DevOps teams and lack of enabling technology for containerization and automation.

    These challenges also need to be overcome in order to take full advantage of today’s technology to drive innovation, business transformation and the competitive edge that can help businesses both survive and thrive in today’s economy.