devopsy.kinsta.cloud

Category: Blogs

Snyk Acquires Helios to Extend Reach of ASPM Platform

With its acquisition of Helios, Snyk plans to add an ability to capture application runtime data to extend the capabilities of its application security posture management (ASPM) platform.

Manoj Nair, chief product officer for Snyk, said Snyk AppRisk will soon provide real-time insights into runtime environments using a Helios observability platform that provides them with deeper insights into issues that need to be resolved. That capability will provide developers with additional context as more responsibility for application security continues to shift left toward application development teams, he added.

Armed with that insight, it then becomes simpler to prioritize remediation efforts based on the level of risk a vulnerability actually represents to the organization, said Nair. That’s critical to close a longstanding divide between cybersecurity and application development teams that, in the absence of any real ability to determine the severity of a vulnerability, results in developers wasting what limited time they have to allocate to remediation, he noted.

Nair said the overall goal is to enable organizations to deploy more secure applications while minimizing adverse impacts on developer productivity.

Snyk last year acquired Enso Security to add an ASPM platform to its portfolio that serves as the foundation upon which Snyk AppRisk was built. It also includes Insights, a Snyk tool that makes use of multiple types of artificial intelligence (AI) models to identify, prioritize and fix vulnerabilities.

There’s often not a lot of love lost between cybersecurity teams and application developers who typically don’t have a lot of cybersecurity expertise. Most of the issues that cybersecurity teams are tasked to address start with mistakes made by developers that cybersecurity teams then need to convince developers to allocate time to fix.

Thanks to the rise of DevSecOps best practices, the overall security of software supply chains is improving, but there is still a long way to go before application security truly improves. The one thing that is certain is the level of accountability for vulnerabilities is only going to rise as more stringent regulations go into effect in the months and years ahead.

In the meantime, DevSecOps teams should assume there will be many more vulnerabilities to remediate. Developers are increasingly using generative AI tools to write code. The challenge is general-purpose large language models (LLMs), such as the one used to drive ChatGPT, were trained using examples of code of varying quality collected from across the web. A lot of the code these platforms generate, not surprisingly, contains vulnerabilities that many developers will not immediately recognize without the aid of some type of scanning tool.

At the same time, cybercriminals are becoming more efficient at discovering and exploiting vulnerabilities that exist in applications that have already been deployed in production environments. DevSecOps teams should expect that, as a result, more zero-day vulnerabilities requiring immediate attention will soon be discovered.

One way or another, the percentage of time allocated to application security issues is only going to increase. The only thing left to determine is how best to go about reducing the time and effort needed to make applications as secure as possible.

January 29, 2024
Can Improving Developer Experience Actually Reduce Costs?

From platform engineering to AI, many new DevOps initiatives aim to improve internal developer experience (DX). Developer experience is essentially like user experience but considers the experience a developer has with a framework or tool. The promise is that quality DX creates a more satisfied workforce, reducing burnout and avoiding employee churn. But can improving developer experience also reduce costs?

I took to LinkedIn with this question, and the response was a resounding “yes.” In today’s lean tech climate, you might think that making the case to invest in employee satisfaction is a tough sell. But, it turns out that developer experience has significant ripple effects that benefit the business in diverse ways, making it a lucrative opportunity for technical leadership.

Developer experience contributes to outcomes like better efficiency, easier onboarding, less re-engineering, reduced overhead and more, which all — indirectly, granted — can reduce costs. Below, I’ll outline some of the ways developer experience can affect the bottom line, featuring viewpoints from various sources across the field of tech.

Improved Efficiency = Dollar Savings

The most obvious impact of enhancing developer experience is that improved efficiency can equate to dollar savings. For a concrete example, consider an API that provides useful error code responses and explains them within a developer portal. This saves developers time and money, said Brandon Boyd, product manager at Tekion. “Otherwise, they will have to guess about error codes and implement improper code, which requires rework,” he said.

With solid DevOps practices, a release that might have taken three months with manual processes could take a single sprint, said Anna Daugherty, director of product marketing, Opsera. “This leads to expensive development time saved while simultaneously getting the release to market faster to improve customer satisfaction and reduce churn,” she said.

