devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Report: Most IT Teams Can’t Fix Open Source Software Security

    Report: Most IT Teams Can’t Fix Open Source Software Security

    Lineaje, a provider of a platform for securing software supply chains, today published an analysis of 41,989 open source components embedded in the top 44 popular projects managed by the Apache Software Foundation (ASF). That analysis found more than a quarter (26%) of vulnerabilities are not patchable by the application development team that deployed them.

    In addition, the report found that 64% of the vulnerabilities analyzed have no patch as of yet. Overall, 68% of the vulnerabilities analyzed are due to dependencies created when an open source software project included a component or package developed by another open source project maintainer.

    Lineaje CEO Javed Hasan said that means that 90% of open source dependencies are transitive, in the sense that they are created when maintainers of a project included a vulnerable open source component created by another entity. Only 10% of the vulnerabilities discovered by Lineaje are the result of a dependency that an application development team could actually address on their own, he added.

    Overall, the report found a full 82% of components that are relied on to build open source software are inherently risky due to vulnerabilities, security issues, code quality or maintainability concerns. In addition, 5% of components failed a basic integrity check, with 3% having no known origin.

    Open source software is not created equal no matter what consortium is overseeing its development, noted Hasan. Unfortunately, there is no universally accepted method for validating the integrity of open source software, so application development teams should proceed with caution whenever employing open source software, he said.

    The challenge, of course, is that developers have been reusing open source software within applications for years now. It’s only in the recent wake of breaches involving open source software that organizations have been taking a harder look at how applications are developed.

    The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is now at the forefront of an effort to better secure open source software by focusing on 10 streams of investment that, in total, will require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure open source software is secure when deployed in a production environment belongs to the organization that deploys it.

    Hopefully, following a recent executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead—assuming, of course, the organizations that rely heavily on open source software make more substantive contributions to securing it. In the meantime, organizations can count on the fact that cybercriminals have taken note of the vulnerabilities in applications that can be traced back to flaws in a wide range of open source software.

  • GitKraken App Correlates Activity Across Jira Cloud and Git Repositories

    GitKraken App Correlates Activity Across Jira Cloud and Git Repositories

    GitKraken today made available a preview of a free application that aggregates activity across Atlassian’s Jira Cloud and any Git repository to provide a unified view across all the activities of a software development team.

    Adam Wride, general manager for planning solutions of GitKraken, said Team Insights for Jira (TIJ) will make it easier for DevOps teams, project managers and application stakeholders to collaborate.

    TIJ accomplishes that goal by providing an overlay using a familiar Gannt chart view of epics and issues found in project management applications to correlate, for example, user activity such as status changes and comments made in Jira Cloud with updates to commits and pull requests made in a Git repository, he noted.

    Team members can then filter those views by project, sprint, contributors, issue type and other criteria to drill down on the exact list of issues that need to be addressed, added Wride.

    Most application development efforts rarely follow the original DevOps workflow plan, so TIJ provides a means for organizations to track real-time activity data to visualize how their efforts are progressing against the plan. That makes it possible to make data-driven decisions about how to reallocate resources as needed, said Wride.

    At the core of TIJ is a Git Integration tool that GitKraken previously made available. TIJ is the second offering from the company based on that tool following the launch of an application that integrates Jira with continuous integration/continuous delivery (CI/CD) platforms. GitKraken claimed there are already more than 10,000 organizations employing its Git integration tool.

    As more organizations become dependent on software to drive a wide range of processes, the need for increased visibility into DevOps workflows has become more crucial. Revenue is now directly tied to the pace at which software is being deployed and updated. Any change to the pace at which an application is being developed needs to be communicated across all the stakeholders that might be impacted. The challenge is that given all the dependencies that exist within modern applications, it’s not always easy to discern how a delay in the development of one module or component might impact multiple application development projects.

    Of course, project managers have been using project management applications to bring some order to the chaos of software development for decades. The challenge has always been that manual updates to projects have not always been provided in a timely manner. Developers don’t always remember to update project managers, who must manually enter updates in a project management application. GitKraken is making a case for an approach that automatically updates Jira Cloud by collecting data from DevOps tools and platforms rather than waiting for software engineers to remember to share that information with a project manager.

    Arguably, there’s now no excuse for everyone in an organization—if they care to, they can find out the status of any application development initiative. The challenge is making sure the data that DevOps teams—and their tools and platforms—already generate seamlessly updates the project management software that everyone else relies on to keep track of those projects.

  • CircleCI Report Surfaces DevOps Productivity Gains

    An analysis of more than 14 million workflows from thousands of organizations conducted by CircleCI, a provider of a continuous integration/continuous delivery (CI/CD) platform, revealed the mean-time-to-recovery (MTTR) decreased by about 13% year-over-year.

    Half of CI workflows (50%) recovered from a failed run in 64 minutes or less. That compares to 73 minutes or more in previous years, the report noted.

    In general, the report found 50% of workflows completed in 3.3 minutes or less. However, the average duration was approximately 11 minutes. The median workflow ran 1.54 times per day.

    Success rates, as defined by the number of passing runs divided by the total number of runs, was, on average, 77% for default branches and 67%, on average, for non-default branches.

    Naturally, the level of productivity any given DevOps team can achieve is impacted by everything from the size of the team to the vertical industry they operate in. CircleCI CTO Rob Zuber also noted there are other crucial developer productivity metrics, such as the amount of time developers are focused on writing code, that need to be tracked as well.

    The goal for any DevOps team is to abstract away as much complexity as possible to enable developers to spend more time on writing business logic, said Zuber. Unfortunately, as more responsibility for infrastructure and security has shifted left toward developers, many of them are spending too much time managing application environments instead of writing code, noted Zuber. He noted that the cognitive load being placed on developers today is too high.

    Developing applications is, of course, as much an art as it is a science. Organizations can set aside time for sprints to write code, but it’s difficult to dictate when inspiration might strike a particular developer. There is always going to be a need to let developers, for example, write code at odd hours of the day and night. The more friction they encounter in terms of spinning up application environments, the less likely it becomes a developer will spend time squarely focused on writing code, said Zuber. The “zone” is when most of the best code is developed, he added.

    Naturally, there is no set of metrics that are equally applicable to all DevOps teams, but they should pay attention to metrics as an indicator of whether teams are improving, added Zuber. Most developers and software engineers are not going to want to work in a “software factory” where every minute of the day needs to be accounted for within a project management application. Rather than employing metrics as a stick, they should instead be used as an educational tool—a carrot—that drives steady improvement. In addition, organizations should take care to make sure the collecting of metrics doesn’t impede the pace at which applications are being developed.

    As the saying goes, things measured are usually things done; but there is a fine line to be observed when it comes to any goal that requires a certain level of creativity to achieve.

  • Synopsys Preps Extensions to Polaris SaaS Platform

    Synopsys Preps Extensions to Polaris SaaS Platform

    Synopsys plans to extend the capabilities of its Polaris Software Integrity Platform for securing application development environments by adding dynamic application security testing (DAST) tools along with the ability to scan code used to provision infrastructure.

    As a software-as-a-service (SaaS) platform, the Polaris Software Integrity Platform was created by combining the static application security testing (SAST) tool Synopsys gained with the acquisition of Coverity in 2014 and the software composition analysis (SCA) tool it added to its portfolio by acquiring Black Duck Software in 2017.

    In 2015, Synopsys acquired the Seeker tool for analyzing the code created using interactive application security testing (IAST) tools from Quotium. The company last year acquired WhiteHat Security from NTT to add a DAST tool.

    Patrick Carey, senior director for marketing strategy for Synopsys, said that the company would add the capabilities of those latter two platforms to create a comprehensive set of best-in-class security tools that are easily accessible via a SaaS platform.

    At a time when more organizations than ever are moving to secure software supply chains, Carey said it’s critical to provide developers with more visibility into vulnerabilities across the entire software development life cycle (SDLC). Some organizations are opting to achieve that goal by embedding tools within the SDLC themselves, but many organizations would likely prefer to invoke a SaaS platform that they don’t have to maintain, noted Carey.

    He noted that a SaaS platform makes it simpler to point a collection of integrated tools at a code repository to surface those vulnerabilities.

    As DevSecOps workflows continue to evolve and mature, more responsibility for application security is shifted left toward developers. The challenge is that many developers have limited cybersecurity expertise, so it’s critical that they have access to high-quality security tools.

    In addition, a SaaS platform helps reduce the total cost of achieving that goal by providing multiple capabilities within a single integrated platform, said Carey.

    Naturally, most of the focus today is on reducing the number of vulnerabilities that find their way into production environments as applications are being built. However, there are already large numbers of unaddressed vulnerabilities in applications that have already been deployed. Organizations will need to find ways to address that technical debt in addition to providing developers with tools that help prevent those code vulnerabilities in the first place.

    As such, there is no one central place through which application security can be managed, noted Carey. Instead, application security needs to be addressed across every phase of the SDLC, he added.

    It’s not clear how quickly organizations are adopting DevSecOps best practices, but as calls for increased liability for software development increase—as outlined, for example, in the U.S. National Cybersecurity Strategy— organizations should expect DevSecOps workflows to become a requirement. Otherwise, organizations will be severely penalized for vulnerabilities that find their way into code. In effect, there is now a race to embrace DevSecOps before any proposed liability legislation becomes the law of the land.

  • Are you Being ‘Nice’ to Your Developers? Think Again

    Are you Being ‘Nice’ to Your Developers? Think Again

    As a developer, you’ve learned your craft. From your fingers comes the magic that builds the applications that run the world. You can literally create something from nothing! And not just software programs. You can create value that means revenue for your company. You’re a revenue machine — no, you’re a god, creating anything that’s needed! That is, you could be if you could spend all of your time writing that magical code. But this dream is not so simple. If you’re like most developers, you’re spending way too much time on other things, such as:
    ● Meetings
    ● Dealing with interruptions
    ● Security hassles
    ● Operations
    ● Debugging
    ● Fighting with infrastructure
    ● Burnout

    Every minute you’re dealing with any of those, you’re not making magic. Because you’re human, that is going to make you unhappy.

    If you really are a developer and not just imagining you are, you already know all of this. Now let’s turn our attention to those of you who are responsible for developers. Because it’s your job to make them happy.

    Yes, it is, if you want them to keep working productively for you and add value. Luckily, it’s within your reach to do so. It will benefit you, add value to the organization and, most importantly of all, the employees themselves.

    Simply put: If you want to get value from your developers, you have to be nice to them. If you expect them to pour themselves into you and into the company, you must first prioritize them and invest in them. Success can only be realized and achieved by a happy balance of developers who are motivated to create.

    Do you know who feels more motivated than anyone else? Who will always go above and beyond?

    Those who are appreciated.

    So let’s get started.

    Increased Productivity and Value

    The most obvious issue is productivity. The reality is that software development can be an arduous mental task, and when developers are unhappy, it will inevitably affect their productivity—especially when they spend mental cycles on things that are not directly related to the task at hand.

    Even if they’re not spending work time searching for another job (or quiet quitting), they’re probably thinking about what could be different and mentally grumbling about it every time something comes up that irritates them.

    By treating developers well and eliminating those annoyances as much as possible, you prevent that problem and get 100% of their attention.

    And there are other productivity benefits, as well. When developers trust their company and their co-workers, it fosters greater collaboration between those developers and business stakeholders. It also engenders greater creativity, which can lead to innovation and value above and beyond what you are expecting them to deliver.

    Retention

    The most obvious issue when it comes to developer happiness is, of course, retention. After all, if you’re not nice to your developers, you should expect them to leave for other jobs. If the Great Resignation taught us anything, it’s that it is human nature to move along if dissatisfied.

    That may not seem like a big deal to you, but think about the implications if your developers are leaving in droves. Never mind the turnover costs, what about the inevitable delays as you bring new developers up to speed? Hiring and training are arduous, time-consuming endeavors. And if turnover is bad enough, you may never be able to actually complete anything because nobody ever gets a chance to build up a good head of steam.

    Compare this to a company with a dedicated team of happy developers who are motivated to grow and innovate for themselves, their team and your organization.

    Which organization do you think is going to come out on top? Yes—the organization with the happier team of developers is probably going to have a competitive advantage—and a big one!

    When developers are happy, they are likely to be loyal to your company. That loyalty means they stay long enough to become experts in what you do, making them more likely to create the kinds of innovations that move the company forward for added value.

    But most of all, can you really afford to have your best employees leave and take all of the knowledge they’ve gained with them, potentially to a competitor? Probably not.

    Maintaining a Good Reputation

    All of this adds up to reputation; get a bad reputation in the developer world and it is going to be hard for you to attract top talent. In a world where technology changes so fast, it’s already difficult to find developers who have stayed with one technology long enough to become experts. You need to take advantage of every tool you can to make it easier. Your reputation can be one of them—if you treat your developers right.

    But there’s another reason to protect your reputation among developers: It could easily bleed over to your reputation among your customers. If you’re a big company, word of your treatment of developers may spread. If you’re not so big, and you have enough developer turnover, some of your former employees may work for prospective customers or know someone who does.

    Today, customers are trying to be socially responsible by buying from companies that ‘do the right thing.’

    Without much effort, you can be one of those companies by trying to foster developer happiness. Ultimately, it’s not that difficult.

    How to be Nice to Your Developers

    Fostering developer happiness doesn’t have to be a hugely expensive proposition. It’s not always about huge paychecks (though they do help smooth out some rough edges). Some things you can do to be nice to your developers include the following.

    1. Provide what they need: Developers should be able to spend as much of their time as possible actually coding; make sure they have the tools that they need so that they’re not having to improvise or struggle with creating infrastructure. For example, engaging a ZeroOps partner can take some of this off their plates.

    2. Eliminate distractions: Even in ideal situations, it can take as long as 20 minutes for a developer to get back into their train of thought every time they’re interrupted. Try to provide an environment with as few distractions as possible.

    3. Foster a training-centric culture: Developers need to feel as though you have their best interests at heart, and one way to do that is to help them learn new skills. And there are multiple benefits for you: For one, it’s much easier to train your existing people in an in-demand technology (such as Kubernetes) than it is to hire someone who already has those skills. For another, training your entire team in these new technologies can unlock creative ways of solving problems.

    4. Help developers understand how their work relates to the customer: While it can be tempting to expect developers to simply do what you ask them to, when they understand why they’re doing it, they’re much more likely to feel invested in the work.

    5. Listen to ideas: Your developers are at the heart of what you’re trying to do. It’s very possible that they have a new way of doing something or an idea for something that could help your company. Even if you don’t end up going forward with the idea, your developers need to know that you respect them enough to listen.

    6. Respect work-life balance: Developers have a reputation for working long hours and many even take pride in it. But it’s not always the most efficient way to get things done. A tired developer works more slowly and makes more mistakes. Be flexible and make sure that you’re not overloading your people with more than they can reasonably accomplish. If your developers have to work 70, 80 or 100 hours a week to meet deadlines, you either need to hire more people (if you can find them) or find a way to partner with other organizations to take things off their plate. (See number one).

    All of these things make for a positive work environment that enables your developers to work their magic for you, day in and day out, making something from nothing and moving you forward the way nobody else can.

  • Orgs Shift Toward Centralizing Automation Initiatives

    Orgs Shift Toward Centralizing Automation Initiatives

    A survey published today found that 75% of respondents recognized that automation silos hamper their ability to unify cloud operations across functions.

    Conducted by CloudBolt Software, the survey polled 350 senior IT and DevOps leaders at organizations with more than 3,000 employees. On a positive note, the survey found 57% of respondents were starting to pursue a more centralized approach to automation, with a total of 88% acknowledging that having all previous and new automation centralized for the entire organization would ensure compliance, bolster security, enable business continuity, encourage reuse and reduce risk.

    Rather than taking a more holistic approach, well over half of respondents (57%) reported automation efforts are limited to specific silos. On average, organizations are employing 27 different automation tools their organizations have deployed, using one or a few as they see fit, with little to no consistency across teams. More than half (55%) of respondents said they have four or more separate automation teams, with 95% noting that each of those teams operates in their own silo.

    CloudBolt CTO Rick Kilcoyne said that lack of continuity clearly creates inefficiencies and redundancies that conspire to raise the total cost of IT. The challenge is that each team tends to favor one approach to automating a silo with little to no regard for a larger overall strategy to create an automation standard, he said.

    That approach also creates issues whenever a member of one of those teams leaves an organization, he noted. In fact, the survey found 77% of respondents reported that continuity is at risk any time a vital member of the team leaves.

    CloudBolt has been making a case for a federated automation platform that can be invoked either via application programming interfaces (APIs) or a graphical user interface (GUI) that provides access to low-code tools. The goal is to make the platform equally accessible to DevOps teams or IT administrators that tend to lack programming skills, and do so in a way that doesn’t require individual teams to replace their automation platform of choice. Instead, each of the automation platforms can be programmatically invoked via a central framework, said Kilcoyne. That approach eliminates any political debate over the potential need to replace one team’s favored automation platform with another, noted Kilcoyne.

    Regardless of who is accessing the platform, most organizations would be well-advised to develop a center of excellence for automation, he added.

    DevOps teams have always been committed to ruthlessly automating as many IT processes as possible, but in many cases, that has resulted in a plethora of automation tools being employed. In effect, automation may have become too much of a good thing. One approach to regaining control over those platforms is to create a platform engineering team that centralizes the management of DevOps workflows.

    Regardless of approach, Kilcoyne said the most important thing for any team to do before automating an IT workflow is to first understand how to manually set it up. Too many IT teams are trying to apply automation to processes they don’t really understand with mixed results, he added.

    The one thing that is certain, especially with the rise of artificial intelligence (AI), is the management of IT is going to become more automated.

  • CodeSee Extends Reach of Code Visualization Platform

    CodeSee Extends Reach of Code Visualization Platform

    CodeSee updated its code visibility platform to enable instant mapping of application services, directories, file dependencies and code changes.

    CodeSee CEO Shanea Leven said CodeSee Enterprise 2.0 should extend the appeal of the platform beyond developers to include software engineers managing DevOps workflows.

    CodeSee Enterprise 2.0 provides real-time visibility across multiple repositories regardless of whether the application is a monolith or based on a microservices architecture, she noted.

    In addition, a Code Automations module enables developers to set granular conditions and actions down to the function level, requiring checklists to be complete before allowing developers to move on.

    CodeSee Maps now includes the ability to click to view code directly, while a streamlined Review Maps module has decreased code review time by 30%. Developers can easily share maps to discuss proposed changes or keep necessary code changes as automatic permanent artifacts.

    Additional languages including C#, VB.NET, ASP.NET, Blazor, Java, JavaScript, Go, Python and TypeScript are now supported.

    Finally, CodeSee is making available a dedicated solutions engineering team that provides guidance to connect an organization’s Datadog or OpenTelemetry trace data to CodeSee in less than an hour without storing code or having to first dive deep into traces, noted Leven.

    The core open source CodeSee tool was created because it takes too long today for most developers to pore over a codebase to understand where they might contribute. The larger a codebase becomes, the longer it takes for a developer or software engineer to be onboarded to a new project.

    The overall goal is to improve developer productivity, noted Leven. That’s become a critical issue because many organizations are hesitant to hire additional developers during uncertain economic times; they first want to ensure they maximize the utilization of the teams they already have.

    Application development, of course, is now a team sport. The days when a lone developer cared for an entire application are long over. The issue is finding a way for teams of developers to collaborate more easily in an era where many of them may never have met in person.

    In the longer term, Leven said she also expects that generative artificial intelligence (AI) platforms such as ChatGPT will supplement code visualization tools. Many developers are already starting to use these tools to help generate code faster. That code should, in theory, have fewer errors because it has essentially been copied from other previously validated sources. CodeSee provides a means to visualize that code before deploying it to ensure it will function as promised in increasingly complex application environments.

    One way or another, the tools being provided to developers to boost productivity are advancing. It’s not clear what metrics should be employed to track developer productivity, but the amount of code simultaneously moving through DevOps workflows is going to increase. The challenge DevOps teams face now is keeping track of all the dependencies that exist in that code as application environments are continuously updated.

  • Database Virtualization – Driving the Next Big Transformation

    Database Virtualization – Driving the Next Big Transformation

    Data is both the most important asset and the biggest challenge for most corporations. It impacts every aspect of the business from financial considerations to AI/ML training. Data is used by development and DevOps teams, engineering teams, quality assurance, business intelligence teams and database administrators. Despite its central role in operations, traditional forms of database delivery remain complex, costly and time-consuming.

    In many cases, enterprise data is growing exponentially, increasing management challenges and driving up the cost of data storage. Duplicating data to each new environment as use cases arise is overwhelming DBA teams and incurring a significant storage footprint. This has resulted in data becoming a significant bottleneck for DevOps teams, highlighting the importance of finding a quick and automated solution for the replication process across non-production environments.

    What’s Changed?

    In the past, development teams would work with the same dataset for upwards of six months. This left DBA teams with plenty of time to meet all database delivery needs. However, as technology became more sophisticated and consumers grew more demanding, the data delivery life cycle was cut down dramatically. Today, with agile development, new features may be added every few days, if not hours. Coupled with QA teams’ requirement for testing data continuously, AI/ML teams requiring millions of data points for accurate training, and data analysts constantly needing fresh data for organizational growth, this means DBA teams are flooded with demands they are incapable of managing.

    What Now?

    Database virtualization is an automated and easy solution to the dataset bottleneck. By simplifying the creation and distribution of database replicas, DevOps teams will be able to create fully functioning virtual environments via a self-service process–allowing DBA teams to focus on more critical duties relating to production databases.

    Speed Up

    The first—and most obvious—advantage of this approach is the increased speed at which data is delivered. To keep DevOps teams productive and avoid the use of old, stale data, new environments need to be produced on demand. By integrating the production of new environments into the CI/CD pipeline, enterprises will be able to automate the process and provide DevOps teams with full autonomy. By cutting out the dependency on the DBA, teams will be able to access the data they need, when they need it.

    Scale

    Agility is fundamental to the success of database management. Each team requires an independent environment, unaffected by other use cases. The creation and supply of virtual databases allow for quick provisioning. Once created, these databases look identical to the original physical database and function completely independently of each other. Any changes made to a vDB remain unique to the environment it’s in.

    Save

    As the need for data grows, so does the cost of storage. Creating a physical copy for each team and use case results in a significant storage footprint. This means that these datasets come with a hefty cost. However, the creation of virtual databases led to a dramatic decrease in storage needs. Where traditionally, physical datasets can weigh upward of several TB, vDBs only weigh a few hundred megabytes. Further, virtualization solutions also compress the weight of physical copies – such as the golden copy – actively decreasing the weight and cost of storage across all fields.

    Secure the Database

    Even after the database delivery problem has been solved, enterprises are faced with another major issue – security. With so many different teams accessing data in virtual and low-level testing environments, the risk of ransomware and other cyberattacks increases dramatically. Generally, the investment in securing non-production environments is significantly weaker than in production.

    A common approach to address this issue is masking sensitive data so it is rendered useless to outside sources. However, traditional masking requires a data expert to manually sift through all existing data and implement data masking algorithms on any sensitive information found. This time-consuming solution creates a new data bottleneck. By automating the process and applying it to the golden copy, corporations can be confident that all vDBs created are completely secure and privacy compliant.

    Looking Ahead

    Database virtualization is the future of database replica management. Virtual databases are delivered in a matter of minutes, significantly accelerating the speed of delivery. These environments are easy to use, independent, and can be maintained via a self-service portal. The ongoing sync between the original database and the vDB ensures continuous access to the latest data without the need for timely or expensive processes.

    Effective database virtualization will allow well-established enterprises to more easily compete against those agile startups that face significantly fewer barriers to entry.

    Image Source: joshua-sortino-LqKhnDzSF-8-unsplash

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Dice.com

    NerdRabbit
    New York, New York
    DevOps jobs
    $120,000 to $150,000

    LinkedIn

    Tata Consulting Services
    Sunnyvale, California
    AWS DevOps Engineer
    $105,000 to $130,000

    Monster.com

    VANET, Inc.
    Irvine, California
    Software Engineer
    $100,000 to $300,000

    SimplyHired

    Renaissance
    Remote
    DevOps Engineer 2
    $100,000 to $125,000

    Indeed.com

    GEICO
    Remote
    Senior DevOps Engineer
    $82,000 to $185,000

  • 5 Key Performance Metrics to Track in 2023

    5 Key Performance Metrics to Track in 2023

    It’s never a bad time to adopt healthy new habits for the mind and body, and for developers, it’s always a good time to consider new best practices at work. As 2023 rolls on, I’ve been thinking about some key performance metrics that help to ensure critical applications and websites perform optimally throughout the year—especially during unpredictable spikes.

    To see why this is important, just look at the problems Ticketmaster had in November 2022 when Taylor Swift’s concert tickets went on sale. Fans of the pop idol (including me!) swamped the Ticketmaster site and brought the system to its knees, resulting in frustrated customers and a wave of bad publicity for the company.

    These usage spikes and the problems they can produce are not uncommon. The holiday sales period, starting with Black Friday and Cyber Monday, is notorious for technical issues that can cost retailers millions due to lost sales and other problems. And it’s not just retail. A few years ago, the Internal Revenue Service (IRS) had to extend its tax deadline after a rush of last-minute filers knocked its systems offline.

    Fortunately, developers can mitigate these problems with the right planning and practices in place. There are key performance metrics that developer teams should monitor, especially in times of peak traffic, to avoid application crashes, long wait times—and burnout for the teams who have to fix these problems when they arise.

    Here are the five performance metrics developers should be tracking in 2023—especially on their busiest days of the year.

    Web Vitals

    The largest contentful paint, or LCP, measures the load speed of a webpage. Having a fast LCP is a clear sign that a customer’s experience is optimal as they toggle between pages. In tandem, the cumulative layout shift, or CLS, scores how a user is experiencing unexpected layout shifts. This plays out on busy shopping days: Typically, these pages have ad and sales notifications that affect a brand’s main page layout, potentially causing shoppers to experience unexpected shifts. This can reduce their ability to shop and becomes a hindrance if a developer cannot quickly access and address the issue.

    Error Count Vs. Error Rate

    Error counts typically increase alongside site traffic as more people flock to a website—that’s a natural occurrence. The error rate is more telling because it reveals if a greater proportion of users are experiencing issues with your application or website. Developers who see an increase in this metric should investigate and take action.

    Mobile Monitoring

    More and more consumers are using their mobile devices to shop and manage all aspects of their lives. For example, mobile accounted for 45% of sales during the holiday shopping period in 2022 from October to December. Mobile performance metrics are critical to understanding what is happening on your users’ devices during these busy times. Vitals like frozen and slow frames or cold and warm starts when an app opens provide visibility into how fast views are loading for your users. As became obvious with the Taylor Swift incident, a slow shopping experience can lead to an outcry and a lot of upset customers.

    Outside of vitals related to mobile performance, it’s important to monitor mobile changes through application release health. Developers can see this in the rate of crash-free sessions and crash-free users as traffic to an application increases—which helps to identify abnormalities in the overall health of the app.

    Slow Database and HTTP Ops

    During sustained traffic spikes, database queries and HTTP requests that take too long to execute harm the user experience. Hitting a slow checkout process, or seeing the dreaded spinning beach ball after adding a product to the cart, confuses shoppers. They don’t know if they should refresh the page, and often they will abandon a purchase completely.

    What’s more, if a developer is working on a backend framework, slow database and HTTP ops could also be a sign of an N+1 query problem. At that point, an application is making database queries in a loop and causing performance issues for the purchaser.

    User Misery

    This is a homegrown metric we use at Sentry; tracking user misery helps developers understand a customer’s experience with an application. It is a ratio of unique users who have experienced load times at 4x a configured threshold in a Sentry project and thus serves as a proxy for customer frustration. With this user misery score, our developers can see which transactions have the highest negative impact on users and prioritize fixing them.

    Providing a smooth end-user experience is table stakes for businesses throughout the year, but especially during high-pressure, culturally-driven spending moments. In any of these scenarios, developers behind the scenes often work long and odd hours to address performance issues and ensure the most seamless experience. You can’t prepare for everything that can possibly go wrong, but you can be equipped with the right tools and metrics to quickly identify and remediate any problems that occur.