devopsy.kinsta.cloud

Tag: as-code

  • Automation Relation

    Automation Relation

    One thing that is absolutely true: This latest iteration of IT improvement is about automation. Whether making DevOps more automated, working on any of the various “X-as-code” movements or implementing AI, the idea is to create what one vendor portrayed as a “human-free zone.” A space where automation does everything that needs doing.

    And the one question we all need to be asking now is simple: Where do we want that human-free zone in our organization?

    The answer is inevitably, “In more places than you think,” for a wide variety of reasons. Let’s cover what you should be thinking about when answering this question – because this change is already upon us and we’re doing a lot more without so much as an approval.

    1. Anywhere that compliance is on the line and the action doesn’t risk crashing systems.
    2. Anywhere the process being performed is so rote that any member of the team can do it and everyone thinks of that process as a distraction.
    3. Anywhere that time is critical. Think of incident response to a DDoS or zero-day attack.

    This is a very basic starting point. From here, we want to move into “anywhere we have a static list of steps to perform.” So, the above points would include things like, “If a new employee is in the marketing department, they belong in the Marketing security group. If they are further working on marketing for new products, they belong in the Marketing for product development group.” But eventually, you want to get to, “This app communicates on port 12345, so that port must be accessible, run the script to open that port.” The decision about “Should this port be open?” can then be shifted left to have more involved discussions about options and necessity. Our current world already does some of that; automation will make it standard.

    And that’s what we’re getting. We’re in a world where some standardization is enabling automation, and automation is demanding that we figure out more standardization. And it is all good. There is a lot we do in IT that a trained monkey could do, and we need to let a trained system do it. The more time we have, the more problems we can solve … So let’s keep freeing up that time.

    And keep rocking it. Your time is valuable precisely because you keep the organization running. Freeing up that valuable time just makes you a greater asset to the organization and makes your job less boring as a bonus.

  • Checkly Adds Monitoring-as-Code to Testing Platform

    Checkly Adds Monitoring-as-Code to Testing Platform

    Checkly this week added a monitoring-as-code (MaC) workflow capability to its software-as-a-service (SaaS) platform that is used to create synthetic tests for applications.

    The Checkly platform spins up browsers to test and can now monitor how applications are performing at both the user interface and application programming interface (API) level. That capability, currently available in beta, is enabled via a command line interface (CLI) for accessing an instance of TypeScript to invoke MaC workflows.

    Checkly CEO Hannes Lenke said that integrated approach enables application development teams to observe applications in as little as 60 seconds without instrumenting them with agent software.

    As part of that effort, Checkly also made generally available Playwright Test, a testing platform for web applications that spins up modern browsers on demand in addition to updating its public dashboards and adding an analytics API.

    Finally, the Checkly SaaS platform has passed a SOC 2 Type II security audit.

    Lenke said the overall goal is to make it simpler for developers to discover and remediate issues as they assume more responsibility for the ongoing management of applications.

    It’s not clear whether developers are taking over responsibility for testing and monitoring applications, but as more responsibility for applications shifts left, organizations are looking to give developers the tools they will require to succeed. That doesn’t mean IT operations teams won’t need to continue to monitor IT environments, but developers do need integrated tools that give them enough meaningful context to address them as they write code. Synthetic testing tools also enable developers to address many routine issues long before they might be discovered by a dedicated testing team that should be focused on ensuring the overall quality of the user experience.

    Regardless of the approach to testing and monitoring, Lenke noted that the silos that make up the software development life cycle are becoming more tightly integrated in modern application development environments. The primary objective is to make it possible for organizations to accelerate application development without compromising quality, he added.

    Of course, the more testing that occurs early in the application development process, the fewer issues a DevOps team should encounter after an application has been deployed in a production environment. The issue is that, historically, much of that testing occurs late in the application development process. Each time a project falls behind schedule, there is naturally a greater temptation to reduce the amount of time spent on testing to ensure the on-time delivery of an application. Providing developers with tools for testing and monitoring applications as they are being built should ensure that the proper level of testing is occurring before an application is deployed.

    There will, however, never be a perfect application. Over time, DevOps teams will discover that every application is impacted by drift to varying degrees as updates are made and the underlying infrastructure is upgraded. The most critical issue is reducing the number of potential issues overworked DevOps teams may need to address later on by ensuring the code being deployed is of the highest quality possible.

  • The Everything-As-Code Revolution and the OWASP Top 10

    The Everything-As-Code Revolution and the OWASP Top 10

    After years of stagnation, the Open Web Application Security Project (OWASP) Top 10 list finally saw some shakeup.

    Most notably, insecure design debuted on the list as the number four security risk to web applications.

    “If we genuinely want to ‘move left’ as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures,” OWASP says.

    That hits the nail on the head. It’s a great sign for the industry that organizations are adapting and continuing to shift left responsibly, and points toward the everything-as-code future we’ve been imagining.

    This addition by OWASP finally recognizes a key reason why organizations struggle to move the needle on addressing security issues. A lot of security today is reactive and organizations find issues long after they deploy applications, leaving security teams to act as firefighters at a time when there are too few security professionals in just about every industry.

    To effectively move forward, we need a shift in thinking.

    Studies have shown that if organizations addressed these same issues in design, they would eliminate the costs of firefighting and significantly improve developer productivity. It would also free security teams to focus on the strategic needs of security. 

    This change from OWASP recognizes that security needs to have a seat at the table when key software design decisions are made and it requires empowering security teams in the same way the DevOps teams have been empowered to own and manage the application’s security design and implementation. 

    A Unique Inflection Point: DevSecOps

    Security breaches continue to pile up, yet many organizations haven’t reexamined their reactive approach, which ignores the architectural problems causing the issues. We can’t continue to operate this way.

    We need a more dynamic and comprehensive approach to security in cloud-native applications. We need to acknowledge the failure of detecting misconfigurations too late in the development life cycle. It’s impossible to scale that way, and you end up creating too many rules in the process.

    We need more proactive engagement, which can be difficult in an application development world where velocity is king.

    Developers and DevOps teams should view security as trusted partners and engage them early in the development life cycle. They should understand that they have a shared responsibility for security. Security teams should embrace automation that fits into the developers’ workflow and makes their lives easier by democratizing security.

    The Everything-as-Code Future

    If we can continue to shift left responsibly, we’ll keep moving the industry forward in a way that will have ripple effects, including in the OWASP top 10.

    In a perfect world, we would see frameworks and application infrastructure address the input validation issues that make up a large part of the top 10 today. Those issues should be off the list and the top 10 should focus on the systemic issues—like insecure design—that lead to the current list.

    As we move toward an everything-as-code world where the boundaries between the application and the infrastructure blur, OWASP may focus more broadly on everything-as-code, which would include a new class of issues such as cloud code, infrastructure-as-code, pipeline-as-code and security-as-code. While there’s certainly more work to do, that would be a strong signal that we’re moving in the right direction. 

  • Jit Emerges to Address Cybersecurity Policy-as-Code Orchestration

    Jit Emerges to Address Cybersecurity Policy-as-Code Orchestration

    Jit today emerged from stealth with a free namesake orchestration platform beta that automatically implements security plans as code.

    Aviram Shmueli, chief product officer for Jit, said the company will both make security plans it developed available as code within GitHub. In addition, Jit will make available a service through which customers can submit documents and spreadsheets that Jit will convert into a custom security plan that can be executed as code.

    Fresh from raising $38.5 million in seed funding, Jit is aiming to advance the adoption of DevSecOps best practices by enabling cybersecurity policies to be more easily implemented as code via its orchestration platform, said Shmueli. The Jit platform enables developers and DevOps teams to take advantage of a graphical tool to automatically implement security policies within a DevOps workflow with a single click, he noted.

    The goal is to eliminate the need for separate DevOps teams to create security policies that each would need to individually manage, added Shmueli.

    In theory, DevSecOps best practices require shifting left the responsibility for security toward application development teams. The challenge is that development teams generally don’t have the expertise required to craft effective cybersecurity policies. Jit is making a case for a platform that makes it simpler to automatically implement vetted cybersecurity policies.

    Exactly how far responsibility for application security will shift left remains to be seen. Developers generally prefer to spend as much time as possible creating business logic rather than implementing cybersecurity policies. As such, it’s frequently left to a DevOps team to find a way to consistently implement cybersecurity policies across multiple applications. Each DevOps team will need to decide how much they can rely on the policies defined by Jit versus opting to implement a set of policies defined by their internal cybersecurity teams. The issue that often arises is cybersecurity teams lack programming skills; the only means available to define cybersecurity policies is some type of document or spreadsheet that, one way or another, needs to be converted into code.

    Given the ongoing chronic shortage of cybersecurity expertise, it’s apparent that more efficient methods for sharing cybersecurity best practices are required at a time when application environments continue to both rapidly expand and increase in overall complexity.

    Regardless of the DevSecOps approach, the pressure to address application security is mounting in the wake of a series of high-profile cybersecurity breaches. Organizations of all sizes are now reviewing software supply chains that are increasingly being targeted by cybercriminals. Security policy-as-code tools make it possible to ensure that applications don’t, for example, communicate with an external system without express permission.

    One way or another, the level of application security currently being attained will improve in the months ahead as more mandates are enforced. The only real issue remaining is the amount of disruption to existing processes that will be required to achieve that goal.

  • Nobl9 Adds Hydrogen Platform to Surface Technical Debt Issues

    Nobl9 Adds Hydrogen Platform to Surface Technical Debt Issues

    Nobl9 today unveiled a Hydrogen platform that makes it simpler for DevOps teams to identify technical debt issues as they manage service level objectives (SLOs) as code.

    Hydrogen enables DevOps teams to define SLOs using a simple wizard or by embedding code within their application as part of a DevOps workflow. That code is then used to automatically collect data from platforms such as Datadog, New Relic, Prometheus, Splunk and others with requiring any additional instrumentation.

    Nobl9 COO Kit Merker said that approach also makes it possible to surface technical debt that inhibits achieving those goals via the Hydrogen platform. Armed with those insights, it then becomes easier for DevOps teams to focus on reducing or eliminating that technical debt because Hydrogen automatically generates a ticket in the Jira project management application—widely used by DevOps teams—to make sure the issue is addressed. Otherwise, in the heat of a DevOps sprint, the issue is likely to be forgotten as the application development project continues to move forward, noted Merker.

    The ability to identify that technical debt is an outgrowth of the ability to manage SLOs as code that is enabled by the core Nobl9 software-as-a-service (SaaS) platform. Hydrogen extends that capability by automating workflows whenever a specific service shows indications that it cannot meet objectives because of a dependency on a legacy platform that needs to be upgraded, added Merker.

    There is also a service health dashboard that organizes SLOs into logical groups that are mapped to features via labels, which Merker noted makes it possible for multiple stakeholders to easily identify which issues affect a particular service most. Hydrogen can also trigger a variety of automated workflows to prompt additional investigations that escalate as services worsen.

    Overall, Hydrogen is designed to provide engineering teams with more accurate context that can be used to prioritize which issues should be addressed first during any technical debt planning cycle, said Merker. Hydrogen can enforce code release policies based on technical debt budgets that are enforced via integrations with continuous integration/continuous delivery (CI/CD) platforms.

    Technical debt generally refers to any code change that is required to optimize a service that is not immediately addressed. The more legacy platforms there are in an IT environment, the higher that technical debt tends to become. At a time when more organizations are building and deploying microservices-based applications, that technical debt, over time, tends to adversely affect applications that are much more dependent on external services than a traditional monolithic application. A single technical debt issue can have a cascading impact on multiple microservices-based applications that would, otherwise, would be difficult to detect.

    The challenge, of course, is that technical debt doesn’t always get the attention it deserves when most of the IT team is focused on rolling out the next great application. However, as application environments become more complex it may only be a matter of time before all the technical debt that is being accumulated becomes unsustainable.

  • Extending Automation to Your First Code Commit

    Extending Automation to Your First Code Commit

    I am a big advocate for software reuse, and an even bigger advocate if that reuse comes in the form of software automation. My team and I rely on reusable software processes that accept simple inputs to produce predictable results. We have tight deadlines with requirements that often seem impossible. Automation makes us more efficient and our work more predictable.

    Once upon a time, we used glue and bubble gum to cobble together means by which to build, then test and then eventually deploy application versions. It worked until it didn’t, and industry opportunities arose for mechanization. Enter continuous integration (CI), continuous deployment (CD) and DevOps, in part.

    You likely know this and have already taken advantage of CI/CD platforms such as Jenkins, CircleCI and others. The simplicity of the as-code model allows us to turn easy-to-create declarations into the otherwise complex provisioning of servers, databases, caches and file systems, along with the execution of code to leverage what was provisioned.

    Life as a developer has been made better using these as-code tools in the tool chain. Spinning up a Kubernetes cluster on Google to (re-)deploy an image built, tested and pushed to DockerHub from a CloudBees/CodeShip pipeline is something I rely upon each time I commit to my Git host.

    In this article, I am going to talk about Project-as-Code to extend automation to the first code commit with a working app running through a functional CI/CD pipeline and deployed to a production-like environment.

    Barriers Keeping Enterprise IT Departments from Coming Along for the DevOps Ride

    Unfortunately, basic usage of all these great tools comes with the added complexity and cognitive load cost. Understanding Docker image creation, HashiCorp Terraform syntax for infrastructure-as-code, Kubernetes cluster deployment and more are just a few of the competencies developers and operators need to have.

    Learning a new set of tools every few years comes with the territory, but there’s no reason to ignore new potential avenues for automation. I’ve wondered if there is a better way to abstract and automate the setup of these common pieces in the modern software production pipeline.

    Another common issue I’ve noticed—these pipeline components often get set up sequentially, with the first meaningful code commit being the blocker to setting up all the other pieces of the CI/CD pipeline. Without this commit, these tools sit relatively idle while waiting to provide value.

    For those of us who work on new projects regularly, getting things started has always had its issues, especially for consulting scenarios where requirements and team dynamics differ between clients. We are disciplined enough to first reach in our toolbox to reuse as much as possible. Still, DevOps has yet to be adopted wholesale in a standard way by many enterprises.

    For these situations, I find the benefits of DevOps are easy to explain and understand. Developers like to reuse and fewer barriers, the business likes savings and an enterprise likes productivity and innovation. However, to inject those benefits is still a very manual, time consuming process, making the overall sell of DevOps harder.

    The purpose of DevOps automation is to simplify tedious error prone manual processes. I see another opportunity for automation: entire DevOps projects using the same as-code model we have become accustomed to.

    Generating Your First Meaningful Commit “As-Code”

    Why not use a straightforward declarative model-driven means of not only generating tech-stack specific application source code, but all the config files that lead to DevOps being automated. With this, the toolchain learning curve is minimized, and idle tools now are immediately called to action. The result is a self-sufficient operational DevOps environment working through an application code base that comprises a fully deployable executable first code commit. Developers then get their reusable assets and environment(s), the business sees cost and time savings, and the enterprise gets the productivity and innovation necessary to stay competitive.

    In an article written by Pete Hodge titled “Hello production,” he goes into great detail about the value of quickly standing up a flowing CI/CD pipeline leading to a functioning app deployed to production. He contends deploying even a useless application into production, as soon as you can, is the right way to start a new project because it pulls unknown risk forward, opens up parallel streams of work and establishes good habits. Project-as-Code standardizes this thinking with model-driven automation.

    The next generation of DevOps is unfolding with automation remaining a key component to expand scale, velocity and productivity. As automation has worked its way up the toolchain, automating the automation behind DevOps will shift the paradigm to improve how projects are created, how DevOps is implemented and the quality and features of the first commit into a Git repository. What now takes weeks to months could instead take hours to days, falling in line with our expectations now met by other successfully mechanized aspects of DevOps.

    Hopefully this article will serve as a starting point for your next DevOps project and how Project-as-Code automation can be a part of getting you started easier and faster.

    — Steven Randolph