Better Cycle Times Reduce Cost

Reduced friction can also lead to reduced cost. Specifically, better developer experience around areas like provisioning, scaling, and security can help things run more smoothly, equating to development and tooling efficiency, added Daugherty. “Taking out the guesswork and human error from development can save money on infrastructure, redundant tool costs and time costs,” she said.

Improving developer workflows, a practice some call developer productivity engineering, can have tangible outcomes that reduce costs. “Developers need flexibility and support from the right technology stack to be successful and deliver on quality work for overall business success,” said Dana Lawson, senior vice president of engineering, Netlify. “Investing in a cohesive workflow using composable web architecture streamlines processes to enable developers to focus on the higher-level thinking their projects need, and therefore cut time and budget spent on busywork.”

Good developer experiences also have minimal context switching, which can further reduce cycle time. “Forcing developers to toggle between various screens, applications, and docs inhibits deep work and focus and directly impacts how long projects can take and even the quality of the work,” said Isaac Nassimi, SVP of product, Nylas. Removing friction in the developer workflow can help launch projects faster, “creating longer revenue-generating timelines and opportunities,” he said.

Less Turnover and Onboarding

Developer turnover and onboarding can be expensive. LinkedIn reports that for each employee lost, the cost to the company could be up to 250% of their annual salary. Better internal developer experience can improve employee retention, which saves significant expenses. “It costs to hire a developer, and it costs to bring a new one up to speed,” said Andrew Cornwall, senior analyst, Forrester. “Happier developers are less likely to leave.”

But instilling a good reputation amongst developers has other side-benefits, Cornwall explained, such as attracting more first-tier, productive engineers. Developer retention also leads to better familiarity with the code, aiding debugging efforts and reducing human error. “Happy developers who have been there for a while start to understand what the goals of the team and the business actually are,” he said. “They can align what they do to satisfy a greater outcome.”

Reduced Overhead For Support

Another outcome for software products with good developer experience is that they are more self-service, meaning developers are more empowered to find the information they require to do their work. This, in turn, lowers the need for manual support and reduces labor costs.

Daan Stolk, co-founder, Alphadoc.io, recounted how his team at a previous company tracked whether support tickets could have been prevented with the right information architecture up front. He estimated that over 50% of cases could have been solved with the proper documentation and resources. As you can imagine, this finding led to a big overhaul of their developer support materials. “Ultimately, this resulted in customers not having to wait for responses to their questions and becoming more self-sufficient,” he said.

Less Re-Engineering

Developers make up an increasingly high expense on the balance sheet, and forcing them to re-engineer code is wasteful. One way to avoid re-engineering is to have better practices around reusable interfaces. For instance, GraphQL is proving to be a helpful layer to aggregate disparate data sources and federate a graph across an organization, making data retrieval more efficient.

“Reduce the time it takes [developers] to do recurring tasks by 30% or 40%, and you are talking about millions of dollars in savings annually,” said George Snowflack, director of central U.S. & LATAM, Apollo GraphQL. “This is why so many of the Fortune 500 have moved to a federated GraphQL architecture, because of its ability to compose a modern data access layer just one time, and then reuse it infinitely across any apps or clients on the front end.”

More Accountability and Responsibility

When employee needs are respected, they tend to feel more kinship with their internal community and take on additional accountability for their actions. “When a company’s developer experience promotes developer ownership, developers are more likely to take responsibility for their cloud environments, including cost optimization,” said Brandon Turner, VP of engineering, Kion. “Developers that feel empowered are much more willing to take accountability for their actions, including optimizing costs.”

Access to a Wider Talent Pool

When software is more usable, more people can participate, thus lowering the barrier to access and reducing the need for high-cost resources. “For some, this could include analysts moving into the developer role creating new efficiencies,” said Rob Koplowitz, former vice president, principal analyst, Forrester. “For the more intrepid, it could enable business developers that could change the paradigm significantly,” he said. However, a citizen developer culture must involve the proper controls around areas like change management, governance, and guardrails.

