In today’s rapidly evolving digital landscape, organizations heavily rely on their applications and systems to deliver optimal performance. As such, driving down the key metric of Mean Time to Resolution (MTTR) is clearly one of the biggest challenges facing observability practitioners today.
To watch the webinar, please fill out the form below:
The recent news regarding Red Hat’s decision to limit access to the source code of their Red Hat Enterprise Linux (RHEL) distribution has garnered considerable attention. In order to understand the ramifications and subsequent changes, it is important to look back at CentOS, its historical alignment with RHEL and the options moving forward.
Starting in 2004, right from its inception, every iteration of the commercial RHEL offering triggered a corresponding release of CentOS. These iterations mirrored RHEL, albeit with modifications to eliminate the Red Hat branding and other minor updates. The presence of open source CentOS Linux facilitated swift installation of a free RHEL variant, rendering it accessible for diverse purposes spanning from development to production environments.
In January 2014, Red Hat joined the CentOS project. Under a new CentOS governing board, they became the main sponsor and driver of the CentOS project. They continued to be an open source downstream alternative to RHEL.
On December 8, 2020, the CentOS project and Red Hat set a new end-of-life (EOL) date for CentOS Linux 8. They shifted focus and investment into a new Linux distribution, CentOS Stream, with a rolling release model. EOL means that the community stops releases regardless of the severity of a bug or a vulnerability. Today, CentOS versions 6 and 8 are already EOL, and version 7 is the last, with EOL set for June 30, 2024. This announcement immediately sparked new projects to fill the CentOS gap. New open source projects such as Rocky Linux and AlmaLinux took off quickly, gaining contributors, sponsors and users.
Fast forward to June 21, 2023, when Red Hat announced it would no longer publicly publish RHEL on git.centos.org.
Previously, the source code was accessible to all, and it was used by various RHEL-compatible alternative open source projects such as Rocky Linux and AlmaLinux. It also affected other distributions, including Oracle Linux, which was a RHEL derivative for many years. All of these open source Linux distributions offered an alternative for applications; they were equally compatible with both free open source Linux and the commercial RHEL offering.
According to the 2023 State of Open Source Report, 15% of all organizations and 20% of large organizations globally still have CentOS Linux deployed in their environments. Organizations have to move off EOL CentOS 6 and 8 and, in less than a year, off CentOS 7. Running EOL versions of any software can pose a substantial risk and cause failure in IT internal and external compliance. New vulnerabilities are constantly disclosed, and without updates or patches to CentOS, it is critical to plan for the “Great CentOS Linux Migration.”
Migration can be challenging. If organizations have legacy applications, they might encounter significant challenges making them work properly on a different Linux distribution. Even a small change in the individual packages that form the Linux distribution can impact and delay testing. While every application is different, and many are not dependent on low-level Linux functions, others could be significantly impacted. The number of CentOS deployments and applications has an exponential impact on the migration efforts. Evaluating different Linux distributions also takes time and will depend on the use cases, the skills developers have within each organization and the results of testing. The actual installation of a new Linux distribution is the easy part—the testing of all the layers on top of the operating system is what will take time. Some might be straightforward while others will require significant changes. Those are the reasons why it is helpful to stay with compatible distributions that will minimize the migration challenges.
As organizations navigate the CentOS EOL and the migration period, it will be helpful to find options to extend CentOS long-term support. This means finding the expertise to generate patches that address newly disclosed high-severity vulnerabilities post-EOL. In other words, organizations must expand the community’s long-term support to address security.
The biggest question about alternative distributions is how closely they resemble RHEL. Are they going to continue to be bug-for-bug compatible? Or are there enough differences to no longer consider them application-compatible? The Rocky Linux Enterprise Software Foundation announced its plan to access RHEL source code and its intentions to continue to be bug-for-bug compatible. AlmaLinux OS Foundation announced a different approach. It is working with the CentOS Stream community while maintaining binary compatibility. This means not strictly bug-for-bug but focusing on applications to continue to be compatible.
It is possible we’ll see other potential changes from Red Hat with regard to the access to RHEL’s source code. Today, it’s only available to customers under a commercial license agreement.
The big test will be the next minor version, RHEL 9.3. It will be interesting to review the corresponding 9.3 versions of Rocky Linux, AlmaLinux, Oracle and others, including SUSE, who announced their intention to offer an open source compatible Linux distribution. The analysis and comparison of how applications run with the new minor version will reveal how close they are to RHEL.
To mitigate uneasiness, organizations have to plan and test alternatives. Finding post-EOL support and patches will allow organizations to have a runway for migrating CentOS to different Linux distributions.
As everyone in the industry with CentOS deployments waits for the next release or the next few releases, extending long-term support becomes a very viable solution. It is wise to make sure security and IT compliance aspects are addressed. Perhaps more open source Linux distributions will appear in the near future and offer another alternative to CentOS Linux.
Bringing products to market quickly, efficiently and safely is key to brand success, and elite DevOps teams minimize the lead time for changes by quickly and efficiently moving new products and software updates from concept to deployment. DevOps teams often measure lead time in hours, not days, weeks or months, which underscores the centrality of speed in today’s hyper-competitive online environment. Customer experience and brand loyalty are constantly changing as new products and services come to market, and DevOps teams are under immense pressure to stay as agile and efficient as possible. Increased technology development velocity can lead to heightened security risks. As of early 2023, as many as nine out of 10 companies have detected security risks in their software supply chain. This is why companies cannot ignore the rising number of attacks targeting software development teams.
High-profile incidents at SolarWinds, NetBeans IDE, Kaseya and Codecov demonstrate the risks facing software development teams at every company.
These threats exploit the continuous integration and continuous delivery (CI/CD) process to sneak harmful software into authentic applications and install risky and harmful components whenever possible.
The risk of code injections makes safeguarding internal and external dependencies crucial. If not appropriately protected, compromised software pipelines can lead to data leaks, code tampering and system exploitations, putting the entire business at a heightened risk.
Simply put, DevOps teams must maximize development speed without compromising security. This is an undoubtedly tall order, but one that’s achievable with the right processes in place. Here are three strategies DevOps teams can implement immediately to reach this goal.
Streamlining privileged access management is vital for enhancing cybersecurity in DevOps teams, particularly with the growing threats to software supply chains. This requires adopting stringent security practices, including temporary access permissions that can be granted and revoked as needed—a strategy ideal for managing temporary services in DevOps workflows.
This approach facilitates automatic management of access privileges, including revoking password permissions when team members leave the organization or project and thorough scrutiny of who has access to what.
At the same time, enforcing least privilege access, a principle that aims to minimize the attack surface by eliminating unnecessary permissions and adjusting overly broad ones, is also essential, reducing the chances of account hijacking or theft of static API keys.
Similarly, zero standing privileges are also essential, relying on just-in-time access management that ensures minimal active permissions at any given moment, enhancing security by reducing potential vulnerabilities.
The cybersecurity AI sector is soaring alongside escalating cybersecurity threats to DevOps teams.
Deloitte expects cybersecurity AI solutions to become a $19 billion market by 2025, as the technology’s “ability to adaptively learn and detect novel patterns can accelerate detection, containment and response, easing the burden on SOC analysts and allowing them to be more proactive.”
AI can help DevOps teams detect and prevent cybersecurity incidents by quickly identifying and monitoring applications at risk, ensuring greater resilience in their DevOps processes through CI/CD, applying analytics to streamline data challenges, and identifying potential hot spots before they escalate and present real risks.
AI can also help combat alert fatigue within security teams, reduce analyst workloads and cut down on false positives, saving valuable time. According to a 2022 IT industry study, 60% of respondents receive more than 500 cloud security alerts every day, and alert fatigue is “causing critical alerts to be missed at an alarming rate.”
By leveraging AI for cybersecurity, DevOps teams can enhance their defensive posture without diluting their team’s impact, allowing them to best balance speed and security in the app development process.
In the realm of DevOps, success relies not only on implementing the right tools and technology but also on fostering an adaptive culture that encourages seamless communication and collaboration among team members.
Effective communication forms the bedrock of this cultural shift. By establishing clear lines of communication, development and operations teams can better understand each other’s challenges and perspectives. Open dialogues can foster mutual respect and create a shared understanding of common goals, thereby encouraging a collaborative problem-solving approach.
Meanwhile, fostering a collaborative culture is equally vital. When teams collaborate effectively, they can identify and resolve issues more quickly, improve the quality of the software, and accelerate delivery times.
Achieving faster app development without compromising security is a complex yet achievable goal in today’s competitive environment.
By investing in streamlining privileged access management, leveraging AI and fostering a culture of effective communication and collaboration, DevOps teams can enhance both speed and security.
To be sure, in the face of escalating cyberthreats, speed and security are not mutually exclusive but, rather, two sides of the same coin. By implementing these strategies, DevOps teams can navigate this delicate balance, accelerating development timelines while ensuring robust security.
Automation is the key to DevOps success, and CI/CD is the driving force behind it. The CI/CD pipeline is a series of automated workflows that help DevOps teams reduce manual tasks, achieve faster feedback, identify and fix issues early in the SDLC and improve the quality of software. However, keeping up with the latest CI/CD best practices and tools can be challenging.
In this episode, hosts Alan Shimel and Mitch Ashley are joined by Bryan Cole (Tricentis), Adam Arakelian (Dell), Jacqueline Porter (GitLab), Ravi Lachhman (Harness). This panel of DevOps leaders break down everything you need to know about CI/CD workflows to help you get started with your DevOps implementation. Our experts define CI and CD, share tips and tricks on how to build a CI/CD pipeline from scratch and discuss the best practices and key metrics to measure the success of your CI/CD pipeline.
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:
Icertis
Phoenix, Arizona
Principal Azure DevOps Engineer
$132,000 to $199,000
SimplyHired.com
Decision Sciences International
Remote
DevOps Engineer
$130,000+
Indeed.com
Hewlett-Packard Enterprise
Durham, North Carolina
DevOps Engineer
$124,500 to $286,300
CareerBuilder.com
CACI
Oklahoma City, Oklahoma
DevOps Platform Engineer
$104,200 to $229,200
Dice.com
SPECTRUM
Greenwood Village, Colorado
DevOps Engineer
$78,900 to $139,500
Despite being a well-known concept, implementing high availability (HA) remains a challenge for many companies. It’s critical to avoid single points of failure in company infrastructure, but it can be difficult to know where to start. In this Techstrong Learning Experience, we’ll shed light on this issue and explore the topic of HA. Our panel of industry experts will discuss the necessity of HA, clarify distinctions between disaster recovery and high availability and offer best practices for successful HA implementation.
You’ll learn:
Presentation Materials:
In today’s fast-paced world of software development, when continuous deployment and frequent releases are the norm, DevOps teams are essential to facilitating smooth communication between development and operations. In a blog post on LinkedIn, I talked about the importance of service level objectives (SLOs) for the testing team to improve the overall product quality. On top of that, let’s look at how adding SLOs to your DevOps team can improve productivity, dependability and client happiness.
• Aligning DevOps Goals with Business Objectives:
SLOs help DevOps teams coordinate their efforts with business objectives. The DevOps team can concentrate on delivering real business value by setting precise performance indicators, such as deployment success rates or infrastructure provisioning timeframes.
• Promoting Collaboration and Accountability:
By implementing SLOs, several stakeholders—including development, operations, quality assurance and business teams—are encouraged to work together. Over each stage of the software development life cycle, this shared responsibility promotes a sense of ownership and accountability.
• Driving Reliability and Stability:
SLOs play a key role in ensuring the stability and dependability of the system. You can be sure that your services consistently fulfill client expectations when your DevOps pipeline adheres to defined SLOs.
• Proactive Issue Mitigation:
Monitoring and alerting systems are used together with SLOs. The DevOps team could avoid service outages and downtime by aggressively identifying possible problems and resolving them before they become more serious by regularly monitoring important indicators.
• Data-Driven Decision Making:
Decision-making is driven by quantitative data. With the help of such indicators, the team is able to identify bottlenecks, prioritize improvements and streamline processes based on quick feedback.
Now, let’s explore some key areas where DevOps teams can set SLOs to improve their performance:
1. Continuous Integration (CI):
SLO: “xx% of builds complete within Y minutes.”
Measurement: Monitor build times and queue times regularly.
Action: Optimize CI infrastructure and configurations to meet the SLO.
2. Continuous Deployment (CD):
SLO: “xx% of deployments are successful.”
Measurement: Track deployment success rate.
Action: Improve the deployment process to meet the SLO and reduce deployment failures.
3. Infrastructure Management:
SLO: “xx% of infrastructure is provisioned within Y minutes.”
Measurement: Monitor infrastructure provisioning time.
Action: Optimize infrastructure provisioning scripts to meet the SLO.
4. Monitoring and Logging:
SLO: “DevOps tools and system uptime should be at least xx%.”
Measurement: Monitor the availability of the DevOps pipeline, deployment system and other tooling, including monitoring and logging systems.
Action: Ensure high availability for DevOps tools and components.
5. Artifact Management:
SLO: “Artifact retrieval time should be less than x seconds on average.”
Measurement: Monitor artifact retrieval time and availability.
Action: Optimize artifact storage and distribution mechanisms.
6. Testing and Quality Assurance:
SLO: “Code must have at least xx% unit test coverage.”
Measurement: Track test coverage regularly.
Action: Encourage developers to write more tests.
7. Security and Compliance:
SLO: “xx% of compliance checks must pass.”
Measurement: Monitor the results of compliance checks.
Action: Ensure necessary security measures to meet the compliance SLO.
8. Standardized Tools Selection:
SLO: “xx% of teams must use the approved CI/CD tools stack.”
Measurement: Track the percentage of teams using the approved tools stack.
Action: Encourage teams to adopt standardized tools and provide necessary training and support.
9. Training and Skill Development:
SLO: “xx% of team members should undergo relevant DevOps training annually.”
Measurement: Monitor training completion rates.
Action: Provide training opportunities and resources to help team members enhance their skills.
Initially, teams should baseline which percentage values to track by observing the current state. In the event they don’t have the bandwidth to baseline, start with any reasonable arbitrary number over a period of time, and it will be automatically refined.
Implementing service-level objectives empowers DevOps teams to focus on delivering reliable and high-performing services that meet user expectations. By setting clear performance and reliability targets, teams can proactively identify and resolve issues, leading to improved collaboration, efficiency and overall user satisfaction.
SLOs are not rigid constraints but are a means to drive continuous improvement and foster a culture of excellence within the DevOps ecosystem. As organizations strive to keep up with the ever-changing demands of the digital world, embracing SLOs is a crucial step toward achieving DevOps excellence and ensuring a competitive edge in the market.
If we’re being honest, the “green issue” currently isn’t the priority it needs to be for a lot of companies. At best, they are ticking the box marked ‘sustainability’ and paying lip service to a trendy topic. At worst, they are engaging in nothing more than greenwashing.
Considering carbon emissions from cloud computing have now overtaken those from commercial aviation, this is disheartening for the IT sector. Unsurprisingly, most of these emissions come from inefficient use of the cloud due to overly complex processes and a lack of centralized oversight over cloud infrastructures. And if “emissions” sounds a bit vague, here’s a translation into dollars–$147 billion was wasted in 2022 in cloud spend.
So, when it comes to reducing an organization’s cloud carbon footprint, there is clearly a financial incentive. Even for those who don’t believe in individual responsibility or worse, simply don’t care what kind of world we’ll leave future (and some present) humans to live in, there is money to be saved.
The truth is that companies need to put sustainability first across the whole enterprise, and they need to do it now.
Tackling departments one-by-one or singling out individual processes to make them more sustainable is not going to work. What organizations need is to stop thinking of sustainability as an afterthought and start incorporating it in the decision-making process from the get-go, maybe even as part of their very business model.
This is the sort of business that places its people and the planet above profits. Progressive, modern companies that want to stay in business longer need to invest in their people and take care of the planet instead of chasing endless growth and ever-increasing profit because that, simply put, cannot last.
As a culture, we’re currently at a turning point–late-stage capitalism is running its course, and more people are realizing that constant growth at the expense of well-being and the planet’s dwindling resources is not sustainable (in all senses of the word).
For this to work, it’s about looking at business through a new prism.
It’s not too late for businesses to become more sustainable. In fact, it is the best time to make life-saving changes. When it comes to tech specifically, there are a couple of things you can do, starting with two key things that need to change.
First, cloud waste has been costing companies billions of dollars for years now. Organizations are set to spend nearly $600 billion on the cloud in 2023, but it seems that most people are still in the dark about the real environmental impact of cloud usage. As with most big corporate changes, it’s all about a change of mindset. We need to accelerate awareness and promote digital sobriety to inspire transformation and decision-making with GreenOps on the enterprise level.
A cloud-first approach has long been the holy grail of IT. However, what we couldn’t anticipate is the sheer volume of resource usage and complexity that comes with it. We simply do not have the planetary resources to support this growth much longer. It’s time to become smarter, leaner and more environmentally conscious by using the “consume better” approach.
Second, think about the KPIs. Change without success parameters will not work. While organizations have a key role in decreasing global cloud spend, they must have the right tools and references. They need to be able to assess the environmental impact of their digital choices at all decision levels.
For the IT sector, this is where platform engineering comes into play. An internal developer platform can act as the critical piece that connects DevX, deployments, governance, security and observability.
With green best practices and cloud carbon footprint visibility at every stage–from the dev deploying a new environment on the cloud to the CFO checking the monthly cloud bill–a platform engineering approach ensures not only organizational but also individual responsibility. When all tools are accessible and processes transparent, nothing gets lost in translation. This means less room for error and cloud waste.
Right now, these KPIs will be financially motivated, and rightly so. But there will come a time when progressive organizations will put their environmental impact at the forefront of their mission statement.
The B-Corp certification, which evaluates companies in terms of their social and environmental performance, grew 63% in 2022. This shows the trend toward moving to a more inclusive and sustainable economy. Partly because it’s in the interest of the businesses’ long-term success and reducing costs, but partly because it is simply the right thing to do.
DevOps, DevSecOps and SRE are all quickly gaining traction within the tech world due to their effectiveness and promise of reliability for companies. Each framework provides various levels of safety and scalability—DevOps is agile, DevSecOps prioritizes security above all else and SRE focuses on performance optimization. Together, these are changing how software gets deployed from conception to production. We’ll break down each one in detail.
DevOps is a set of practices that combines software development and IT operations, which aims to shorten the software development life cycle (SDLC).
DevOps bridges the gap between those two areas by bringing together different people–developers, operators, testers and system engineers–who are responsible for different parts of the software delivery process, from planning to deployment into production environments.
A core tenet of DevOps is to automate manual processes within each stage of the SDLC, eliminating much of the redundant work that used to take weeks or even months. This automation significantly drives down costs, as well as reduces problems posed by human error when running manual tasks.
The following are some of the core tenets of DevOps:
1. Collaboration
2. Quality and reliability
3. Automation
4. Scalability
5. Security
DevSecOps (or DevOps security) is an emerging field within the DevOps practice that focuses on strengthening software security within the development and operations process.
These three distinct groups often have different priorities when it comes to building software applications. Developers are focused on speed-to-market objectives from their employers or clients, operations focus on reliability and scalability, while security teams prioritize safety from malicious actors or data breaches. At the same time, with DevSecOps, these goals become united under one umbrella: Build fast and reliable applications with built-in protection against attacks.
DevSecOps focuses on implementing security as code—or automating many routine tasks involved with identity management, like user authentication and authorization. To ensure that security is properly integrated into your DevOps pipelines, below are some key DevSecOps practices:
1. Automate security processes whenever possible
2. Encourage continuous testing
3. Prioritize remediation over detection
4. Create a culture around secure coding principles
SRE stands for site reliability engineering. The basic idea behind SRE practices is that software engineers should be responsible for both the development as well as the reliability of their product as a whole. This means having an understanding of not only how users will interact with the application or service but also how it interacts with other services in its operating environment, such as databases, firewalls, cloud environments, etc.
To maintain uptime while meeting these requirements, SRE applies various techniques like automation and continuous deployment processes to ensure high availability.
A key goal of site reliability engineering is service-level objectives (SLOs), which measure how consistently a service meets its goals over a given period of time—such as how often it’s available, how quickly it responds to requests made by users or customers—and establishing goals around those SLOs. Achieving objectives like these helps organizations build customer trust in their products and services since it ensures that they have stable and reliable day-to-day operations.
Here are some of the most important SRE principles:
1. Automation
2. Proactive monitoring
3. Fault tolerance
4. Measurement and analysis
5. Service-level objectives (SLOs)
The differences between DevOps, DevSecOps and SRE can be summed up in three main areas: Scope, roles and objectives.
DevOps focuses on improving the speed of releasing software by automating processes and optimizing collaboration between development and operations teams. This helps organizations create a continuous delivery pipeline to quickly deploy code into production with minimal risk. As such, it is typically focused on development or operations activities and has become synonymous with agile methodologies such as continuous integration/continuous delivery (CI/CD).
DevSecOps expands upon these concepts to include security considerations from the very beginning of a project’s life cycle instead of tacking them on after the fact. By shifting security left in the process–meaning bringing security earlier into the design phase–teams are able to reduce risk early on while achieving faster results overall through continuous feedback loops.
As part of this shift left process, DevSecOps practitioners focus heavily on automating security compliance activities as part of their job function rather than waiting until after deployment has occurred.
Meanwhile, SRE focuses more broadly on keeping the user experience consistent across various products an organization offers by responding to customer needs quickly while creating automation processes that allow common tasks to be repeated without manual intervention from engineers or developers.
Then there is also platform engineering, which is a closely related yet distinct discipline with its own unique responsibilities. While both DevOps and platform engineering involve automation and working with the infrastructure that supports software development, there are some key differences between them.
Platform engineering can be defined as a practice that involves developing a standardized platform on which all applications will run. Platform engineers build the underlying infrastructure to support applications, including servers, databases, virtualization layers and networking components using standardized toolsets. An important task for this field is designing an application’s architecture in such a way that allows it to scale easily with increased demand or usage levels. Additionally, they create self-service tools that enable developers on their team to quickly spin up new environments without requiring outside assistance.
In conclusion, while all three approaches have similar goals–ensuring reliability, speeding up the software delivery process and securing user data–they do so using different strategies:
● DevOps favors automation.
● DevSecOps puts focus on proactive security measures.
● SRE prioritizes optimization, reliability and scalability.
Each one can contribute significantly when appropriately implemented into any organization’s workflow, depending upon its own specific needs.
