devopsy.kinsta.cloud

Category: DevOps Practice

  • Cloud Disaster Recovery Best Practices

    Cloud Disaster Recovery Best Practices

    It’s increasingly common for companies in all sectors to use the cloud to store their data. The cloud provides scalability, security and flexibility that was often inaccessible to businesses only a few years ago. But just like any other technology, it has its limits.

    What happens if a severe thunderstorm knocks out power to a data center or if an employee accidentally deletes critical files? These are the types of scenarios that, however unlikely, can still happen and cause significant disruptions to a company if they’re not prepared.

    That’s where cloud disaster recovery comes in. In this article, we’ll discuss why cloud disaster recovery is critical for businesses and the different strategies you can implement to ensure your data is always safe and accessible.

    What Is Cloud Disaster Recovery?

    Cloud disaster recovery (CDR) is a strategy that helps businesses keep their data safe in the event of an unforeseen disaster. This can be anything from a natural disaster like a flood or earthquake to a man-made disaster like a power outage, fire or cyberattack.

    There are many different cloud disaster recovery strategies that businesses can implement, but the most important thing is to have a plan in place so that you know what to do if and when something goes wrong.

    One Company’s Story of Cloud Impact: OVHCloud

    Before providing strategies, we wanted to give you a real-life example of a cloud disaster that impacted multiple businesses, big and small.

    In 2021, OVHCloud, one of the world’s largest cloud service providers, suffered a catastrophic fire at one of its data centers in Strasbourg, France. The fire destroyed the facility, causing widespread damage and leaving many businesses without access to their critical data.

    In the aftermath of the fire, it quickly became apparent that OVHCloud did not have a solid cloud disaster recovery plan. As a result, many businesses were left scrambling to find alternative solutions for their data storage and backup needs.

    The moral of the story is that even the biggest and most well-known companies can be caught off guard by a disaster. This is why it’s so important for businesses of all sizes to have a cloud disaster recovery plan.

    Now that we’ve seen the importance of cloud disaster recovery, let’s look at strategies you can implement to keep your data safe.

    Cloud Disaster Recovery Strategies

    When discussing cloud disaster recovery strategies, many options are available, but not all of them will be right for every business. The key is to find the strategy or combination of strategies that work best for you and your company.

    Here are some of the most common cloud disaster recovery strategies:

    1. Know Your Infrastructure

    The first step in any cloud disaster recovery strategy is to understand your current infrastructure and what assets and data you have. Your assets can include everything from physical servers and hard drives to cloud-based applications and data. 

    Do the homework necessary to understand what you have and where it’s located. For example, take inventory of all of your assets and determine which ones are critical to your business operations. 

    Once you know what you have, you can start to develop a plan for how to protect it. Yes, this may take some time, but it’s an essential step in protecting your data.

    2. Conduct a Business Analysis

    Data breaches within the cloud can come in many different forms. From unexpected data loss to malicious cyberattacks, it’s important to understand the different ways your data could be compromised. This is where conducting a business impact analysis comes in.

    A business impact analysis (BIA) is a process that focuses on identifying and evaluating the potential risks to your business. Rather than focusing on the causes of the breakdown, a BIA focuses on the potential impact of the disruption. The impact can include things like loss of income, damage to reputation and compliance issues.

    By conducting a BIA, you can better understand the risks your business faces and what steps to take to protect against them. For example, using endpoint security vendors can help protect your data by preventing attacks on endpoints on or off the network.

    3. Draft a Disaster Recovery Plan Based on RPO and RTO

    Once you’ve conducted a BIA and clearly understand the risks your business faces, you can start to draft a disaster recovery plan, specifically around the recovery point objective (RPO) and recovery time objective (RTO).

    Your RPO measures how much data is lost during a disruption, while your RTO measures how long it takes to recover from it. By understanding these two factors, you can start putting together a plan that meets the specific needs of your business.

    It’s important to note that your RPO and RTO will likely differ based on the type of data you’re working with. For example, if you’re working with data that can be easily recreated, your RPO may be relatively low. However, if you’re working with mission-critical data that can’t be easily replaced, your RPO will be much higher. The same is true for RTO.

    Regardless, you want to ensure that your disaster recovery plan is based on your specific RPO and RTO so you can recover from a disruption promptly and with minimal data losses.

    4. Have a Strong Cloud Backup Solution

    No matter what cloud disaster recovery strategy you implement, it’s essential to have a strong backup solution in place. It will ensure that you can quickly pivot to a different strategy and dodge the hefty price tag that often comes with data loss and encrypted files when there’s no backup.

    There are several different backup solutions available, so you must find one that meets the specific needs of your business based on the type of data you have and how often it changes.

    5. Test Out Your Disaster Recovery Plan Regularly

    Once you have your disaster recovery plan in place, it’s important to test it out regularly. Testing will ensure that your plan works as intended and that you can recover from a disruption quickly. Things to test for include data backups, file restores and application availability.

    You should also involve your entire team in the testing process so everyone knows what to do in the event of a disruption. Look for collaboration software that comes with important tools such as chat, video conferencing and task management so your team can easily communicate and work together, even when they’re not in the same place.

    Final Thoughts

    There you have it! These five cloud disaster recovery strategies can protect your business from data loss and keep your operations running smoothly. We suggest starting this process as soon as possible so you can be well-prepared for whatever comes your way.

  • OpenSSL Fiasco: What can DevOps Learn? | Elon Fires ‘50%’ of Twitter

    OpenSSL Fiasco: What can DevOps Learn? | Elon Fires ‘50%’ of Twitter

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The OpenSSL project has egg on its face, and half of Twitter’s staff are for the chop tomorrow. (more…)

  • Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod today revealed it will add an application programming interface (API) to make cloud development environments (CDEs) more extensible. Gitpod also said Johannes Landgraf assumed the role of single CEO for Gitpod, as the previous co-CEO, Sven Efftinge, becomes the company’s first technical fellow.

    Fresh from raising an additional $25 million in funding, Gitpod’s Landgraf said that API will make it easier to build plug-ins for CDEs. In time, Landgraf said, CDEs will become as accessible as any development environment running on a local desktop.

    Software engineers typically waste five hours a week maintaining application environments, noted Landgraf. Via an open source development platform, Gitpod automates the provisioning of secure workspaces in the cloud that provide the added benefit of making it easier for multiple developers to collaborate, he added.

    Capabilities added to the GitPod product roadmap include dramatically faster startup times, improved resiliency and a Gitpod Cloud offering for larger companies as well as a preview environment and workflows that foster collaboration. Gitpod also announced it passed a SOC2 Type II security audit.

    Today, the Gitpod platform is being used by more than 750,000 developers at organizations such as Shopify, Stripe and Slack, noted Landgraf.

    One of the longstanding issues that has always been problematic when building software is that code that runs on a local desktop doesn’t always work when deployed in a production environment. The Gitpod API will make it simpler to spin up various platforms and tools whenever a developer accesses a CDE. The goal is to make it possible to more closely replicate the production environments on which developers will ultimately deploy their applications, noted Landgraf.

    In addition, a CDE should reduce the amount of data that developers routinely move between laptops and cloud computing environments as they build more complex applications, he added.

    In the wake of the economic downturn, there is a lot more focus on developer productivity these days, especially as organizations look to accelerate their of digital business transformations. DevOps teams are also keen to find ways to centrally manage developer experience at a time when many of those developers continue to work from home, said Landgraf.

    It’s not clear to what degree CDE will replace integrated development environments (IDEs) running on a local machine, but all the major cloud service providers are encouraging developers to build applications in the cloud where their applications will run. The challenge is that many of those offerings tend to lock developers into a specific cloud platform, noted Landgraf. Most developers today are building applications that need to be deployed across multiple clouds, he added.

    One way or another, software development is increasingly shifting to the cloud. Most organizations will likely try to find a balance between the amount of code developed on a local machine that developers can just fire up when the mood strikes and the amount of code developed in the cloud. The most immediate challenge is to make sure the CDE experience is every bit as good as the existing local IDE.

  • Solving the Culture Conundrum in Software Engineering

    Solving the Culture Conundrum in Software Engineering

    The one crucial ingredient underpinning our transition to a digital-first economy, more than any other, is software. That’s why software engineering has become one of the world’s most in-demand professions. In the UK alone, the median salary for the role has increased 13% year-over-year as businesses look to stay ahead of the competition and attract the very best IT talent. But the high salary often isn’t consistent with where software developers stand in the business; many organizations still view them as suppliers rather than as crucial players in their success. Based on the current speed of transformation, we know that demand for software engineering is only going to increase. So business and technology leaders need to urgently consider vital cultural changes to help better integrate software development teams within the wider organization. But what exactly should they be?

    The Development Dilemma

    Agility has quickly emerged as a competitive advantage as businesses strive to deliver on customer expectations quickly and effectively. That’s heralded the rise of DevOps, which aims to write high-quality digital solutions more efficiently and have the ability to continuously update in a secure and low-risk way.

    The practice is already accelerating feedback loops in the software development of digital solutions on a wide scale, meaning new software is brought into production as fast as possible and with reduced risk. As a result, today’s successful businesses are now releasing software updates multiple times a day. The figure even runs well into the tens of thousands for tech giants like Amazon and Netflix. However, other businesses are struggling to keep up with the speed the market demands, largely due to a lack of clear communication, ways of working and integration between software developers and the wider business. It’s a dilemma that needs immediate attention if businesses are to remain at the competitive edge.

    Developers are too often left to deal with huge monolithic pieces of work, which require them to write code for months on end without it being road-tested. This inevitably leads to mistakes that are found only once the updates have already been released to market creating a ripple effect throughout the organization. It’s an all-too-common scenario that demonstrates business leaders’ clear lack of clarity and understanding about the colossal value adopting a DevOps culture can deliver for the wider business, including its customers.

    Take financial institutions looking to introduce a new offering, for example, such as a new mortgage product. Without a collective approach to development, getting the backend systems up and running for a product can take up to six months. But modularising the options and breaking down the functionality can shorten timelines to weeks.

    Business leaders must look to create unified, cohesive and cross-functional teams that work together on projects that are broken down into simplified and localized components that can be easily integrated together without a negative impact on each other. It might seem like a small strategic change in working practices, but its impact on the speed and efficacy of software development can be enormous.

    Revisiting Personalities and Processes

    The role of the software engineer has changed; it is no longer about writing code in isolation without much regard for or knowledge of how it benefits the business. Developers work better when they have clarity about the direct impact their work will have on achieving business goals and on the bottom line. It’s down to business leaders to communicate these challenges and goals (in other words, understand the “why”) to help software developers understand what they’re trying to achieve. But doing so in a way that moves towards a better working culture requires a new approach to building and managing software development teams.

    The first step is casting aside the negative stereotypes many have of software engineers and celebrating the intellectual and cultural diversity within their teams. Diversity of personnel brings a diversity of personalities, which is crucial to creating more inclusive cultures that accept and welcome all characters with open arms. While this may seem obvious, what is often overlooked is the impact diversity can have on stimulating and increasing innovation.

    Improving the diversity of development teams helps unlock multiple ways of responding to and analyzing the challenges brought forward by business leaders. After all, each individual has an array of different soft and hard skills based on their learning, development and experience. So, encouraging individuals to bring their characters and personalities to their roles is crucial; it ensures each and every stakeholder in the development process is empowered to contribute, feels inherently valued, and is able to challenge existing assumptions, helping deliver a more robust end product.

    Recognizing and harnessing this spectrum of skills also helps bridge many of the barriers to development that exist within businesses. Some software engineers, for example, might struggle to communicate technical updates in a way the wider business can understand, but tapping into another individual’s strong communication skills can help unite teams–and entire businesses-around one, holistic digital strategy.

    Channeling Change to Deliver Better Outcomes

    Clearly, cultural change is needed to embed software engineering at the core of modern business. But revisiting project management practices is also imperative to continually deliver software that provides value to the business, the world of scientific management and Waterfall delivery methods is no longer appropriate for the development of digital solutions. With such a heavy reliance on digital services, businesses—and, consequently, developers—need to be able to make changes with minimal effect. So, eschewing monolithic projects and encouraging cross-functional teams is essential. Not only does it reduce the need for sweeping software updates, but it negates the risk of a project failing to meet the initial brief, which could ultimately impact the entire business.

    By reviewing organizational processes, and bringing the wider business and software developers together, we can create teams that deliver digital solutions effectively and quickly, so that every user, whether internal or external, reaps the benefits of a more sophisticated approach to software engineering.

  • Tanium Uses SBOMs to Automate Vulnerability Remediation

    Tanium Uses SBOMs to Automate Vulnerability Remediation

    Tanium this week added the ability to detect libraries and software packages with known vulnerabilities within a software bill of materials (SBOM) manifest that can then be used to automate remediation of endpoints running vulnerable code.

    Pete Constantine, senior vice president of product management for Tanium, said the Tanium Software Bill of Materials (SBOM) module provides IT teams with both the ability to discover where vulnerable code is running in real-time and automatically apply any required software patch.

    The Tanium SBOM tool examines the contents of individual files wherever they reside in IT environments to make it simpler to immediately discover where, for example, vulnerable instances of the Log4j log management software or OpenSSL software for securing communications are running. Today many IT teams are spending weeks trying to track down every potential instance of code each time a new vulnerability is discovered.

    Once those vulnerabilities are discovered, IT teams can then opt to use a Tanium Patch tool to remediate vulnerabilities or use other Tanium management tools to kill specific processes or uninstall applications, noted Constantine.

    Awareness of the need for SBOMs to secure software supply chains has increased sharply in the wake of a series of high-profile cybersecurity breaches. However, few organizations have the tools in place to operationalize the data collected in SBOMs that are essentially little more than a list of components employed to build an application. The goal is to enable IT teams to decide whether to go ahead and deploy an application based on the level of threat the vulnerabilities included represent.

    It’s unlikely that vulnerabilities will ever be completely eliminated from applications running in production environments, but it’s clear there is a need to be able to quickly identify issues based on the level of severity any vulnerability represents. The trouble is that an SBOM is only the first step toward achieving the level of remediation automation that is required to address vulnerabilities discovered in applications after they have been deployed.

    Hopefully, all the focus on securing software supply chains will lead to a narrowing of the divide that has historically existed between cybersecurity and application development teams. Developers still need to create patches to fix issues, but overall the number of vulnerabilities that find their way into production environments should decline as more organizations embrace DevSecOps best practices before applications are deployed.

    In the meantime, however, given how much developers today reuse code, the odds are good multiple vulnerabilities have already been widely propagated across an application environment. In fact, the amount of technical security debt that organizations face today is simply staggering when considering the total number of potential vulnerabilities that need to be remediated. In the absence of IT automation capabilities, it might take the better part of a decade to resolve all those vulnerabilities.

    On the plus side, however, the tools and platforms required to automate remediations are now integrated with SBOMs that, at the very least, make pinpointing where vulnerabilities are located easier. The challenge now is defining a set of end-to-end processes that make fixing all those vulnerabilities a much less arduous task for all concerned.

  • Pulumi Adds Deployment Capability to IaC Platform

    Pulumi Adds Deployment Capability to IaC Platform

    At the Pulumi Cloud Engineering Days event, Pulumi announced today it has added a code deployment capability to its Pulumi Cloud platform for managing infrastructure-as-code (IaC).

    Pulumi CEO Joe Duffy said Pulumi Deployments will make it possible for DevOps teams to provision infrastructure and deploy applications via a single Git commit that can be invoked via an application programming interface (API) or graphical tool.

    A Git Push to Deploy capability allows DevOps teams to connect to any Git repository to drive deployments for a given project path, push to any given branch and set up GitOps workflows such as pull request reviews. Deployment actions include both updates and destroys in addition to providing drift detection and remediation capabilities.

    The Deployments and Automation API Pulumi developed also enables ephemeral code review environments, automatic cleanup and deployment orchestrations across multiple cloud platforms using a library of templates Pulumi provides. In effect, Pulumi is now providing a GitOps workflow out of the box, said Duffy.

    Pulumi has already integrated these capabilities with GitHub and plans to add support for GitLab, Atlassian Bitbucket and other DevOps platforms. The goal is to make it possible for DevOps teams to effectively manage ten times the amount of cloud infrastructure resources per engineer using GitOps workflows than is currently possible relying on IaC tools such as Terraform, said Duffy.

    As an alternative to Terraform, the Pulumi platform has been gaining traction because it makes it possible to more easily centralize the management and provisioning of infrastructure using a set of embedded guardrails. One of the major issues enterprise IT organizations are encountering these days is the number of misconfigurations created when developers use tools like Terraform to provision infrastructure on their own. Those misconfigurations often lead to, for example, ports being left open and cybercriminals exfiltrating data. In the wake of a series of high-profile breaches, more organizations are now reviewing the security of their software supply chains including how infrastructure is provisioned by embedding policy-as-code into DevOps workflows.

    At the same, organizations are also keenly interested in increasing the productivity of DevOps teams during an economic downturn that limits the number of IT professionals an organization can afford to hire, added Duffy.

    Pulumi claims there are now more than 5 million users of its platform spanning more than 1,000 organizations. Less clear is the degree to which organizations are embracing GitOps workflows to unify deployments on IaC and application code. As platforms make it easier to make that transition, the number of organizations using a more opinionated approach to DevOps should steadily increase.

    In the meantime, DevOps teams are going to be required to find ways to build and deploy safer applications faster. Much of the focus in recent years has been on accelerating application deployments with little regard for cybersecurity. Those days are clearly now coming to an end.

  • Octopus Deploy Tightens Integration With GitHub Actions

    Octopus Deploy Tightens Integration With GitHub Actions

    Octopus Deploy announced today it has tightened the integration between its automated deployment platform and GitHub Actions continuous integration/continuous deployment (CI/CD) platform.

    Harsh Sabikhi, senior vice president of revenue for Octopus Deploy, said GitHub Actions for Octopus Deploy v2 adds support for a push-build-information-action capability GitHub added to its platform that enables DevOps teams to track commits, builds and issues. That information is now also synchronized with a DevOps Insights tool from Octopus Deploy that surfaces metrics based on the DevOps Research and Assessment (DORA) metrics defined by Google.

    Other capabilities added to the integration include support for semantic versioning release tags within workflows, job summaries and a revamped user interface that makes GitHub easier to access from within Octopus Deploy.

    Sabikhi said that while GitHub Actions provides some deployment capabilities, the automation platform created by Octopus Deploy automates application release management across multiple clouds and on-premises IT environments. GitHub Actions is optimized for managing CI processes within the context of a Git-based workflow emanating from a cloud service managed by GitHub, he added.

    The integration with GitHub Actions makes it simpler to extend those Git-based workflows across multiple deployment platforms, noted Sabikhi.

    GitOps is, essentially, a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. GitHub views GitOps as a means of extending a code repository into the realm of DevOps workflows using the GitHub Actions platform.

    As organizations embrace GitOps, however, many are finding it advantageous to more loosely couple CI and CD platforms. Integrated CI/CD platforms have been around now for more than a decade, but few organizations have been able to truly automate the delivery of applications using those platforms. Platforms such as Octopus Deploy have been created from the ground up to specifically manage deployments of applications. In addition to GitHub Actions, Octopus Deploy also provides integrations with multiple other CI platforms to enable DevOps teams to mix and match CI platforms as they best see fit, said Sabikhi.

    It’s not clear how many DevOps teams are willing to acquire a separate CD platform, but as applications become more challenging to build and deploy in the cloud-native era many organizations are revisiting the DevOps processes they used to build and deploy monolithic applications. The challenge is many of them have spent years defining workflows based on legacy CI/CD platforms, so there is a lot of existing inertia that would need to be overcome when adopting a dedicated CD platform.

    It’s clear that CD is finally becoming more achievable using platforms that automate much of the process. Each DevOps team will need to decide how many staff they want to dedicate specifically to managing those CD platforms; the pace at which applications are being deployed should accelerate as application release management becomes more automated.

  • Opsera Brings DevOps Intelligence to GitHub Actions

    Opsera Brings DevOps Intelligence to GitHub Actions

    Opsera today announced it has extended its platform for collecting DevOps intelligence to include support for the GitHub Actions continuous integration/continuous delivery (CI/CD) platform.

    Opsera CEO Kumar Chivukula said as GitHub Actions is adopted more widely, there is a growing need to provide greater visibility into Git-based workflows in real-time. A GitHub Actions Insights module for the Opsera platform makes it possible to track key performance indicators (KPIs) across those workflows, he added.

    The goal is to make it simpler to make data-driven decisions about how best to optimize those workflows by identifying bottlenecks, noted Chivukula.

    The Opsera platform surfaces that intelligence by scanning all repositories and branches, including commit history, and generating alerts and notifications whenever KPI thresholds or compliance requirements are exceeded. DevOps teams can also use the platform to assess their overall DevOps maturity using a set of DevOps Research and Assessment (DORA) metrics defined by Google. Going forward, Opsera also plans to start surfacing metrics based on the Supply chain Levels for Software Artifacts (SLSA) framework for securing software supply chains also defined by Google.

    Platforms such as Opsera make it possible to apply analytics to DevOps workflows as they become more complex. The number of dependencies that exist between various application modules, for example, makes it exceedingly difficult for DevOps teams to manually identify the impact a delay in one project might have on any number of other downstream projects.

    In addition, many organizations are keen to discover what best practices should be adopted by other application development teams.

    Finally, many developers tend to use a repository as a dumping ground for all kinds of software artifacts, noted Chivukula. DevOps teams need an intelligence tool that makes it possible to identify which of those artifacts are the most essential to the business, he added. Otherwise, manually combing through a repository looking for artifacts becomes the DevOps equivalent of looking for a needle in a haystack, noted Chivukula.

    GitOps is essentially a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. GitHub views GitOps as a means of extending a code repository into the realm of DevOps workflows using the GitHub Actions platform. It’s not clear how much traction GitHub Actions is gaining at the expense of other CI/CD platforms, but for organizations that are relatively new to DevOps and already using GitHub as a code repository, it presents a path of least resistance.

    Regardless of why organizations adopt a DevOps intelligence platform, the need to optimize workflow across toolchains is becoming more pressing during an economic downturn. It’s becoming more clear that the cost of an application delivery delay directly impacts the level of revenue an organization generates in the age of digital business transformation.

  • Nobl9 Simplifies SLO Identification

    Nobl9 Simplifies SLO Identification

    Nobl9 today added a Replay capability to its service level objectives (SLO) management platform that makes it simpler to collect the historical data a DevOps team needs to get started.

    Nobl9 COO Kit Merker said Nobl9 Replay makes service level indicator (SLI) data instantly available in minutes using 30 days of historical data collected from observability and application performance monitoring (APM) platforms. Previously, DevOps teams would have had to wait as long as a month before the Nobl9 platform could collect enough spreadsheet data to create a graph that identified the relationship between various services.

    Nobl9 now enables historical data to be merged with data collected in real-time to allow DevOps teams to view SLO charts and generate reports shortly after creating an SLO within a Git-based workflow.

    Nobl9 is trying to spur greater adoption of SLOs by making available an open source SLO specification that defines a common interface for constructing them that has garnered support from Dynatrace, Sumo Logic and others. SLOs, of course, are not a new idea; they have been used as a metric to track the performance of IT services for decades. However, as more microservices-based applications are built and deployed, it’s becoming more challenging to maintain SLOs across applications that have many more dependencies than legacy monolithic applications.

    The Nobl9 platform is designed to enable DevOps teams to employ an SLO-as-code approach that makes it simpler to gather the metrics that confirm whether SLOs are being achieved.

    It’s not clear whether reliance on SLOs has waned over the years or if application environments simply became too complex to track meaningful metrics. A recent survey conducted by Dimensional Research on behalf of Nobl9, however, found a full 94% of respondents that have or plan to implement SLOs intend to map them directly to business operations, with 91% reporting they expect that effort to improve decision-making. More than 80% also said their organizations are planning to increase the use of SLOs, with 87% indicating SLOs should improve overall microservices performance.

    The issue is that most organizations have limited visibility into their IT environments. The survey found less than half of respondents (46%) had visibility into all their IT environments. Only 45% and 35% claim to have visibility into containers and microservices, respectively. More than three-quarters (78%) said hybrid clouds make observability more difficult, even though 45% said they already employed 11 or more observability and monitoring tools. Trying to track SLOs using tools such as Grafana dashboards that DevOps teams need to set up and maintain is simply too difficult, noted Merker.

    As applications are increasingly constructed using services that drive digital business transformation initiatives, it’s now only a matter of time before SLOs are more widely tracked. That will enable DevOps teams to not only ascertain their current level of performance but also more easily work toward achieving their actual performance goals, he added.

    The challenge is that defining an SLO in a highly dynamic application environment where services are added and replaced with much greater frequency is often a lot easier than maintaining it.

  • PlanSecOps: Incorporating Security Strategies in Design

    PlanSecOps: Incorporating Security Strategies in Design

    Organizations that don’t adapt and change aren’t likely to survive. The same can be said about DevSecOps, a discipline created to ensure security is baked into the software development process, not an add-on after the code is approved. And as much as DevSecOps has changed the software development world for the better, it is time to evolve DevSecOps so that security is considered even earlier in the application development process—before a single line of code is even written.

    We are already seeing glimpses of this early marriage of security and software development. Security is starting to be implemented from the initial design through integration, testing, deployment and software delivery. I’ve taken to calling the process PlanSecOps.

    What is PlanSecOps?

    With DevSecOps, developers integrate security measures into the code, then test to ensure it works. PlanSecOps starts the process earlier in the development cycle, incorporating security at the planning stage before any code is written. It’s easier to incorporate security fixes during the development cycle (i.e., before the coding phase) by including security pros who know from experience what kind of vulnerabilities exist in different types of software during the planning and architecture cycles.

    Consider the process of building a house. Adding a hard-wired security system after the house is built usually requires some retrofitting with the aid of an electrician and contractor to install the system in a manner that doesn’t interfere with other parts of the electrical infrastructure. However, if a security system is part of the house’s blueprint, it’s ready to go when the build is complete with no risk of incompatibilities. PlanSecOps does the same thing for the development process.

    PlanSecOps is a More Holistic Approach to Security

    Companies want to grow, innovate and move quickly to deliver new functionality to improve the customer experience. It’s how they remain competitive. Shortening development cycles with Agile methods and DevOps teams helps them move faster.

    Yet, attack strategies are only getting more sophisticated, and hackers are ready to jump on any vulnerability in an app. Like the game whack-a-mole, DevSecOps looks at individual pieces of code and applies patches. As soon as one vulnerability is patched, a never-ending set of new exposure points pop up. Fixing one problem may undo the patch for another, making each new issue more complex to address.

    PlanSecOps is a more holistic approach to security by design. It’s putting a system in place versus just fixing issues as they emerge—patching different subroutines and making sure they all work together. PlanSecOps simplifies coding and testing to ensure functionality. It also simplifies the process downstream for the engineer, providing a faster, easier and more sustainable development process. It can cut weeks out of the development cycle.

    Recommendations for Implementing PlanSecOps

    Security patching is increasingly impractical in the development phase because of its complexity and the impact of privacy regulations like GDPR. Having one overarching strategy for data privacy is a better approach than trying to retrofit it into software after the coding phase. While this oversight is possible to handle in-house, it requires either one privacy engineer with a legal background and experience in software development or a team that covers all of this expertise. Both options are costly. Additionally, tech talent is challenging to recruit right now.

    While at the RSA conference earlier this year, I saw several new companies that are creating security platforms designed to make security-by-design easier. These tools grade your code and provide a framework for the development process. Gathering this data could be a good start to identifying any issues, but you still need an expert who is smart enough to enact fixes based on the information the tool provides. Additionally, it’s difficult to vet which tools are right for your dev process. For example, a tool designed for the health care industry wouldn’t be applicable to a manufacturing application.

    Alternatively, you could partner with organizations that have a security-by-design approach and are already handling security planning during the architecture phase. Partnering with software development companies like this is typically less expensive than hiring someone in-house. Plus, you’ll get the experience you need to bake security into your applications from the beginning.

    Security Needs to Start Early and Never End

    October was cybersecurity awareness month and reminds us that cybersecurity is everyone’s responsibility. To stay competitive, companies need to embrace that responsibility and address the ever-evolving security risks at the beginning of DevOps cycles. The software development journey has no end because new features will always be needed and new technologies will emerge. The key to success is to ensure that everyone in the software development process shares accountability for security and that all systems are as automated as possible. With improved collaboration and understanding of risks, organizations can better respond to both cybersecurity risks and software development innovations as they look to the future.