Furthermore, internal education costs are reduced with good developer experience. “The cost-savings value of prioritizing the developer experience is that companies do not have to make investments in continued education or hiring new individuals to help build upon new skills,” said Neil Kanungo, VP, product-led growth, KX. “Conducting in-person or costly training exercises can be viewed as an expansion if organizations have the time and budget, rather than a necessity.”

So, How Do We Get There?

It’s clear that improving DX can reduce expenses, especially regarding reduced labor costs. But how do you go about building out experiences that developers love? Well, it’s important for technical leadership to clearly understand what positive developer experience improvements actually look like. “These improvements should include introducing self-service mechanisms, removing friction, making educational training simplified and more accessible, and providing free access to community resources and support,” said Kanungo.

Lastly, leaders shouldn’t expect developers to optimize their costs without the proper support. Instead, cost savings will hinge on giving developers more visibility into their applications, especially for complex shared cloud environments. “If a development team can’t tell what cost inefficiencies are related to their application, they are less likely to optimize those costs,” said Kion’s Turner. “Simplifying the developer experience by giving development teams isolated environments that they own promotes responsibility for the health of those environments,” he added.

Furthermore, helpful tools will be required to move developer experience initiatives forward. Jon Peck, senior manager, developer relations and enterprise advocacy at GitHub, explained how DevOps practices, such as AI pair programmers, cloud IDEs, automation, asynchronous communication formats and shift-left security tools can work together to improve developer experience and indirectly bring cost-savings. The latter, developer-first security, could have real tangible monetary benefits since fewer vulnerabilities in production means fewer costly security incidents.

Lastly, as leaders seek to optimize their IT departments, much thought has been placed on ways to measure software developer productivity lately. Yet, most savvy executives view this as a red herring. While taking account of some development metrics is helpful, relying too heavily on minute analytics, such as individual commits or bug fixes, can negatively affect developer experience.

Final Thoughts: Good DX = Less Humanpower = Cost Savings

The most obvious outcome of improved developer experience is that less energy and time are expended. Developer cost per hour doesn’t have as much of an economic impact. This impact is apparent in both bustling and lean economies. “In times of expansion, improved developer experience can improve new-hire onboarding costs,” said Kevin Swiber, API strategy lead at Postman. “In times of contraction, developer experience can help improve cycle times as folks do more with less.”

It’s also evident that developer experience is especially important for API-first strategies. Better usability around API gateway management, for example, can increase simplicity and enable teams to allocate resources elsewhere, explained Abdallah Abedraba, developer relations, Zuplo. Mark Rovetta, senior programming writer at F5 Networks, also added that improving the quality of API documentation can reduce costs substantially since it enables deployment fluidity and aids learnability.

So, with all that said, listen to your developers and their needs. You might learn a thing or two. And save a buck or two.

January 29, 2024
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:

SimplyHired.com

D2 Consulting
Springfield, Virginia
DevOps Engineer
$150,000 to $180,000

Indeed.com

Mariner Finance
Remote
DevOps Engineer
$120,000 to $150,000

ZipRecruiter

Cogility Software
Irvine, California
DevOps Engineer
$110,000 to $140,000

CareerBuilder.com

BAE Systems
Manassas, Virginia
DevOps Engineer
$92,290 to $156,860

Dice.com

Rackner
Falls Church, Virginia
Software DevOps Engineer
$90,000 to $140,000

January 29, 2024
Pretense and Pretending

January 29, 2024
5 Serverless Challenges of DevOps Teams and How to Overcome Them

Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation of machine resources. The term ‘serverless’ might be somewhat misleading as it doesn’t mean servers are not involved. Instead, it means that developers no longer have to think about servers, even though they’re running on them.

The idea is to abstract the infrastructure away so that developers can focus solely on the code. Functions, the units of code, are triggered by a variety of events, including HTTP requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (cron jobs), and user sign-ups or in-app activities.

The Importance of Serverless for DevOps Teams

