devopsy.kinsta.cloud

Category: DevOps Practice

  • Transitioning Legacy Systems to DevOps: The XDR Support Paradigm

    Transitioning Legacy Systems to DevOps: The XDR Support Paradigm

    In today’s rapid and evolving technological landscape, DevOps emerges as a frontrunner in development methodologies, promising agility, efficiency and continuous delivery. While companies are keen to leverage its benefits, the transition from legacy systems can be fraught with challenges. Integrating extended detection and response (XDR) while making this transition can serve as a powerful tool to manage these challenges. In this article, we will delve deep into the potential pitfalls of this transition and explore the remedial measures with the aid of XDR solutions.

    The Legacy System Quagmire

    Legacy systems are often monolithic, siloed and heavily dependent on older technologies. According to a report by Forrester, a staggering 72% of corporate architectures still run on legacy systems. These systems, while operational, often lack the flexibility and scalability required for a DevOps-driven environment. They can become roadblocks, slowing down processes and becoming vulnerable points of failure.

    The Inherent Challenges

    Scalability Concerns: DevOps emphasizes scalability. However, legacy systems weren’t built with this level of dynamism in mind. Most legacy systems face scalability issues when introduced to DevOps practices.

    Security Vulnerabilities: The older tech stacks are more vulnerable to modern-day threats. Without continuous updates, these systems become an attacker’s paradise. This is where XDR solutions come into play, offering real-time threat detection and response across the infrastructure.

    Integration Hurdles: Legacy systems often struggle to integrate with modern tools used in DevOps, from container orchestration tools like Kubernetes to configuration management tools like Ansible.

    XDR to the Rescue

    Holistic Threat Detection: XDR’s primary strength lies in its comprehensive threat detection across networks, clouds, endpoints and applications. This compensates for the potential vulnerabilities of legacy systems, providing a safety net.

    Real-time Responses: XDR doesn’t just detect threats; it actively responds to neutralize them. As per a study by IDC, integrating XDR can reduce incident response times by up to 50%, ensuring that any security breach on legacy components is swiftly managed.

    Forensic Capabilities: Understanding the root cause of issues is paramount. XDR solutions come with forensic capabilities, allowing teams to understand the “how” and “why” behind incidents, an essential feature when dealing with older systems that may lack documentation.

    Migrating With Minimal Friction

    Training and Skill Development: One of the most underrated challenges is the lack of skills in managing and migrating legacy systems. Investing in training and reskilling can bridge this gap. A recent survey by DevOps Institute revealed that 72% of organizations that prioritized skill development found transitions, including to DevOps, smoother and more efficient.

    Pilot Programs: Before a full-blown transition, it’s wise to run pilot programs. This involves migrating a smaller, non-critical segment of the legacy system and integrating XDR support. The lessons learned here can guide the broader migration.

    Continuous Monitoring: Post-migration is not the time to be complacent. Using XDR’s monitoring capabilities, teams should continuously oversee the newly migrated segments for any anomalies or performance issues.

    Infrastructure-as-Code (IaC) and Legacy Systems

    Bridging the Gap with Automation: DevOps heavily leans on the principle of automation, and infrastructure-as-code (IaC) plays a pivotal role in achieving this. However, legacy systems often don’t align seamlessly with IaC principles. By using IaC platforms like Terraform or CloudFormation, organizations can create templates for legacy systems, making them more malleable for DevOps operations.

    Ensuring Compliance: One challenge with legacy systems is maintaining compliance, especially when regulatory standards evolve. IaC, when coupled with XDR’s continuous monitoring, can ensure that these older systems remain compliant. According to a 2021 report by Puppet, companies that adopted IaC methodologies witnessed a 60% faster compliance update implementation time on their legacy systems.

    Cultural Shifts and Organizational Dynamics

    The Human Element: While the technical challenges of migration are tangible, the human element is often overlooked. Employees used to legacy systems might resist transitioning to DevOps practices, fearing obsolescence or due to comfort with older methods.

    Change Management: Addressing this requires an organized change management strategy. Workshops, seminars and constant communication can assuage fears and foster a culture of continuous learning. A study by the Harvard Business Review highlighted that organizations that integrated change management strategies had a higher success rate in technical transitions, including shifts to DevOps models.

    Collaborative Approach: It’s essential to foster a collaborative environment where both legacy system experts and DevOps enthusiasts work together. XDR’s collaborative tools can be instrumental here, providing a platform where teams can discuss XDR solutions, share insights and collaboratively respond to threats.

    Conclusion

    Transitioning from legacy systems to a DevOps model is not a mere technical challenge; it’s a transformative journey for the entire organization. The challenges, while significant, are not insurmountable, especially with tools like XDR providing support. By understanding the pitfalls and leveraging advanced solutions, businesses can ensure a smooth transition and harness the power of DevOps to its fullest.

  • 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.

  • How to Navigate App Modernization Strategies for the Cloud

    How to Navigate App Modernization Strategies for the Cloud

    In today’s fast-paced digital landscape, organizations continuously seek ways to innovate and enhance customer experiences while optimizing efficiency. One of the most transformative strategies is modernizing applications for the cloud. App modernization isn’t just a technology upgrade. It’s a holistic business transformation. The cloud’s elasticity and scalability present opportunities to create deeper customer engagement, foster seamless partner integration and unlock valuable data insights. However, this requires a thoughtful approach that aligns with business goals and technological aspirations.

    Let’s look at some best practices for modernizing apps for the cloud and navigating potential challenges.

    The App Modernization Process

    It’s important to determine whether the cost of migration will lead to better efficiency and customer engagement that will yield an increase in return on investment (ROI). This approach allows businesses to address current issues and future-proof their data stacks.

    After assessing the cost and ROI considerations, organizations need to follow a systematic process to successfully modernize an app for the cloud. The first step is to evaluate the existing app’s strengths, weaknesses and areas for improvement. It’s crucial to assess an app’s compatibility with cloud platforms and set clear modernization goals.

    Following the assessment, design a cloud-native architecture that aligns with the cloud’s scalability, elasticity and distributed nature. This may involve rearchitecting the app to include such cloud-native components as microservices, containers, or serverless computing. Once the architecture is in place, migrate the app’s data from on-premises or legacy databases to cloud-based storage solutions to ensure data availability, scalability and ease of management in the cloud environment.

    The next step involves rewriting or modifying the app’s codebase to take advantage of cloud services and APIs. Specific modules or functionalities may need to be re-engineered to enhance performance, scalability and integration capabilities. Perform comprehensive automated load and security testing to verify reliability and performance in the cloud.

    Once the modernized app has been tested, deploy it on the selected cloud platform. Implement monitoring and logging mechanisms to gain insights into the app’s behavior, performance and user experience so it operates effectively in the cloud environment.

    Navigating App Modernization Challenges

    While the benefits of app modernization are significant, challenges can arise during the process.

    One of these hurdles involves dealing with legacy constraints. Legacy applications often have complex architectures that complicate modernization. Careful planning is required to update outdated technology stacks and move from a tightly coupled system to a loosely coupled one.

    Another obstacle pertains to data migration complexities. Transferring large amounts of data from on-premises systems to the cloud demands meticulous planning and execution to maintain data integrity, security and minimal downtime.

    Integration presents another potential difficulty. Modernized apps often need to integrate with other systems, both on-premises and in the cloud. Many cloud vendors offer tools and programs to aid in migrating data. These, coupled with credits to be used as apps are migrated, can significantly reduce costs.

    Security and compliance are critical considerations when moving to the cloud. Cloud environments require robust security measures to protect sensitive data, and organizations must comply with relevant regulations and industry standards.

    Effective change management strategies are another aspect to consider to ensure a smooth transition for users and stakeholders. App modernization is a business process modernization representing a significant change in business operations.

    In-House Vs. Outsourced App Modernization

    Choosing between in-house and outsourced app modernization depends on several factors.

    First, if an organization has skilled developers with cloud expertise, handling app modernization in-house is a viable option. On the other hand, if a team lacks the necessary skills, it may be more practical to outsource the task to a cloud service provider or a specialized development partner. It should be noted that if the development work is outsourced, it’s important to keep the app business owners involved to ensure that the modernized solutions yield the expected benefits.

    Another consideration is the availability of resources, such as time, budget and staffing. App modernization projects require dedicated efforts, and outsourcing becomes appealing if internal resources are limited. By entrusting the project to external professionals, organizations can ensure it receives the attention and resources needed without burdening the internal team.

    Evaluating whether app modernization aligns with an organization’s core competencies is also essential. If the application is not directly related to the core business, outsourcing can free up internal resources and redirect them toward more strategic initiatives. This allows an organization to concentrate on areas in which it has a competitive advantage and expertise while still benefiting from the app modernization expertise of external partners.

    Pioneering the Future

    Modernizing an app for the cloud is a transformative journey that holds the potential to enhance customer experiences, optimize processes and unlock valuable insights. Navigating challenges through meticulous planning, robust testing and adherence to standards are crucial, whether opting for in-house expertise or external collaboration. By embracing cloud-native principles and using advanced technologies, organizations can position themselves at the forefront of innovation, ensuring lasting success in the dynamic landscape of the digital era.

  • Improvement Cycles and AI

    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.