devopsy.kinsta.cloud

Category: DevOps Practice

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

  • The Scariest Things About SCA

    The Scariest Things About SCA

    It is a time of ghouls, mischievous spirits and David S. Pumpkins. In the spirit of Halloween, here are the top five scariest limitations of software composition analysis (SCA) tools that are enough to send shivers down your spine. Read on … if you dare!

    1. SCA Scans Only Your Application Code

    SCA’s scope is frightfully narrow. When scanning for vulnerable dependencies, SCA only examines your source code even though vulnerable dependencies used to build your software can exist throughout your entire development pipeline. Vulnerable dependencies can be found in dev tools like Jenkins, dev tool plugins like Jenkins Plugins, build modules like GitHub Actions, build module dependencies like GitHub Actions libraries, and infrastructure-as-code (IaC) dependencies. If you’re only scanning application code, you should be shaking in your boots because it is not enough to protect against modern software supply chain attacks like SolarWinds or Codecov.

    The good news is that next-gen SCA, pipeline composition analysis (PCA), scans your application code and your entire pipeline for vulnerable dependencies. PCA improves upon the foundation of SCA by including a deep understanding of the tools, configurations, processes, activities, components and dependencies used at every stage of the delivery pipeline. When new dependencies like Text4Shell are disclosed, you can be sure every instance of the vulnerability is found and remediated. This way you know you don’t have any proverbial skeletons lurking in your software’s closet.

    2. SCA Can’t Tell You Where Vulnerabilities Are Deployed

    Vulnerability remediation can be ghoulish. When new high-severity exploits are disclosed, you need to remediate every instance of the vulnerability from all production environments where it could be exploited–and you need to do it fast. Identifying a vulnerability like Log4j in your code base is a start, but you’re not truly secure until you have removed every instance of the vulnerability in production systems where they pose a real risk to your organization. Though traditional SCA can tell you where a vulnerability is in your application code, it has no visibility once that code has been deployed.

    PCA gives you visibility into your entire development pipeline, including production environments. This enables you to easily trace the path of a vulnerability from code to deployment locations, such as identifying which Kubernetes clusters contain a specific vulnerability. This enables organizations to be more agile in their response to newly disclosed threats and ensures that every instance of a vulnerability has been remediated.

    3. SCA Doesn’t Correlate Risk Across AppSec Engines

    Some traditional SCA solutions may be able to collect data from various scanning engines, but they are terrible at making meaningful connections between various data points. Because of this, “traditional” SCA is unable to provide the context required to deliver an accurate and nuanced assessment of the impact of one event and how risk might be compounded by other related events. SCA without context generates too many false positives—this results in your team wasting time chasing ghosts.

    PCA correlates risks and threats across all phases of the SDLC as well as from all AppSec scanning tools. By connecting the dots from numerous data sources, PCA helps your security and DevSecOps teams understand holistically how risks relate to each other so they can best tackle the most important security initiatives first.

    4. SCA Ignores Pipeline Security and Governance

    Modern development pipelines are complex and deeply interconnected–almost as if they are stitched and bolted together like Frankenstein‘s creation. Though managing security policies across the entire SDLC is an arduous and painful task, it is essential if you want to prevent software supply chain attacks. Unfortunately, traditional SCA solutions don’t even come close to helping you manage pipeline security and governance policies like enforcing least privilege or hardening authentication.

    Pipeline composition analysis identifies pipeline tooling misconfigurations and helps you implement best practices for security controls across your entire pipeline. Even better, to prevent your tooling from being bypassed, PCA alerts you when pipeline security controls like SCA scanning are removed or disabled.

    5. SCA Provides No Visibility into Your SDLC

    Traditional SCA solutions focus only on application code. They provide no visibility across your SDLC. They were not designed to scan development and deployment environments, so they cannot secure the later parts of your SDLC. SolarWinds was infiltrated via its TeamCity build server, which traditional SCA tools did not scan. So how can you protect your software supply chain if you can’t see it? Don’t be haunted by SCA tools’ inability to scan the entire SDLC.

    Vulnerable dependencies that impact your application can be found across the SDLC. You need to understand all development and deployment tooling–activity, settings, configuration, users and more–to protect your application. Pipeline composition analysis was designed from the ground up to understand your SDLC and bring context to your SCA findings to improve accuracy. It can give you complete visibility into the big picture to cut down on all the noise that traditional solutions generate.

    Pipeline Composition Analysis: Put Your Nightmares to Rest

    While it’s fun to be scared at Halloween, the last thing you want is to be terrified by your AppSec program. When the limitations of traditional SCA solutions threaten to keep you up at night, just remember that AppSec innovation requires the ability to do pipeline composition analysis across the entire SDLC, hence the shift from SCA to PCA. PCA plugs all the holes mentioned here, which hopefully can put even the worst nightmares to rest.

  • One-Third of Developers Seeking New Job

    One-Third of Developers Seeking New Job

    With the relentless pace of enterprise digital transformation efforts, even in this softening economy, developers still face an enviable job market. The number of open job positions in computer occupations is greater than 804,000, according to National Foundation for American Policy (NFAP) analysis and, at 326,000 vacancies, software developers have by far the largest number of job openings available to them.

    US Developers Are Less Confident About Job Prospects

    Still, according to a new report from OutSystems, Developer Engagement Report: Are Your Developers Happy or Halfway Out The Door?, slightly more U.S. developers are seriously considering changing companies right now (33% U.S. versus 31% globally) and they feel less confident about their prospects. Only 25% of U.S. developers strongly agreed that there are many opportunities to easily get a better position right now, compared to 42% of global respondents.

    Still, not many developers are thrilled with their current jobs. According to the survey, only 49% of U.S. developers love their jobs and only 37% are very satisfied with the work they do every day. Outside the U.S., developers are a bit more optimistic. Globally, 64% reported that they love their jobs and 46% said that they are very satisfied with their day-to-day work.

    Interestingly, when it came to work-life balance, it was U.S. developers who felt more optimistic than their global counterparts. While 50% of all respondents strongly agreed that they need more work-life balance, only 38% of U.S. developers agreed on the same.

    Finally, while 48% of developers said that they would definitely be with their current employer within a year, when that timeframe was extended to two years, that figure fell to 29%. And U.S. developers are itchier to move, with only 38% saying that they would definitely be with their current employer in a year and 18% said they would remain there in two years.

    Most Low-Code Developers Also Traditional Coders

    The report also examined so-called low-code developers. As a subset of the broader population of developers, 59% of low-code developers reported being very satisfied with both team productivity and 57% were satisfied with the quality of tools they use at work. Only 41% of traditional developers felt the same toward team productivity, and only 36% of traditional developers are very satisfied with the quality of the tools they use.

    Interestingly, 71% of low-code developers reported that they can keep their workweek to the standard 40 hours, while only 44% of traditional developers said the same. While 63% of low-code developers said that they are happy with their salary and benefits, only 40% of traditional developers agreed. Further, low-code developers claimed an average of 3.5 job promotions at their current company while traditional developers said they’ve been promoted two times.

  • 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 as part of an effort 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:

    Indeed.com

    Bobcat Company
    Bismarck, N.D.
    Solutions Architect AWS and SecDevOps
    $130,000 to $180,000

    LinkedIn

    Lenovo
    Morrisville, N.C.
    Software DevOps
    $100,000 to $140,000

    Monster.com

    Softweb Solutions
    Plano, Tex.
    AWS Engineer
    $100,000 to $140,000

    Dice.com

    Estuate
    Remote
    DevOps Engineer
    $100,000+

    Indeed.com

    Landmark Global
    Remote
    DevOps Engineer
    $90,000 to $105,000

  • Mezmo Adds Observability Pipeline to Analyze DevOps Data

    Mezmo Adds Observability Pipeline to Analyze DevOps Data

    At the KubeCon + CloudNativeCon North America conference this week, Mezmo launched an Observability Pipeline platform that promises to make it simpler to manage, enrich and correlate machine data.

    Previously known as LogDNA, Mezmo is expanding the scope of its reach to add the ability to augment and analyze data on top of its core log management platform. Over time, that capability will be extended to add support for metrics and traces using the open source OpenTelemetry agent software.

    Mezmo CEO Tucker Callaway said the goal is to provide a framework for centralizing the flow of observability data that is now being generated by a wide range of sources across a DevOps workflow. It’s clear that DevOps teams require a means to enrich and correlate high volumes of data in motion that goes beyond simply pre-processing so it can be stored more cost-effectively, he added.

    The Mezmo Observability Pipeline achieves that goal by ensuring the right data is flowing into the right systems in the right format for analysis, noted Callaway.

    As the volume of data being collected by DevOps teams continues to dramatically increase the need to embrace a set of DataOps best practices is becoming more apparent. DataOps has emerged recently to describe a set of data engineering practices that applies many DevOps principles to the way data should be managed. Mezmo’s Observability Pipeline aims to make it simpler to apply DataOps best practices specifically to the data collected by DevOps teams.

    Of course, each DevOps team will need to decide for themselves how much data they want or need to store long term. However, increasingly DevOps teams are holding onto data much longer as IT environments become more complex, noted Callaway. That creates a need to more efficiently analyze as much data as possible and store it more cost-effectively, he said. Those twin goals, however, often create a physics problem in the sense that they can be diametrically opposed.

    In the longer term, it’s not quite clear how much DevOps teams are embracing observability. Most DevOps teams make use of monitoring tools that enable them to track a set of pre-defined metrics. Observability platforms promise to make it easier for DevOps teams to query a wide range of data types to discover potential issues before they disrupt an IT environment. The challenge is that many DevOps teams may not know what queries to form to discover those issues. It’s likely that, over time, machine learning algorithms will be increasingly applied to observability data to make it simpler to surface potential issues.

    In the meantime, however, the need for DevOps teams to find ways to manage all the data being generated by multiple types of applications is becoming a higher priority. In fact, in the absence of any meaningful way to manage all that data, the benefits of an investment in an observability platform is likely to be limited, at best.

  • Making App Dev More Efficient

    Making App Dev More Efficient

    Applications of all kinds are continually popping up across various industries to help improve consumer customer experiences, provide entertainment, make certain tedious or error-prone tasks easier for workers and to help businesses improve their operations overall. In fact, there are over 5.4 million applications available across the Apple App and Google Play stores as of this year.

    As more and more individuals and organizations turn to applications for various experiences and to drive enterprise efficiencies, we need to take stock of the process we deploy in application development.

    The Inefficiencies of Application Development

    Today, it is estimated that there are more than 26 million software developers worldwide. Each of these developers brings a unique combination of creativity and technology acumen to the organizations they work for and the applications they create. However, the current application development process in many enterprises is riddled with inefficiencies that often require these talented developers to focus on tedious, mundane, non-innovation-related tasks. 

    Technical Debt: Renowned programmer Ward Cunningham first introduced the concept of technical debt in 1992, stating, “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.” What many didn’t realize at the time was that technical debt would grow to be a major issue in software and application development years later. Recently, a new Scandinavian study found that developers dedicate 23% of their time, on average, to addressing technical debt. While this statistic alone should be alarming to enterprises—given their development teams are spending a quarter of their time on an issue that could have been avoided had a different approach been taken—the study also found that developers often have to introduce new technical debt in the process. 

    Maintenance: As with all technological equipment, applications require routine maintenance to ensure they remain working for the end user, provide ongoing value and are secure. However, unlike a car or kitchen appliance, applications see far more frequent updates from operating systems (OSes), cloud or hardware providers that need to be addressed by development teams. According to research from Stripe, developers spend more than 17 hours per week on maintenance issues like debugging or refactoring. For instance, take a look at Apple. From the time iOS 15 was released in June 2021 as a beta, there were more than a dozen updates made to the OS until early September 2022. That means that every single time the updates were released, developers had to spend time ensuring their applications were working correctly, were bug-free or complied with new security measures. When you add this to the fact that the average enterprise app has 110 third-party integrations, that is an extreme amount of maintenance.  

    The Reinvention of the Wheel: Of all the applications available today, many of them consist of the same foundational features and functionality—login, chat, social sharing, payments and more. What’s astonishing about this is that developers are frequently recreating each of these common features and functionalities from scratch every time they develop a new application. 

    It is clear that these tasks are highly inefficient, and it begs the question, “What can be done to address these inefficiencies?” 

    Prioritizing Innovation 

    It is not enough to just introduce some sort of technology in the hopes that it makes application development more efficient. It also requires an overall mindset change by enterprises. Yes, it is still of the utmost importance to get applications to market quickly and keep up with the pace of competition; however, innovation doesn’t have to be sacrificed to do so. 

    Innovation must be the key driver for enterprises and their development teams. Providing unique value and experiences to end users will truly set enterprises and their applications apart from the competition. But, the reality is that nearly 80% of technology leaders from around the world believe basic application maintenance and support are the biggest barriers to innovation. 

    Enterprises must be able to balance innovation, time-to-market and development processes that are free of technical debt and outrageous maintenance support. 

    Making Application Development More Efficient

    One way in which enterprises can balance innovation, commercialization, and development is through an emerging approach to application development known as features-as-a-service (FaaS). 

    A FaaS approach to application development enables enterprises to implement an agile and accelerated engineering process—similar to that of low-code/no-code without the constraints often seen with those vendors and their functionality today—without sacrificing quality, code or time. More specifically, it combines pre-coded “commodity” features with continuous and automatic updates that empower development teams to spend their time and creative minds on innovation. In most cases, this approach can help enterprises bring applications to market within weeks instead of months and limits the headaches on the backend for development teams down the line. 

    As enterprises work through the fourth quarter of this year, I implore them to reconsider their development process at a fundamental level and bring innovation to the forefront before the beginning of 2023. Time and resources are of the essence, and something must be done now to address the inefficiencies of application development. 

  • BMC Extends Scope of ServiceOps Initiative

    BMC Extends Scope of ServiceOps Initiative

    At the BMC Exchange conference this week, BMC revealed it has updated its Helix IT service management (ITSM) platform to include mapping and discovery capabilities. Those updates make it simpler for cross-functional teams to correlate incidents, alerts and data and pinpoint root causes faster.

    In addition, BMC is now applying pre-trained artificial intelligence (AI) models to observability data and the service models it tracks to assess service health, predict service impacts and proactively manage IT environments as the volume of metrics, events, and alerts continues to increase.

    Finally, BMC also announced that the BMC Helix Control-M orchestration engine now supports open source Apache Airflow, a workflow management platform for defining data pipelines using a Python programming tool.

    Margaret Lee, vice president and general manager for digital service and operations management at BMC, said these updates extend a unified ServiceOps initiative the company launched last year to unify ITSM, DevOps and customer service desk workflows. While each of these disciplines may have distinct objectives—such as speed and reliability—that are often in conflict with one another, Lee said it’s apparent IT organizations need to reduce the current level of friction that is often encountered when managing IT.

    As a software-as-a-service (SaaS) platform, Lee said the BMC Helix platform achieves that goal via a consumer-like user interface that can be easily personalized. The goal is to make it simpler to create virtual agents, knowledge bases, live chat and tickets that make it easy for customers and employees to request IT help, she added.

    Achieving that goal, however, will require IT organizations to rely more heavily on AI models to automate routine tasks as IT environments become more complex. There are simply not enough IT professionals available to manage IT environments using legacy processes, she noted.

    In addition, end users and customers are expecting service requests to be automated in way that allow them to resolve issues via a mobile device, added Lee. In many cases, how cumbersome IT processes now has a direct impact on both customers and employee retention. The primary goal is to reduce the number of interactions required to complete a task such as changing a password or provisioning a laptop whenever a new employee needs to be onboarded.

    While the pace at which IT management is evolving will vary greatly from one organization to the next, it’s apparent that many DevOps principles are being absorbed into traditional ITSM platforms. The challenge is that cultural divide between DevOps teams and centralized IT teams is still very wide. Most organizations are still trying to determine how far left they want to shift responsibilities toward application development teams versus continuing to rely on IT administrators using graphical tools to centrally manage IT workflows. It’s rarely going to be an all-or-nothing proposition. Rather, the issue is finding a way to strike a balance that enables organizations to be as agile as possible without introducing unacceptable levels of risk to resiliency.

  • Why You Should Consolidate Your IAM

    Why You Should Consolidate Your IAM

    It’s not often you can get a win that makes your IT processes easier while simultaneously improving your cybersecurity. In fact, oftentimes making improvements in one area (for example, improving IT processes) comes at the cost of the other (cybersecurity). But there’s one area, in particular, where these improvements aren’t mutually exclusive: Identity and access management (IAM). In fact, consolidating the identity and access management technology used in your organization is one of the few ways to simplify and secure against threats at the same time. Let’s see why this is the case by focusing on each of those items individually and then look at the big picture.

    Let’s start with security. Properly managing identity and access is naturally a critical component of a good cybersecurity stance. If you aren’t properly managing access or don’t know who is leveraging your access tools, the rest of your cybersecurity stack won’t be of much help in keeping you out of the headlines. While that’s pretty obvious, the piece that’s easy to overlook is the consolidation of those tools. As organizations grow, they often find that rather than scaling solutions with teams, they pick up additional solutions for new teams, new locations, new vendors and so on. Suddenly, the original corporate VPN is now three, there are five different vendor access methods (all tied to different authentication methods or shared accounts), some users are in Active Directory, some only in GSuite and there are too many local accounts on applications to count. At the end of the day, each path to an application should be tied to a proper access tool with authentication and a known individual identity, but that becomes difficult or impossible to verify. At that point, it takes just a few questions to realize the security risks of disparate access solutions:

    • When something goes wrong, how do you verify who may have had access to that system? How many access solutions could have gotten a user there?
    • When John leaves the organization, how certain are you that all of his access will be revoked?
    • How do you know that all of these solutions are up-to-date with the required patches to remain secure?
    • Is there a comprehensive list of access methods the organization uses, or are you going to find some long-forgotten VPN in the future?

    So, the security implications quickly become obvious. Consolidating on a minimum number of required solutions means you can address those security gaps with simplification. It’s not often that you get the chance to do that in a world where security usually means adding another tool to the stack. The result of consolidating means your users, whether non-technical end users or IT admins, all see improved workflows. Fewer credentials for end users to manage and less chance they’ll need different access tools depending on the system they need to reach. From the IT side, it means your staff can quickly provision or deprovision access. It also means that when something does go wrong, a clear picture of all access to an affected system can be drawn up in minutes, rather than hours or days. When consolidating identity and access management tools, the following should be clear goals:

    • User authentication should enforce multifactor authentication (MFA)
    • Authentication should also include employment verification when third parties are involved
    • Access management should embrace a least-privilege access model, narrowing access to specific applications and even timeframes where applicable
    • An access solution should take into account the various needs of all user profiles at the protocol level. Some users may need a few web services, while others might need the right protocols to manage servers or custom applications
    • IT admins should be able to quickly identify all the access a user has and all the users with access to a given endpoint
    • History and audit is a given

    Keeping these items in mind when consolidating technologies should not only make it easy to find which tools are right for your organization, but which tools are in place today that should be the first to go. 

    In the end, all organizations have to face identity and access management challenges. Sometimes that’s a problem that can be tackled with a centralized solution from day one, but oftentimes it becomes a mess of tangled wires. Whether you’re starting from square one and building your technology set or you’re pulling those wires apart, the end goal of consolidated solutions is the best way to present a simple solution that makes your users happy while maintaining the security that your organization will depend on for years to come.

  • 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 as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it just that much 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:

    Direct Contact

    ZoomInfo Engineering
    Waltham, Mass.
    Cloud Security Operations Engineer
    $145,000 to $180,000

    Dice.com

    Orion Business Innovations Careers
    Montvale, N.J.
    DevOps and Engineering Manager
    $140,000 to $160,000

    Indeed.com

    Liberty Mutual Insurance
    Remote
    Scrum Master II – Secure DevOps
    $131,000 to $152,300

    LinkedIn

    Kyndryl
    Denver, Col.
    Cloud DevOps
    $120,000 to $200,000

    SimplyHired

    Penguin Computing
    Fremont, Calif.
    DevOps Engineer
    $120,000 to $170,000

  • Fire at Data Center Causes Chaos | 20% Costlier Cloud

    Fire at Data Center Causes Chaos | 20% Costlier Cloud

    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: A South Korean conflagration leads to a ridiculously long outage, and the price of public cloud is skyrocketing. (more…)