Serverless computing brings a paradigm shift in how applications are built, deployed and managed, directly impacting DevOps teams. The core advantage of serverless for these teams is the significant reduction in operational overhead. With serverless, the cloud provider takes responsibility for running the server, ensuring its reliability, and scaling the infrastructure. This frees DevOps teams from the routine tasks of server provisioning, maintenance, and patching, allowing them to focus more on optimizing the application’s code and business logic.

However, this shift also demands a change in mindset and approach. DevOps teams must adapt to a more granular, event-driven architecture that serverless promotes. They need to design systems thinking about individual functions and how they interact, instead of traditional monolithic applications or even microservices. This requires a deeper understanding of the cloud environment and its services, as serverless functions are often tightly integrated with other cloud services like databases, message queues, and API gateways.

Moreover, serverless computing introduces new challenges in areas like security, monitoring, and cost management. For instance, the ephemeral nature of serverless functions can make traditional monitoring approaches less effective, and the dynamic scaling can lead to unpredictable costs. DevOps teams need to develop new strategies and adopt specialized tools to address these challenges. Despite these issues, the benefits of serverless – in terms of agility, scalability, and potential cost savings – make it an increasingly essential tool in the DevOps arsenal, particularly for organizations looking to innovate and deploy rapidly in a cloud-centric world.

5 Serverless Challenges of DevOps Teams and How to Overcome Them

1. Complexity of Monitoring in Serverless

A main challenge in the serverless world is the complexity of monitoring. Unlike traditional architectures where you can monitor physical or virtual servers, in serverless, you need to monitor individual functions. This can be tricky as you may have hundreds or even thousands of functions running simultaneously.

To effectively monitor serverless architectures, you need to go beyond traditional methods. You need tools that can provide insights at the function level, such as AWS CloudWatch or Azure Monitor. These tools allow you to monitor metrics like execution time, error rates, and invocation counts for each of your functions.

But monitoring is not just about gathering metrics. It’s also about understanding the relationships between your functions and other components of your system. For this, you need distributed tracing tools like AWS X-Ray or OpenTelemetry, which can provide a detailed view of how requests flow through your system.

2. Managing Lambda Cold Starts

One of the most common serverless challenges that DevOps teams face is cold starts. A “cold start” refers to the delay that occurs when a function is invoked after being idle for a while. This delay can significantly impact the performance of your applications, especially those that rely on real-time processing.

The first step to managing Lambda cold starts is understanding what triggers them. Typically, a cold start happens when a new instance of your function is created, which can be due to several reasons, such as an increase in traffic, the deployment of a new version of your function or after a function has been idle for too long.

To overcome this challenge, there are several strategies you can employ. First, you can use provisioned concurrency, a feature offered by AWS Lambda that allows you to keep a specified number of function instances warm and ready to respond to invocations. Another strategy is to design your applications to be resilient to cold starts by implementing retry logic or using asynchronous invocation when possible.

3. Security Concerns in Serverless Architectures

Security is a top concern for any DevOps team. In serverless architectures, you have less control over the underlying infrastructure, making it more difficult to ensure the security of your applications.

The first step to securing your serverless applications is understanding the shared responsibility model. In a serverless environment, the cloud provider is responsible for securing the infrastructure, while you are responsible for securing your code and configurations. This means you need to pay extra attention to things like input validation, error handling and secure configuration practices.

Another key aspect of serverless security is managing permissions. Each of your functions should have the least privileges necessary to perform its task. This can be achieved by using identity and access management (IAM) services provided by your cloud provider.

4. Managing Third-Party Dependencies

Managing third-party dependencies is another challenge that DevOps teams often face in serverless architectures. These dependencies can introduce vulnerabilities into your applications, affect the performance of your functions, and even increase the cost of your serverless deployments.

The key to managing third-party dependencies is to minimize their use. Only use dependencies that are necessary for your application and regularly review them to ensure they are still needed. You should also keep your dependencies up-to-date to benefit from the latest security patches and improvements.

When using third-party dependencies, it’s also important to understand their impact on your functions. You can use tools like AWS X-Ray or Google Cloud Trace to monitor how these dependencies affect the performance of your functions.

5. Cost Management and Optimization

While serverless can be cost-effective, it’s easy to rack up high bills if you’re not careful. This is because in serverless, you pay for every invocation of your functions, even if they result in errors.

