Category: DevOps Culture

  • The Cyber Resilience Act Threatens the Future of Open Source

    The Cyber Resilience Act Threatens the Future of Open Source

    The European Union (EU) is currently considering approval of the Cyber Resilience Act (CRA), a proposed regulation that is a major threat to the future of the global open source industry. While the intention of the act is to enhance cybersecurity (which is extremely welcome), its current form lacks clear liability exemptions for many open source developers and maintainers, which could be a death knell for open source in the EU and which could spark additional, global implications.

    The CRA regulation for the EU was proposed on September 15, 2022, by the European Commission. The intent is to improve cybersecurity and cyberresilience in the EU through common cybersecurity standards for products with digital elements. In theory, this is welcome. But there are some notable areas that many open source developers and industry organizations are concerned about.

    Modern applications are comprised of 90% open source code; penalizing open source developers would lead to a fragmented community and hinder important projects across various sectors, including critical infrastructure, health care and even military systems.

    The seemingly purposeful omission of exemptions for open source would put undue onus on open source foundations and maintainers and poses a serious risk to not just EU innovation and security but global collaboration. Something we, and many others in the industry, have tried to raise awareness about over the past six months. Unfortunately, the EU has largely ignored the industry’s voice. Holding open source developers whose components end up in commercial products liable for security issues will stifle innovation and harm the EU economy without providing a substantive improvement in security.

    This legislation is slated for a vote on July 19 in the parliament’s Industry, Research and Energy (ITRE) committee, where it will then be sent on to the full parliament. And, if nothing is done, it could be adopted without even a vote in a plenary session by the Parliament itself. I feel strongly that if the open source industry doesn’t take a stand now, it will become law and the open source community as we know it will be no more.   

    There are two main problems with the proposed CRA: It discourages commercial support of open source and imperils vulnerability disclosure.

    CRA Discourages Commercial Support of Open Source

    The revised CRA offers new cybersecurity requirements for hardware and software products, much like the U.S.’s National Cybersecurity Strategy does. It calls for software vendors and producers to understand what components are in their software and to be able to recall software that is affected by a vulnerability. But, unlike the recently released details for the U.S. strategy, it seems to be trying to call out certain open source projects from foundations and large companies. By doing so, it potentially impacts every open source project, which creates a web of issues.

    It goes without saying that open source projects rely heavily on volunteers, individual contributors and small teams who often work without significant resources or financial support. The support that foundations and contributors do get often comes from commercial entities who have adequate resources to provide developer time to give back to the community.

    The current CRA text only excludes OSS software that has no commercial activity around it. Unfortunately, it defines commercial activity in part, this way:

    “where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.”

    This can be read to mean that if the main contributors are not unemployed, then the project is commercially tainted. It does not clarify what was probably intended—that the employer fully controls the project here.

    Additionally, it says:

    “Accepting donations without the intention of making a profit should not count as a commercial activity, unless such donations are made by commercial entities and are recurring in nature.”

    The first part is acceptable, but recurring donations from commercial entities are the upside of contributing back to open source. This may force the projects to reject large contributions to avoid becoming “tainted,” and will likely cause commercial entities to enact further bans on OSS contributions and pull their support entirely.

    Further, if the CRA is passed without proper exemptions, these developers and maintainers may face legal risks and liabilities for vulnerabilities found in code used in commercial products. The OSS developers have no visibility into how and in what instances their components are used; only the final manufacturer of the product has this visibility.

    The potential legal risk, without an upside, would discourage OSS developers from contributing to and maintaining open source projects. This situation not only undermines the spirit of open source but could bring about an open source crisis and isolate the EU from the rest of the world. Non-EU open source producers will avoid the EU market, meaning no access to Linux, Apache, Kubernetes and many other projects. Repositories like Maven Central, npm and PyPi may be prompted to ban EU consumption to avoid being considered a distributor. EU projects concerned about liability could pull their source code off the internet, and EU businesses may be forced to halt contributions to open source projects.

    CRA Imperils Vulnerability Disclosure

    The regulation also would require that vulnerabilities be disclosed to the European Union Agency for Cybersecurity (ENISA) within hours of discovery, whether or not a fix is available. This would make it difficult to conduct coordinated disclosure—where researchers give vendors time to develop security patches before vulnerabilities are disclosed publicly. This would increase the chances that bad actors will develop exploits for the vulnerabilities before they are fixed, putting every company that uses that software at risk. This would be an unfortunate outcome for a law whose purpose is to improve security of software.

    What Can we Do?

    As I mentioned earlier, time is of the essence since this measure is moving quickly and faces a vote this week. We need the community to take immediate action. GitHub and other industry bodies need to publicly oppose the proposed measure. EU developers, maintainers and others need to ask their European Parliament Members (MEPs) to investigate further and bring the voices of the open source community to the discussion.

    Legislators need to understand the importance of collaboration and the role of the global developer community in driving open source innovation. Open source projects underpin much of the software we use every day. It’s the lifeblood of the internet. Legislation that deters contributors would interfere with the open source community’s ability to maintain existing projects and deliver new software, impacting the tech industry, hurting the EU economy and compromising overall software security.

  • State of API Report Highlights Productization and Generative AI

    State of API Report Highlights Productization and Generative AI

    In today’s software landscape, an API-first strategy is increasingly popular. It’s the bedrock of how applications are built and connected. APIs help promote internal tech reusability, helping developers do more with less. Due to this increasing API reliance, maintaining quality control is increasingly important for internal and partner integrations and ensuring the reliability and security of these connections remains a top priority.

    Due to the rising API ubiquity, nearly half of the total development energy is spent working with APIs. And to continually improve these interfaces, taking a product mindset is proving helpful. In fact, 60% of API developers now view their APIs as products. Generative AI has also shown incredible promise and is now being used in tandem with traditional tools to increase API code quality.

    Postman recently released its fifth annual State of the API Report. The 2023 edition, which surveyed thousands of developers and API professionals, found subtle changes in tooling preferences and styles. It also sheds light on the ongoing API productization movement and API developers’ use of generative AI. Below, I’ll focus on these two key areas and review the report for its other key takeaways.

    API Productization is Hot

    The majority of API developers now view their API as a product, and this figure rises to 68% in large companies. A full 65% of respondents said their API generates revenue, too. This news is significant, as it demonstrates the industry is maturing its view of APIs. They are no longer offshoot developer toys but fully functional services contributing to overall business growth.

    But how much growth? Well, of those monetizing APIs, 43% now say APIs generate a quarter of company revenue. For some companies, APIs generated more than 75% of total revenue! There also appears to be a parallel between API revenue generation and large companies.

    Do you view your APIs as products? Most developers say "yes."
    Do you view your APIs as products? Most developers say yes.

    Other industry reports unearthed similar API productization potential. Rapid’s 2022 State of APIs report found that 42.6% of organizations are now monetizing APIs. And investment into API-first products remains strong even amidst a broader contracted tech investment climate. These findings come as social media giants like Reddit and Twitter attempt to monetize their APIs.

    That said, for 28% of companies, API revenue still equates to less than 10% of total revenue. APIs still don’t get the lion’s share, perhaps because they’re packaged with an existing platform or because of the many other indirect ways APIs might benefit the business. Furthermore, consumers are becoming more cost-conscious, as 60% cite pricing as a factor before integrating with an API. Still, the numbers are significant firsts for the burgeoning economy.

    Most API Developers are Using Generative AI

    Generative AI interfaces like ChatGPT and Bard have certainly taken the tech industry by storm due to their ability to generate code snippets, debug code and more. And for the first time, the State of the API Report spotlighted generative AI and its use within the API economy.

    Today, 60% of API professionals are using generative AI on the job. API engineers commonly use generative AI to find mistakes in code, generate machine-readable code and increase learnability around their programs. Some even use generative AI to suggest potential security flaws in their APIs.

    Compared with other app development endeavors, developers are by far most excited about building generative AI-powered applications in the year ahead. Yet, the efficiency gains are modest—many engineers forecast productivity improvements of 10% to 25%.

    How are API developers using generative AI in their work?
    How are API developers using generative AI in their work?

    Generative AI is set to accelerate many areas, including DevOps and API operations. Yet, contrary to some headlines, generative AI can’t automate all aspects of the software development life cycle. Rather, the technology is more likely to augment the API developer’s workflow than replace the need for seasoned professionals altogether.

    Other Key Takeaways

    Similar to last year’s report, integrating between internal applications, programs or systems remains a top concern for integrating an API or producing an API. The good news is that these integrations continue to increase in quality.

    The report found that deployment failures and times-to-recovery are improving on average. More than half (56%) of respondents said API security incidents occur less than once a year within their organization. This shouldn’t overshadow the significant impact API security breaches can have but signals that DevSecOps is beginning to respond to persistent API vulnerabilities.

    There are more API-first leaders than ever before. And API owners continue to evolve how their services are built and deployed. For example, REST is still by far the most common API style, used by 86% of developers. Webhooks made second place at 36%. However, GraphQL rose in usage, bumping SOAP into fourth position.

    SOAP slips on API architectural styles
    REST is still the dominant style, but GraphQL makes gains as SOAP slips.

    Other Quick API Factoids

    • More non-developers are becoming interested in APIs, as evidenced by 53% of survey takers being non-developers.
    • Most APIs are private—61% percent of businesses’ APIs are for internal use only.
    • After the technology group, business/IT services, financial services and health care are the most common sectors to adopt APIs.
    • Microservices is still the dominant architectural style of APIs, at 42%.
    • Performance, security and reliability are the top factors evaluated when integrating with a new API.
    • Improper authentication, authorization or access control is the most commonly cited API risk.
    • Common API tools include Postman, SwaggerHub, Datadog, SoapUI and Insomnia. Top gateway and API management platforms include AWS API Gateway, Azure API Management, Apigee and Kong.
    • JSON Schema is by far the most popular API specification.
    • The financial industry is a leader in API-first strategies—32% of respondents spend more than 20 hours a week working with APIs.
    • Most developers deploy APIs to production once a week to once a month.
    • When developers leave a company, their departure can cause outdated documentation, zombie APIs and a loss of institutional memory.

    API Obstacles Remain

    Looking to the future, investment in APIs is projected to climb. In fact, 92% of developers said their organization plans to invest the same or more time and resources into APIs in the coming year. Yet, some obstacles remain—a lack of documentation and poor service discoverability are still prominent roadblocks to API consumption. Furthermore, a lack of time and talent are major concerns that might stunt API development.

    The Postman State of API Report surveyed over 40,000 developers and API professionals, making it the largest study conducted on APIs to date. It should be noted that, given Postman’s specific focus in the market and its surveyed pool, figures may be skewed to represent increased API enthusiasm. For deeper insights, you can read the entire report here.

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

    Indeed.com

    ServiceNow
    San Diego, California
    Senior Software Engineer – DevOps
    $119,970 to $204,030

    LinkedIn

    Fox Tech
    New York, New York
    Senior DevOps Engineer
    $118,000 to $157,500

    SimplyHired.com

    GM Financial
    Arlington, Texas
    DevOps Automation Engineer III
    $113,000 to $143,000

    CareerBuilder.com

    Edward Jones
    Henley, Missouri
    DevOps Technical Architect
    $109,696 to $186,781

    Dice.com

    Suremind Solutions
    St. Louis, Missouri
    DevOps/Site Reliability Engineer (SRE)
    $100,000 to $140,000

  • Forking RHEL! Oracle and SUSE Join the Fight ¦ Silverman Sues AI Firms

    Forking RHEL! Oracle and SUSE Join the Fight ¦ Silverman Sues AI Firms

    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: SUSE announces a Red Hat Enterprise Linux fork after Oracle said a similar thing, and Sarah Silverman says OpenAI and Meta have stolen her words. (more…)

  • Roadie Adds Scorecard Tool to Backstage SaaS Platform

    Roadie Adds Scorecard Tool to Backstage SaaS Platform

    Roadie today made generally available a tool that automatically tracks and reports how software development teams are performing against engineering standards defined by a DevOps team. The Tech Insights tool is an addition to Roadie’s implementation of the open source Backstage developer portal and is delivered via a software-as-a-service (SaaS) platform.

    Roadie CEO David Tuite said Tech Insights is a proprietary tool that Roadie developed as an extension to its platform. Tech Insights provides scorecards that track software assets in the Backstage catalog and ensure they are meeting predefined quality and compliance targets.

    Tech Insights comes with built-in, pre-defined data sources; alternatively, DevOps teams can define them using external application programming interfaces (APIs) or files in a repository. A rule known as a Check can then be created to validate whether a project complies with the engineering standards defined by the DevOps team. Each DevOps team can create an unlimited number of scorecards.

    In addition, teams can create prompts and notifications to warn engineers when they are about to make a change that will violate an engineering standard. DevOps teams can also employ gamification techniques to show teams how their performance compares to others.

    While Roadie is now adding its first proprietary tool to the platform, Tuite said the company remains committed to enabling organizations to migrate their instance of Backstage to another environment should they ever deem it necessary, he added.

    Originally developed by Spotify, Backstage makes it possible to create and manage a catalog of blueprints that developers can readily consume rather than requiring them to repeatedly build these capabilities themselves. The goal is to create scaffolds that developers can consistently reuse across multiple application development projects.

    Spotify has since donated Backstage to the Cloud Native Computing Foundation (CNCF). However, Backstage currently requires a significant amount of DevOps expertise to set up and maintain, an issue that Roadie is addressing by making it available as a SaaS platform that can be accessed by any application development team, said Tuite.

    The concept of a self-service portal through which developers can address their own needs may not be new, but as an open source project, Backstage is lowering the cost of improving overall developer productivity. At the same time, many organizations are now embracing platform engineering as a means of centralizing the management of DevOps.

    Ultimately, every minute developers spend on tasks other than writing code is one less minute they are spending writing the business logic that drives an application. Measuring developer productivity is, of course, an inexact science. No one knows for sure when inspiration might strike, but if developers are busy maintaining code that they created to provision infrastructure, it’s less likely they’ll be struck by a flash of brilliant insight that improves and application. The easier it is to spin up a development environment, the more likely that inspiration will one day turn into code that runs in an actual production environment.

  • Don’t Let Developer Experience Break Your Business

    Don’t Let Developer Experience Break Your Business

    As organizations digitally transform to support the needs of customers and help them win in their markets, IT leaders, software developers and DevOps teams have emerged as the central players in the transformation landscape. They are also key advocates for improving the developer experience and promoting technology adoption—both critical components of a successful digital transformation. They are also on the front lines of understanding operational and team challenges. Their understanding of the business objectives and the role people and technologies play in support of achieving these goals makes IT an indispensable driver of value creation.

    Digital transformation has also fueled the swift adoption of Kubernetes and cloud-native technologies, which promise enterprise speed and scalability. As these technology adoptions accelerate, so too does the demand to make developer experience a priority. After all, developers are tasked with creating and delivering software to the market quickly to support business objectives.

    As more organizations adopt cloud-native development methodologies, developers have taken on a more strategic role across the business. No longer just writing code, they have been asked to take on ownership of the entire application life cycle. In the cloud-native environment, this shift in developer responsibility comes with an evolving ecosystem of technologies and tools that can have enormous complexity and impact how dev teams collaborate as they code, ship, test and run apps to support business goals.

    Asking developers to take on this level of responsibility is not ideal for productivity. Most developers want to know enough about the full software development life cycle (SDLC) and infrastructure to get their work done but do not want to become Kubernetes experts. Giving developers a good developer experience relies on understanding the importance of creating an experience that removes friction, fosters innovation and fuels the ability to move faster.

    Here are four tips to ensure the developer experience is not your Achilles heel in fueling business performance:

    Share the Why: Don’t just tell developers how to do something. Explain why they’re doing it. Storytelling and making the ‘why’ matter play an often hidden but important role in undoing developer frustration and, hopefully, avoiding it altogether.

    With the pressure to do more with less, ensuring that developers understand the reasons behind their actions and activities is key to relieving their frustrations and getting to safer, faster deliveries that underpin business value. Developers don’t like black boxes, and the more you can share upfront about why and how the plan or strategy works, the better the developer experience.

    The 2022 Stack Overflow Developer Survey found that well over half of the developers polled spent more than 30 minutes a day looking for solutions to problems. Not only is this a distraction from core development work and productivity, but it can also account for up to 650+ hours of lost time per week (in a team of 50 developers). Informing developers about the ‘why’ from the start—and then arming them with the right tools—can alleviate both developer and business challenges.

    Reduce Friction and Preserve Existing Workflows: Developers want to focus on what they do best—writing code. They don’t want to be hunting down answers to problems created by a growing list of complex technologies, processes and tooling that impact their ability to write and ship software fast. Most developers don’t want to think about selecting or having to use a variety of different (or new tools) to support their work.

    Clear the path for developers. Find infrastructure that puts your developers in the driver’s seat and allows them to continue using the toolchains they already know and love and the power to pick and choose which capabilities best support their requirements for fast, scalable app delivery.

    Foster Team Collaboration and Communication: Faster, safer development is not just about developer experience, but includes the experience of the entire development team and its ability to collaborate. The entire DevOps team plays a critical role in getting software out the door. Site reliability engineers (SREs), for example, play a key role in guiding developers through the cloud-native learning curve to use platforms and ecosystems effectively. It’s more than firefighting—it is a trusted partner to create success in deploying, releasing and running services.

    Encourage developers to share pain points and learn about tools and best practices from the SRE team. Rethink communication patterns to unify developer and SRE approaches to problem-solving, i.e., remove the “this is a developer problem” or “this is an SRE problem” to reframe them as “this is a business problem” and shared responsibility.

    Let Developer Voices be Heard: Empathy cushions every good developer experience. This includes listening to and understanding the needs and wants of developers. Offering more training, having a robust onboarding experience, focusing on reducing cognitive load and having an ongoing dialog with developers shows empathy and reinforces your commitment to supporting developer skill sets and roles within the organization.

    Organizations that empathize with their developers can eliminate friction and fuel a more collaborative, supportive onboarding experience that allows developers to provide input as they progress in their journey. Continuing that empathy throughout a developer’s time at an organization fosters an overarching culture of communication, collaboration and empathy.

    Additionally, institute measurable and realistic key performance indicators (KPIs) as this will help organizations quantitatively understand the developer experiences and identify areas for improvement and celebration.

    Many organizations that go cloud native to improve development speed and shipping frequency end up in a situation where they ask themselves, “Why is it taking hours to do what we used to do in minutes?” Here it is essential to return to the core question about developer experience. If developers are struggling with hours of repetitive, non-core work, a clear path is not paved for them. If they never got a solid onboarding, there’s no shared development environment, friction is everywhere and lines of communication are closed, it’s inevitable that the developer experience will suffer—and by extension, so will the business.

    How you respond to the needs of the developer and the developer experience can make or break your business. Invest in the developer experience. It’s critical to fueling developer productivity and supporting a faster time-to-market for your business.

  • Key Insights From the Stack Overflow 2023 Developer Survey

    Key Insights From the Stack Overflow 2023 Developer Survey

    Stack Overflow has released its seminal yearly developer survey. The 2023 report, which surveyed over 90,000 developers, provides a comprehensive view of the current software developer experience.

    Below, I’ll highlight a few important findings, namely the significant programming language and tooling preferences, the use of AI in the development workflow and what these trends could mean for the DevOps field. I also gathered insights from Joy Liuzzo, vice president of product marketing at Stack Overflow, to dive deeper into some of the findings.

    Developer Technology Preferences in 2023

    Of note is that more and more developers are learning to code online. Learning to code using online resources increased from 70% in 2022 to 80% in 2023. Although many developers (47%) still have a Bachelor’s degree in computer science or the equivalent, these trends underscore the movement toward alternative knowledge solutions, especially for younger programmers. The topmost online resources include technical documentation, blogs, forums and how-to videos.

    JavaScript is still king—it’s now in its eleventh year as the most common programming language. But it’s worth highlighting that Python has overtaken SQL as the third top language. “SQL was solidly in the top three (JavaScript, HTML/CSS, SQL) since 2015, so it’s a big deal for it to have fallen below Python,” said Liuzzo. “We’ve seen Python’s popularity increase based on the number of questions asked on our public site, so we’ve been expecting some shifts.”

    TypeScript and Bash/Shell have also consistently grown in usage over the last few years. “These two languages are involved with the functions of other popular programming languages, explaining their prevalence among programmers,” Liuzzo said.

    PostgreSQL also overtook MySQL as the most common database type. In terms of web frameworks, Node.js and React.js are the most dominant. Other frameworks, like jQuery and ASP.NET, are showing signs of going out of style, likely because they are older web frameworks.

    Spotlight on AI

    The explosion of new AI innovations, such as large language models (LLMs) and chat-driven generative AI tools, had a major impact on this year’s technology findings. In fact, 83% of respondents have used ChatGPT over the past year. This is followed by Bing AI (20.6%), WolframAlpha (13.36%) and Google Bard AI (9.86%). GitHub Copilot was ranked as the top most-used AI developer tool.

    There was a significant spike in using AI tools amongst those learning to code—these folks often see benefits like speeding up learning, increasing productivity and greater efficiency. “Pair this with how they are currently using AI tools to debug and get help (68%) and learn about a codebase (50%), and we see that the commonality is that AI tools enable learning,” explained Liuzzo.

    That being said, there’s skepticism around AI’s accuracy, and only 13% see improved accuracy in coding as a benefit of using such tools. These pain points may resolve as LLMs evolve, but for now, there still needs to be human judgment to catch bugs and avoid hallucinations.

    “AI has a complexity cliff. Much like Helmsman’s complexity cliff found in project management, after a certain point, the ability for AI to handle all the nuances and interdependencies of a solution drops off,” said Liuzzo. “That’s when humans, their ability to apply judgment and have original thoughts, saves the day.”

    So what are some takeaways for those working in the DevOps field, namely DevOps tooling providers and platform engineers? Well, new tooling preferences and habits will continue to evolve in the DevOps field in new ways. Here are some potential examples:

    • More Markdown-based collaboration. Markdown is the most admired asynchronous tool and has increased in popularity this year. New programmers are adopting a blend of Markdown, GitHub Discussions and Notion for their asynchronous tooling. Flavors of Markdown are already being used for comments, merge requests, issues and more.
    • Continued Docker reliance. Docker remains the top-used tool, followed by npm and Pip. Despite the rise of managed container services, Docker is still a popular way to package and distribute software.
    • Challengers to the big three loom in the distance. Amazon Web Services (AWS) is still the most-used cloud platform at 48.62%. It’s followed by Microsoft Azure (26.03%) and Google Cloud (23.86%). Yet, newer developers want to work more with Hetzner and Vercel.
    • Online learning is paramount to knowledge sharing. Given the steady increase in new programmers and their reliance on online resources rather than traditional schooling, DevOps and open source communities should seek to enhance their online footprint by making knowledge like tooling documentation and tutorials easily consumable.

    Last but not least, generative AI is set to enhance programming in many areas and is already becoming embedded into many environments. Just as AI can be used for code generation and debugging, LLMs will likely assist the DevOps side of the equation, helping automate the CI/CD pipeline, optimize infrastructure, detect anomalies and provide more chat interfaces to initiate these capabilities.

    “AI tools are empowering and enabling learning,” said Liuzzo. “Generative AI will democratize coding and grow the developer community by several folds—and that growing number of developers will be the ones using the tools and also verifying and validating the outputs as they learn—bringing the power of the developer community and the technological power of AI together.”

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

    LinkedIn

    Harris Allied
    New York, New York
    DevOps Engineer
    $160,000 to $175,000

    CareerBuilder.com

    MassMutual Financial Group
    Remote
    DevOps/Kubernetes Cloud Infrastructure Engineer

    $137,800 to $180,800

    Indeed.com

    Lawrence Livermore Labs
    Livermore, California
    DevOps Engineer
    $123,960 to $159,168

    SimplyHired.com

    CVS Health
    Remote
    DevOps Engineer
    $90,000 to $180,000

    Dice.com

    Idea Entity
    Herndon, Virginia
    Azure DevOps Engineer
    $80,000 to $100,000

  • How to Keep Your IT Infrastructure Invisible

    How to Keep Your IT Infrastructure Invisible

    IT infrastructure is critical. IT infrastructure enables businesses to run—from day-to-day operational execution to visionary strategic innovation and everything in between. What’s interesting, though, is that people are only aware of it when there’s a problem: HR can’t access the payroll application, customers are complaining about how slow the transactional system is or this month’s cloud bill was double what you expected it to be.

    No one should notice a well-orchestrated environment, but once application performance slows or an outage occurs, people start to grumble. The same is true for IT infrastructure.

    The Top Four Ways Your IT Infrastructure Can Become Undesirably Visible

    Given the complexity of modern hybrid/multi-cloud environments and the applications they support, it’s no surprise that countless things can go wrong—and when they do, your IT team takes the flack.

    If your infrastructure is humming along nicely, that’s a testament to the IT infrastructure team’s hard work and expertise. Sadly, they don’t get the recognition because it’s all invisible to the rest of the organization. It’s only when *BAM!* something happens that the team is scrutinized.

    While there are many ways this can manifest, it usually falls under one of the following four categories:

    • Availability — This may be the most catastrophic because when systems are unavailable, people can’t do whatever it is they need to do.
    • Performance — A system might be available, but that doesn’t mean it’s performing to SLA or user expectations. The result can range from minor annoyance to lost revenue and customer churn.
    • Cost — Runaway expenditures don’t necessarily affect users, but you do not want to be called to account by the finance team or, worse, executive leadership.
    • Compliance — This is another area that may not have a broad impact on user experience, but the repercussions of non-compliance can be financially and reputationally significant.

    Common Infrastructure Culprits and How to Address Them

    To ensure the necessary availability, performance, cost control and compliance to keep your IT infrastructure under the radar, you must understand what can cause problems in these areas. Here are eight common culprits, along with ways you can address them, so your IT team stays invisible.

    Broken or Misunderstood Dependencies
    Your infrastructure is a complex web of interdependent applications and services. Every time you make a change, it could have a rippling effect on the categories mentioned above. Automated discovery and service mapping capabilities enable you to easily trace dependencies throughout your infrastructure to avoid unintended consequences.

    Cloud Waste
    Chances are very high that you’ve got cloud waste. This means that you could be getting billed for a storage block that’s attached to a stopped instance, for compute instances that are not being used, or for unattached load balancers. Finding idle and abandoned resources can keep your monthly cloud bill under control and on budget.

    Un-Breakdownable Cloud Costs
    Cloud bills are notoriously complex, and while cloud providers do offer tools to help you analyze your cloud spend, those tools often don’t answer all the questions your business might have. In addition to adding clarity to such opaque expenses, you need to be able to parse your cloud spend based on what makes business sense to your organization, not what makes technical sense to your cloud provider.

    Poor Capacity Planning
    Your infrastructure needs to meet your business needs, which are continuously evolving. As changes happen, whether it’s increased utilization of existing resources or modified/added resources to support new requirements, workloads could push current capacity and impact performance and stability. You need to be able to forecast infrastructure demands against business objectives to minimize potential issues before they happen.

    Poor Workload Placement Decisions
    Your infrastructure consists of various environments each with its own characteristics. If you migrate a workload without understanding the implications of that particular environment, you could risk performance problems or spiking costs. To prevent this, you need any-to-any migration insights to make better decisions about workload priorities, groups and deployments.

    Poor Reservation Planning
    Reservations (i.e., reserved instances or programmatic discounts) offer discounts for committing to a particular plan. If you plan well, the savings can be significant. But if you don’t use the capacity you’ve bought, the savings might not materialize. To improve cloud resource planning, you need to be able to evaluate your potential savings in varied scenarios.

    Workload Drift
    Over time, your workloads evolve due to changing demand, data volumes, etc. As a result, they can outgrow their current configurations, leading to performance issues or rising costs. This is a natural result of business growth, so the goal isn’t to prevent that drift. Instead, you want to optimize capacity and cost on an ongoing basis to keep your workloads right-sized.

    Slow Problem Troubleshooting and Remediation
    No matter how many precautions you take, something somewhere will inevitably go wrong. And once you become aware of the situation, the clock starts ticking to find the cause and fix it, all of which takes time. The longer the entire process takes, the longer your infrastructure will be visibly and painfully not working as expected. For those cases, you need full-stack visibility with application-centric, AI-based analytics to minimize impact duration as much as possible.

    Keeping the engine running behind the curtain can be a daunting task, but with proper planning and management, your IT team will remain visible to those responsible for managing it and invisible to those in the rest of the organization. Of course, the complexity of today’s cloud infrastructure makes that challenging, and there will be IT fire drills that take place, but it’s about how IT leaders react to the situation and resolve it in the quickest way possible, allowing themselves to return to their preferred place in the shadows.

  • Threads: Twitter Killer or Ad-Infested Hellscape?

    Threads: Twitter Killer or Ad-Infested Hellscape?

    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: Meta launches its much-leaked Threads microblogging app. A spinoff from Instagram, it’s already reached 30 million signups at the time of writing—even before it’s available in the EU. But how is Meta’s DevOps team making it scale? (more…)