To manage costs in serverless, you need to monitor your usage closely. Tools like AWS Cost Explorer or Google Cloud Billing can provide insights into your spending and help you identify areas for optimization.

You can also optimize costs by designing efficient functions. This means writing code that executes quickly and efficiently, minimizing the use of third-party dependencies, and managing the concurrency of your functions.

In conclusion, while serverless technologies offer many benefits, they also present unique challenges for DevOps teams. By understanding these challenges and employing the right strategies, you can effectively manage and overcome them, ensuring the successful delivery of your serverless applications.

January 26, 2024
SmartBear Acquires Reflect to Gain Generative AI-Based Testing Tool

SmartBear this week revealed it has acquired Reflect, a provider of a no-code testing platform for web applications that leverages generative artificial intelligence to create and execute tests.

Madhup Mishra, senior vice president of product marketing at SmartBear, said the platform Reflect created will initially be incorporated into the company’s existing Test Hub platform before Reflect’s generative AI capabilities are added to other platforms.

Reflect provides access to a natural language interface to create tests using multiple large language models (LLMs) that it is designed to invoke. It can also understand the intent of a test to understand what elements to test regardless of whether, for example, a button has been moved from one part of a user interface to another, said Mishra. Test step definitions, once approved, can also be automatically executed using scripts generated by the platform.

SmartBear has no plans to build its own LLMs, said Mishra. Rather, the company is focusing its efforts on providing the tools and prompt engineering techniques needed to effectively operationalize them, he added.

Reflect is the tenth acquisition SmartBear has made as part of an effort to provide lightweight hubs to address testing, the building of application programming interfaces (APIs) and analysis of application performance and user experience. Last year, the company acquired Stoplight to gain API governance capabilities.

Rather than building a single integrated platform, the company is focused on providing access to lightweight hubs that are simpler to invoke, deploy and maintain, said Mishra. The overall goal is to meet IT teams where they are versus requiring them to adopt any entirely new monolithic platform that requires organizations to rip and replace every tool they already have in place, he said.

There is little doubt at this point that generative AI will have a profound impact on application testing in a way that should ultimately improve the quality of the applications. As the time required to create tests drops, more tests will be run. Today, it’s all too common for tests not to be conducted as thoroughly as they should be simply because either a developer lacked the expertise to create one or, with a delivery deadline looming, they simply ran out of time.

Naturally, the rise of generative AI will also change how testing processes are managed. It’s not clear how far left generative AI will push responsibility for testing applications, but as more tests are created and run, they will need to be integrated into DevOps workflows.

Of course, testing is only one element of a DevOps workflow that is about to be transformed by generative AI. DevOps teams should already be identifying manual tasks that can be automated using generative AI as part of an effort to further automate workflows that, despite commitments to automation, still require too much time to execute and manage. Once identified, DevOps teams can then get a head start on redefining roles and responsibilities as generative AI is increasingly operationalized across those workflows.

January 26, 2024
Diffblue Integrates Generative AI-Based Testing Platform With GitLab

Diffblue this week generally made available an integration between its automated unit testing platform for Java and the DevSecOps platform from GitLab.

The Diffblue Cover platform makes use of generative artificial intelligence (AI) to automatically create unit tests based on reinforcement learning technologies that don’t rely on LLMs—avoiding their drawbacks of sometimes introducing hallucinations and also requiring human review.

Diffblue CEO Mathew Lodge said the integration with the continuous integration capabilities found in the premium and ultimate editions of the GitLab platform would, for example, streamline regression testing in a way that should ultimately improve both application quality and security. Diffblue Cover, for example, can update tests as much as 250 times faster than a human developer can write them manually without developer review.

That approach also serves to reduce the level of friction many DevSecOps teams encounter when bottlenecks involving testing processes emerge, noted Lodge. The overall goal is to make it simpler for developers to test as much of their own code as possible before integrating it into a build, he added. Otherwise, developers will get fed up because testing is continuously breaking the build, noted Lodge.

Ultimately, instead of having to write unit tests, developers become supervisors of a platform that automatically generates them on their behalf, said Lodge. The job of a developer doesn’t go away, but it does fundamentally change, he added.

To achieve that goal, developers need to be able to access a platform that writes the tests and can then also execute them automatically. If it takes too long to create the test, chances are high that most developers won’t run it. On average, writing and evaluating a single unit test can take a developer 10 minutes. Over the course of any project, thousands of tests need to be written, so the amount of time testing takes away from coding is often much greater than most IT leaders fully appreciate.

Automating those tests should improve developer productivity as more time is available to focus on writing code rather than testing. That doesn’t necessarily eliminate the need for a dedicated testing team, but it does mean that more tests will be run without slowing down the overall pace of application development.

Developers naturally want to be able to test code at the very instant they create it. AI platforms can make that happen by, for example, employing reinforcement learning to write unit regression tests.

Most developers are not going to resist assuming more responsibility for testing if the tools to automate that task are more accessible. Instead of merely shifting responsibility for testing left toward developers, DevOps teams need to find ways to streamline the process. Otherwise, testing just becomes one in a series of tasks that are being shifted to developers in ways that many of them are coming to resent.

It may take some time before AI is fully integrated into software engineering but it’s clear with each passing day more previously manual tasks are being automated. Among the lowest hanging fruit for applying AI to software engineering are clearly testing processes that, if truth be told, few indeed enjoy conducting.

January 25, 2024
Kubernetes Troubleshooting in GitOps: Dealing with Unexpected Helm Chart Modifications
Quiz #17 was:
You’re working in a GitOps environment where developers use Helm charts to manage Kubernetes deployments. One day, a developer makes a change to a Helm chart to adjust the replica count of a deployment. However, after the change is applied, you notice that the deployment’s pod template has also been unexpectedly modified, leading to errors. Which of the following is the most likely cause of this issue?

1. Version control conflicts
2. Incorrect values file usage
3. Helm version incompatibility
4. Namespace configuration error
5. Insufficient RBAC permissions

Correct Answer: 2) Incorrect values file usage

99 people answered this question with 27% getting it right.

Meta Description: Discover how to tackle Helm chart issues in GitOps environments. Learn about common pitfalls and ﬁnd solutions to keep your Kubernetes deployments error-free.

Are you managing Kubernetes deployments using GitOps and Helm charts? It’s an excellent approach to maintain infrastructure as code and ensure reproducible deployments. However, like any technology, it comes with its challenges. In this blog post, we’ll explore a scenario and guide you through Kubernetes troubleshooting in GitOps, speciﬁcally when unexpected Helm chart modiﬁcations occur.

The Scenario

Imagine a typical day in your GitOps environment. Developers are busy making changes to Helm charts to ﬁne-tune Kubernetes deployments. One day, a developer makes a seemingly innocent adjustment to a Helm chart—changing the replica count of a deployment. But as you apply the change, something unexpected happens. The deployment’s pod template is also modiﬁed, leading to errors and chaos in your cluster.
The Most Likely Cause
The culprit in this scenario is often “Incorrect values ﬁle usage”. Helm charts rely on values ﬁles to customize deployments. When values ﬁles are used incorrectly or contain erroneous values, they can inadvertently modify various aspects of your Helm chart, including the pod template.

How to Tackle It
1. Review Values Files:
Start by thoroughly reviewing the values ﬁles used in your Helm chart. Ensure that the values provided align with the intended changes. It’s crucial to understand how each value affects your deployment.
1. Validate Chart Versions:
Check that you are using the correct Helm chart version. Helm chart versions can evolve, and using an incompatible version may lead to unexpected behavior. Maintaining a well-documented Helm chart repository helps.
1. Test Changes Locally:
  Before applying changes to your live environment, consider testing them in a development or staging cluster. This allows you to catch issues early and prevent unexpected modiﬁcations.
  1. Collaborate with Developers:
  Encourage close collaboration between developers and operations teams. Clear communication about changes and their potential impact is essential. Developers should provide detailed documentation for values ﬁles.
  1. Implement Access Controls:
  Utilize Kubernetes Role-Based Access Control (RBAC) to restrict who can make Helm chart modiﬁcations and deployments. This helps prevent unauthorized or inadvertent changes.
  
  Conclusion
  
  In the world of GitOps and Kubernetes, troubleshooting unexpected Helm chart modiﬁcations is a part of the journey. By understanding the most likely causes and following best practices, you can mitigate issues and maintain the integrity of your deployments.
  
  Remember, Kubernetes troubleshooting in GitOps is not just about ﬁxing problems; it’s about preventing them in the ﬁrst place. Embrace a proactive approach to ensure that your Kubernetes environment remains error-free and eﬃcient.
  
  But when things do go wrong, issues like these can be time consuming to debug increasing downtime. In the last quiz we looked at a similar issue where, at times, it is essential to bypass best practices to address an urgent issue. When this happens, and it invariably does, Webb.ai leverages AI to automate troubleshooting to reduce downtime and make SRE and DevOps more productive. Similar to how Github Copilot is automating software development and making developers more productive, Webb.ai is automating troubleshooting to make Ops more productive! The goal should be for the machines to do the repetitive stuff so that we humans can think about the more fun and creative stuff!
  
  Ready to streamline your GitOps and Kubernetes troubleshooting efforts? Participate in our Early Access Program.
January 25, 2024
New Relic Adds Ability to Correlate IT Events to Business Processes

New Relic this week added an ability to enable DevOps teams to better understand the potential business impact any change to an IT environment might have.

Manav Khurana, chief product officer for New Relic, said New Relic Pathpoint adds a dashboard to the company’s observability platform through which business metrics can be collected alongside telemetry data. That data is collected either via connectors provided by New Relic or via a metrics application programming interface (API) that IT teams can invoke.

IT teams can use that API to connect to custom applications or an end-to-end business process, noted Khurana.

All that data is then modeled alongside DevOps telemetry data to provide insights into the impact any change might have on the business in real-time, he added. That approach provides the added benefit of making it easier to strategically align the management of applications, services and infrastructure by business function, noted Khurana.

In the near future, New Relic will also extend the natural language capabilities it is currently previewing to New Relic Pathpoint, he said.

Longer term, New Relic is working toward making it possible to model how proposed changes to business processes will impact IT environments, added Khurana.

Business and IT leaders intuitively understand that every business event creates a corresponding IT event, but most organizations manage those processes in isolation. New Relic Pathpoint presents an opportunity to close a divide between IT teams and the rest of the business that has plagued organizations for decades.

It may be a while before advances in data analytics and AI eliminate that divide completely, but creating a common set of metrics for managing business and IT processes is a crucial first step.

In the meantime, DevOps teams, in addition to accelerating the pace at which applications can be built and deployed, are being asked to employ observability platforms such as New Relic One to minimize disruption to the business. Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications using open source agent software, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate IT and business events.

It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of predefined but often conflicting metrics. Observability platforms, however, unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue, hopefully before any catastrophic disruption can occur.

January 25, 2024
5 Security Threats DevOps Teams Should Know

DevOps security, also known as DevSecOps, is a philosophy in which security practices are integrated into the DevOps process. DevOps security involves creating a ‘security-as-code’ culture with ongoing, flexible collaboration between release engineers and security teams. The DevSecOps movement, much like DevOps itself, is focused on creating new solutions for complex software development processes within an agile framework.

DevOps security is about breaking down silos and promoting open collaboration across teams. It’s about making everyone accountable for security with the ultimate aim of improving the quality and speed of code releases. The adoption of a DevOps security model necessitates a cultural shift across the organization. It requires the integration of security into every aspect of the development and operations processes.

DevOps Security is not just about implementing tools and technologies; it’s about changing the way we look at security. Rather than being an afterthought, security should be a key part of the ongoing conversation from the start of the project to the end.

5 Security Threats DevOps Teams Must Know About

As a DevOps professional, it’s crucial to be aware of the potential threats that could compromise your systems, applications, and data. Let’s take a look at the top five security threats that DevOps teams must be aware of.

Phishing Attacks

Phishing attacks are a common security threat that can lead to data breaches. These attacks involve cybercriminals impersonating legitimate organizations to trick individuals into revealing sensitive information, such as passwords and credit card numbers.

Phishing attacks can be particularly damaging for DevOps teams. They can lead to unauthorized access to development systems and data, which can lead to devastating supply chain attacks. For example, an attacker could trick a team member into revealing their login credentials for a critical system, allowing the attacker to gain access and inject malware into a CI/CD pipeline.

Code Injection

Code injection is another common security threat that DevOps teams must be aware of. This involves the exploitation of an application by injecting malicious code. The attacker can then execute the malicious code to compromise the system or steal sensitive data.

For DevOps teams, code injection attacks can be particularly harmful. These attacks can lead to compromised systems and applications, resulting in data breaches and significant downtime.

Man-in-the-Middle Attacks

Man-in-the-middle attacks are a type of security threat where the attacker intercepts and potentially alters the communication between two parties without their knowledge. This can lead to a range of damaging outcomes, including data theft, session hijacking, and even identity theft.

For DevOps teams, man-in-the-middle attacks can be particularly problematic. These attacks can lead to compromised systems and data, and even the unauthorized alteration of code.

Container Vulnerabilities

Container vulnerabilities are a significant security threat for DevOps teams. Containers are a key technology in the DevOps world, allowing for the rapid and reliable deployment of applications. However, like any technology, they come with their own set of security risks.

These vulnerabilities can range from use of insecure images, to misconfigurations and software bugs, to more serious issues like kernel exploits. If an attacker is able to exploit a container vulnerability, they could potentially gain control over the entire system.

DDoS Attacks

Last but not least, distributed denial-of-service (DDoS) attacks are a significant security threat that DevOps teams must be aware of. These attacks involve overwhelming a production environment with traffic, causing it to become unavailable to users.

For DevOps teams, DDoS attacks can be particularly damaging. Not only can they lead to significant downtime, but they can also result in lost revenue and damage to the organization’s reputation.

How to Mitigate These DevOps Security Threats

While these security threats are concerning, there are effective strategies and techniques that can be used to mitigate them.

Implement Email Security Practices and Tools

To combat phishing attacks, it’s crucial to implement email security tools that can detect and block phishing attempts. These tools can help to filter out phishing emails, reducing the likelihood that team members will fall victim to these attacks.

In addition to implementing email security, it’s also important to provide security awareness training for team members. This training should cover the basics of cybersecurity, including how to recognize and respond to phishing attempts.

Use Input Validation and Sanitization in Applications

To protect against code injection attacks, it’s important to use input validation and sanitization in applications. Input validation involves checking that the data provided by a user meets certain criteria before it’s processed by the application.

Input sanitization, on the other hand, involves cleaning up the data to remove any potentially harmful elements. This can help to prevent malicious code from being executed within the application.

Employ HTTPS and SSL/TLS Encryption for Data in Transit

To guard against man-in-the-middle attacks, it’s important to employ HTTPS and SSL/TLS encryption for data in transit. This ensures that any data being sent between the user and the application is encrypted, making it much more difficult for an attacker to intercept and read the data.

Regularly Scan Containers for Vulnerabilities

To protect against container vulnerabilities, it’s crucial to regularly scan containers for vulnerabilities. This involves using tools that can analyze the containers and identify any potential security risks.

By regularly scanning containers, DevOps teams can identify and address vulnerabilities before they can be exploited by an attacker.

Implement Rate Limiting and Network Filtering

Finally, to mitigate the risk of DDoS attacks, it’s important to implement rate limiting and network filtering. Rate limiting involves restricting the number of requests that a user can make to the application within a certain period of time.

Network filtering, on the other hand, involves blocking traffic from certain IP addresses or ranges that are known to be associated with DDoS attacks. This can help to reduce the impact of a DDoS attack and protect the availability of the application.

In conclusion, DevOps security is a crucial aspect of the DevOps process. By being aware of potential security threats and taking steps to mitigate them, DevOps teams can significantly reduce the risk of a security breach and ensure the ongoing success of their projects.

January 25, 2024