During an online SLOconf event today, Nobl9 revealed that the platform it created to enable IT teams to achieve service level objectives (SLOs) is now available under an open source Apache license.
Brian Singer, chief product officer for Nobl9, said the goal is to make a YAML specification format for defining SLOs that includes a parser and basic validation and testing capabilities more accessible via an OpenSLO project. Achieving that goal is critical at a time when organizations are deploying microservices-based applications that have dependencies that often adversely impact performance and availability.
While the concept of an SLO and/or a service level agreement (SLA) has been around for a long time, IT teams that have embraced DevOps best practices by hiring site reliability engineers (SREs) are programmatically attempting to assure that SLOs are attained and, just as importantly, maintained, said Singer. Most SLAs have, historically, not been well-enforced. OpenSLO makes it possible to achieve that goal by embedding SLO objectives within a YAML file that become part of a Git-based workflow, he noted.
Niall Richard Murphy, author of the book, Site Reliability Engineering, has signed on to be a core OpenSLO contributor working alongside committers from GitLab, Dynatrace and Nobl9. The ultimate goal is to make it simpler to share and migrate portable SLO specifications across multiple application development projects by constructing them using an object model, said Singer.
Nobl9, meanwhile, will continue to operate a software-as-a-service (SaaS) platform for managing SLOs based on OpenSLO. Singer noted there will be an increased need for OpenSLO as it becomes more widely employed. The Nobl9 SLO platform is compatible with monitoring platforms such as Datadog, New Relic and Prometheus, and uses data collected from monitoring and observability platforms to calculate acceptable rates of error per service. It can be configured to trigger alerts and even workflows in anticipation of outages.
Accessible via a CLI/GUI/API, the platform also enables DevOps teams to create business rules and define “facets” of users based on the application experiences required. DevOps teams can identify users who are being serviced poorly in addition to tracking groups of users. They also can associate contractual obligations to an SLO for a critical business period.
The platform also makes it easier to determine how to make systems more reliable or lower reliability goals to reduce costs when possible. IT organizations will also spend much less time determining the root cause of any issue using a combination of real-time and historical data that is more accessible. Today, it’s not uncommon for IT teams to spend weeks looking for the source of an application degradation issue, only to discover the problem can be fixed in a matter of minutes.
It’s still early days as far as adoption of SLO-as-code is concerned, but the days when SLAs or SLOs were, at best, aspirational statements of intent are coming to an end. The expectation is SLOs will soon be maintained via YAML files embedded within application code and distributed across a rapidly expanding enterprise with more interdependencies than any IT team can manually track.
Digital transformation is increasingly propelled by rapidly changing user expectations. Release frequency is increasing, as is the need to connect a growing number of applications and digital experiences. As a result, 83% of IT specialists consider API integration critical to their business, found the State of API Integration Report.
Application programming interfaces (APIs) hold powerful sway in tech discussions of late. Building API-first could increase internal reusability. APIs have become a standardized machine-readable mechanism for connecting partners. There is also a hot market for API startups, meaning APIs are becoming products in their own right.
APIs are also enabling change for large enterprises. I recently connected with Bernd Gross, CTO at Software AG, to get his perspective on the role APIs and integrations are playing within the new wave of enterprise digital transformation. Below, we’ll see how connected customer experiences, digital business excellence and a new ecosystem-driven economy are driving the emergence of more API-based strategies.
Three Drivers of the Connected Enterprise
Businesses continue to transform into more connected enterprises. Once relegated solely to improving back-office efficiency, digitalization efforts are being applied across the board — to employee management, assets, machines, partners and the supply chain at large, said Gross.
Amid rising digitalization, connectivity is the glue that unites disparate elements and tools. A fully connected world is “the new flavor of digitalization,” said Gross. To his point, ‘connected experiences’ is a crucial driver for 68% of platform providers, The State of API Integration Report found.
So, how are APIs fueling the new connected enterprise? Gross identified three key reasons why integration is now fundamental to enterprise digitalization initiatives.
Software AG Marketecture, used with permission.
1. Connected Customer Experience
Many organizations “want to transform into a technology and software company,” said Gross. To participate in the connected digital economy, organizations are striving to create advanced 360-degree customer experiences. Today’s technology needs to “look beyond a PC application,” Gross said. These experiences must cater not only to desktops and smartphones but also to IoT devices and physical assets.
For example, he explains how one large elevator company architected an embedded connected experience, incorporating digital touchpoints within elevators to showcase signage, entertainment and ads, opening new monetization possibilities. This change was so radical that the mechanical engineering company pivoted its mission statement, reimagining itself as a “vertical transportation company.” Soon, their AI-enabled elevators will predict behaviors and optimize travel times, so they are always on the right floor, waiting for human riders.
Intelligent building technology is similarly being applied by digital-savvy hotels, Gross explained, which is especially important for contactless visits during the pandemic. A fully digitalized customer experience could involve automated check-in, a room access code sent to a smartphone, an online billing system, physical sensors and more. Enabling a seamless digital hotel experience sounds easy, but it’s technically quite challenging — there are endless integration requirements to connect. In some cases, it would take 24 integration points, noted Gross.
2. Digital Business Excellence
Gross recognized the high expectations for modern digital experiences. He described a “new trend of business excellence in delivering more of an end-to-end digital experience.” This means data can no longer be locked up; even traditional companies must transition to platforms to offer software and data to their end users. In the process, interesting things may occur — your customers could become partners, Gross adds.
He described how one medical company, a leading centrifuge producer, sought to build more digital experiences to complement their hardware. Though the machine functioned seamlessly, there was no easy way to port data results to other applications. This inhibited initiating the fully digitalized workflow required for a smart lab experience.
In this case, APIs were imperative to opening up back end cloud services to enable smooth user interfaces and end-to-end workflow automation. “Intuitive user interfaces must integrate all services, including cloud and on-premises services, to create and automate workflows,” Gross explained. “To do this, you need integration.”
3. Ecosystem-Driven Economy
The network effect of platforms is that they enable an ecosystem to form. And, according to Gross, involving partners in this new digital experience matrix is imperative for success. For example, the API gateway is one area where partnerships help an integration strategy; “You need an API gateway for security and governance reasons,” he stated.
Throughout his experience overseeing APIs on many projects, Gross often noticed a naïveté associated with defining the ecosystem. “When [clients] engage in the first phase of these projects, they think they know how to do it, but they typically don’t,” he said. Potential API providers often don’t fully realize their monetization strategy, the security implications or the complementary software providers necessary to support a working model. “Partnerships often facilitate a value-add to customers — they enrich the total offering through APIs and ecosystems,” said Gross.
Similar to how a machinery company may embed a bill of materials into the product they sell, digital partnership ecosystems can open up data so partners can access and innovate with it, Gross said. Frequently, ecosystem partnerships make a lot of sense, as they can better meet consumer expectations. For example, Gross suggested that integrating a ticketing system into a conditional monitoring system would bring compelling value.
The Next Stage: Self-Service Integration With APIs
According to the report, 40% of companies said that digital transformation is driving their need for app integration. Truly connected enterprises must embrace digitalization and integration across all aspects of the business. As a result, this is forcing a business shift toward more open ecosystems.
But building these systems will require newfound knowledge dissemination around developer experience and self-service capabilities. “Self-service has become fundamentally important,” said Gross. It’s not enough to simply open interfaces — you have to also add self-service capabilities to integration tools, he added. This could mean offering low-code options alongside APIs — such drag-and-drop UIs would help facilitate integrations for more citizen developers. A self-service approach to digital platformification is an emerging trend, yet one that’s “not fully at mass market,” described Gross; it’s still in its early stages.
Open ecosystems are guided by consumers, who often desire connections between your tool and external partners. But, opening up data isn’t just helpful for partner integration; it could also benefit internal use. As Gross described, time-series industrial analytics could empower operators on the shop floor or production facility to make sense of local data. “You need self-service analytics tools to give them that ability,” Gross said.
Building new customer experiences to cater to various devices and platforms is a big driver for API adoption. As a result, headless styles are emerging to address multi-platform requirements. For these reasons and many more, APIs are fueling new digital transformations across enterprises, powering innovative customer experiences and hiding complexity in the back end. With APIs, smart processes, smart machines and smart partners can all come together.
The Linux Foundation announced today that an open source application programming interface (API) gateway known as KrakenD has become the latest project it will oversee.
Rechristened the Lura Project, the lightweight stateless API gateway was originally developed by KrakenD, which plans to continue to offer an enterprise edition of the platform.
KrakenD CEO Albert Lombarte said the API gateway it developed provides a more streamlined approach to managing APIs that doesn’t require an organization to install a separate proxy or database. All the reverse proxy capabilities most organizations require is already embedded within the API gateway. That approach also makes it easier for IT teams to decouple back-end server applications from client applications because now an API can be more easily updated without impacting client applications, Lombarte added.
Organizations that already contribute to the ongoing development of the API gateway include 99P, Hepsiburada, Openroom, Postman and Stayforlong. The API gateway also is embedded in a variety of other platforms, said Lombarte; he noted that the number of servers running the gateway now exceeds more than one million per month.
API gateways have been available in various forms for years, but with the rise of microservices the number of APIs organizations need to deploy and manage continues to rise steadily. Each microservice added to an environment adds yet another API. At a time when microservices-based applications are at the core of many digital business transformation initiatives, IT teams must employ a more flexible approach to managing the interactions between APIs.
Thanks in part to the role they play in enabling digital business transformations, APIs are also being targeted more frequently by cybercriminals that have come to view them as an efficient way to exfiltrate data or inject malware into an application environment.
It’s not clear what impact the Linux Foundation’s support might have on organizations’ selection of one API gateway versus another. In fact, many organizations are still trying to navigate when to employ an API gateway versus relying on proxy software to manage a handful of APIs versus a service mesh to manage thousands. The issue comes down to not just how many APIs there are, but also the overall weight of the platform being employed, said Lombarte. A service mesh typically requires more time and effort to deploy and manage, he noted.
As the number of APIs in an IT environment continues to increase, there may come a day when organizations will have to revisit how APIs are created and maintained. All too often, APIs are still created as an afterthought once an application is created. They tend to be brittle and, as a consequence, still break often. A more holistic approach to managing APIs based on a set of DevOps best practices is required. The challenge is getting DevOps teams to prioritize APIs when there are so many other issues that require their attention. Nevertheless, it’s become apparent APIs are, in many cases, becoming too strategic to the business for their management to be left in the hands of a single development team.
ServiceNow today announced it has acquired Lightstep as part of an effort to add an observability platform to its IT operations portfolio. Terms of the deal, expected to close this quarter, were not disclosed.
The Change Intelligence observability platform from Lightstep is based on a time-series database that is capable of processing a trillion events each day. It was built by the same team that created Monarch, the globally distributed in-memory time series database system that Google employs to monitor its applications and systems. Lightstep team members also co-created both the OpenTracing and OpenTelemetry open source projects for collecting traces, metrics and logs.
Pablo Stern, senior vice president and general manager for IT workflow products at ServiceNow, said ServiceNow will employ Lightstep to enable IT organizations to observe both monolithic and microservices-based applications as IT operations and DevOps teams continue to collaborate more closely with one another. The goal is to provide a single pane of glass through which IT teams can observe their entire IT environment via the Now platform that ServiceNow makes available via a software-as-service (SaaS) delivery model.
That approach will enable DevOps teams to programmatically manage IT environments alongside IT administrators employing graphical tools, noted Stern.
Lightstep CEO Ben Sigelman added that, in time, the number of users of that observability will only increase as more application stakeholders start to track software development projects that are at the heart of various digital business transformation initiatives.
Thanks mainly to the rise of microservices that are now being deployed across highly distributed computing environments, it’s become more difficult to discover the root cause of an IT issue. Microservices-based applications have lots of dependencies that, while serving to make the overall application more resilient, conspire to make it difficult to determine which specific microservices might be adversely impacting the performance of an application.
The time-series database that lies underneath the Change Intelligence observability platform makes it feasible to go beyond logs and metrics to process distributed traces that provide more insight into application behavior. Ultimately, the goal is to enable organizations to innovate faster with a higher degree of confidence in the IT environment, said Sigelman.
As far as the march to observability in the enterprise is concerned, it’s still early days. While observability may be a core tenet of any DevOps practice, most IT organizations rely on myriad tools that surface data the teams then attempt to correlate. Whenever there is a major issue, those IT teams typically convene in a “war room” to compare reports generated by the various IT monitoring tools employed. Observability platforms that collect and process distributed traces used to instrument an application using a consistent set of specifications, frameworks and libraries. The OpenTracing and OpenTelemetry tools are significant because they provide an open source approach to instrumenting applications that reduces the total cost of observability. In comparison, many legacy application performance management (APM) platforms employ proprietary agents to instrument applications.
Naturally, each IT organizations will be moving down the path toward an observability platform that provides greater application context. At this point, however, it’s not clear to what degree observability platforms will need to be installed before making the transition to microservices versus being a capability that only gets appreciated once the trouble with microservices finally becomes apparent.
Trend Micro and Snyk unveiled today a software-as-a-service (SaaS) platform the two companies have jointly developed to identify vulnerabilities in open source code.
The Trend Micro Cloud One – Open Source Security by Snyk platform enables DevOps teams to both identify vulnerabilities and licensing issues to better monitor, prioritize and share information about risk and exposure rates within application development projects.
Trend Micro COO Kevin Simzer said the SaaS platform provides a unified approach that combines six services within a single subscription to enable organizations to better protect a software supply chain.
Snyk CTO Geva Solomonovich said that while the relationship between the two companies is not exclusive an alliance with Trend Micro will enable organizations to employ Snyk tools and the open source vulnerability database to implement a set of best DevSecOps practices within their organization.
Simzer said Trend Micro is also including automation tools that make it easier for cybersecurity teams, along with the rest of the IT organization, to discover what application development projects are underway with their organization. The goal is to provide cybersecurity teams and DevOps teams with a set of tools that provides them with a common language through which they can collaboratively address vulnerabilities.
Trend Micro claims approximately eight hours can be saved per vulnerability through automation and early discovery of the versions of open source code being employed. Roughly 80% of all application code in use today is derived from open source software, noted Trend Micro. That translates to saving more than 650 hours of development time per application, according to the company.
Snyk, meanwhile, claimed to have observed a 2.5x increase in the number of open source vulnerabilities it has discovered over the past three years. In the wake of some recent high-profile breaches the security of software supply chains has become a greater area of focus, with many organizations now implementing a more rigorous review of all the code they employ and any associated dependencies.
It’s still early days as far as adoption of DevSecOps best practices are concerned within most organizations. Responsibility for application security is clearly shifting further left toward developers. As part of that effort, cybersecurity teams are trying to adjust their processes in a way that enables them to vet the efforts of developers without slowing down the rate at which applications are developed. That’s becoming more challenging as the rate at which applications are being developed continues to increase.
The conundrum organizations are trying to navigate is that every minute a developer spends on security is, theoretically, one less minute they have to write applications or business logic. At the same time, however, if vulnerabilities are not addressed early in the development cycle, they may take longer and cost more to fix, especially if they are discovered after an application is deployed in a production environment.
Of course, there may come a day a when application security is just another set of steps to be performed within a quality assurance process. In the meantime, however, a lot more attention is being paid to application security today, in part, to make up for the many sins of the past.
Spring is here, and after a year filled with record-setting digital transformation and its associated vulnerabilities, now is the right time to give the open source components in your codebase a refresh. For many development teams, today’s open source operations present a ‘mess’ that’s difficult to clean up; often, no one knows how many libraries, third-party components or modules are in use, not to mention their vulnerability status. This can create a significant source of risk and technical debt, making a spring cleaning that much more necessary.
The good news is that there are some simple strategies and tools that organizations can implement to jump-start the open source spring cleaning process. Once implemented, these systems will help ensure that your codebase is kept up-to-date and clear of vulnerabilities.
Organizing and Inventorying Open Source
When embarking on your open source clean-up mission, an ideal first step is to take stock of what’s there. Gathering a list of all the relevant libraries and packages in your codebase, along with version information and where in your code they are used, should be your top priority.
Decide to Keep or Toss
There is a strong possibility that some of the components in your library contain vulnerabilities. Be sure to use online databases for a published list of vulnerabilities to easily identify which items may be past their security sell-by date. Consider which ones to update and which to remove altogether if they’re riddled with unpatched flaws.
Polishing, Dusting and Refreshing
Polishing your physical surfaces not only makes them look shiny but also protects them from damage caused by light, water or other natural elements. Digitally polishing your open source security posture should involve keeping your code base defended in a similar manner, which means making repeat security assessments as frequently as possible while also keeping the inventory up-to-date so your teams are always aware of what’s being used.
As a last step in this process, consider dusting off any outdated or existing policy documentation. Give them a spring refresh, as well, so they can account for the changes not only in your open source database but for your entire development team. By ensuring developers are all on the same page regarding policies, responsibilities and best practices, you are effectively setting the stage for the next phase of operational success.
Keeping Your Open Source Code Clean
Sometimes a clean-up becomes more substantial than anticipated and requires some extra muscle. Implementing a dedicated tool to assist with this clean-up will not only make the process faster and easier, but it can also lead to fewer false positives and more accurate results based on your choice of reinforcements.
Software composition analysis (SCA) tools can parse your codebase and discover the libraries, modules or frameworks that are in use, and automatically compare all discovered components against a vulnerability database. Your SCA tool needs two key things to produce actionable results:
Access to a curated, high-fidelity vulnerability database. Your time is valuable. It’s well worth getting the most accurate data you can, despite what may be marked “vulnerable” or “safe” in the public domain.
Insight into your code. Just because you are using a vulnerable library does not automatically mean your code is vulnerable. What method in the library is vulnerable – are you even using it in your code? If you are using it, are you passing a static value or some input-derived variable? This is a function described as the ‘Exploitable Path’, and it is critical to focusing your clean-up efforts.
This process will provide a comprehensive list of the flawed modules in use and help you decide what needs to ultimately be kept and what needs immediate attention. With the right tools – and the right data – you can get an accurate, prioritized list of what open source components you should update or depreciate in your code.
While embedding an SCA tool into your development process and workflow alongside your other build and security-focused tools is essential to stop the accumulation of more risk and technical debt, maintaining the quality and freshness of the source vulnerability data is also extremely critical. While retaining an up-to-date list of vulnerable components seems like a full-time job, baking an open source hygiene process into your workflow can be a key component of your database’s overall maintenance.
Evaluating your open source components at build time – and then systematically scheduling reassessment scans to catch newly discovered vulnerabilities in previously ‘safe’ libraries – can bake an open source hygiene process into the developer workflow. This will serve to extend the “spring cleaning” mentality to a year-round endeavor. With the threat landscape continuing to rapidly evolve and vulnerabilities rising by the hour, implementing these simple practices could have a long-lasting impact on your open source infrastructure as it stands today.
Splunk today unveiled an observability platform delivered as a cloud service that captures all metrics, traces and logs in real-time without relying on sampling.
Spiros Xanthos, vice president of product management for observability and IT Ops at Splunk, said Splunk Observability Cloud collects all that data via a single agent based on open source OpenTelemetry software to instrument an application.
Historically, application performance management platforms (APMs) have only analyzed samples of data to identify a potential anomaly. Splunk Observability Cloud analyzes all the streaming data captured by its agent software to enable IT teams to pinpoint the root cause of an issue faster, said Xanthos.
As a result, Xanthos said the signal-to-noise ratio dramatically improves compared to legacy monitoring platforms. It will then be up to each IT team to decide how much of that data they want to store after it’s been analyzed, added Xanthos. Pricing for Splunk Observability Cloud is based on the number of hosts employed rather than the amount of data collected.
The Splunk Observability Cloud unifies a Splunk analytics portfolio by including capabilities provided via Splunk Log Observer, Splunk Real User Monitoring (RUM), Splunk Synthetic Monitoring, Splunk Infrastructure Monitoring, Splunk APM and Splunk On-Call. Splunk Synthetics Monitoring is based on technology Splunk gained with the acquisition of Rigor last year.
The Splunk Observability Cloud is one of the first such platforms to rely solely on OpenTelemetry agent software being developed under the auspices of the Cloud Native Computing Foundation (CNCF) to collect data. That project not only reduces the cost of instrumenting applications, it also reduces the number of agents an IT team might have to deploy to collect metrics, traces and log data.
Many rival observability platforms can collect data from OpenTelemetry agent software, but also tend to encourage DevOps teams to deploy proprietary agent software that they claim is easier to install and collects data at a more granular level. Splunk has decided OpenTelemetry has matured to the point where those proprietary agents are no longer required, said Xanthos.
The rise of observability platforms presents an opportunity for IT teams to rationalize a raft of monitoring tools that often surface conflicting analyses. IT teams today spend an inordinate amount of time convening so-called “war room” meetings to determine the actual source of an issue. Those meetings can go on for hours, only to eventually discover an issue that only takes a few minutes to fix.
While observability has always been a core DevOps principle, the level of visibility most IT teams have into their application environments is limited. There is no shortage of monitoring tools, but because there is no unified approach to observing an IT environment, there simply isn’t enough context being provided. As IT environments become more complex – thanks primarily to the rise of microservices-based applications that have lots of dependencies – that lack of context is rapidly becoming a major issue. A microservices-based application is designed to degrade gracefully if one microservice suddenly become unavailable. The issue is that it can take a very long time to discover the root cause of performance degradation.
It may be a while before most IT teams achieve true observability, but once they do, many will wonder how they previously managed IT without it.
Activity among China-based open source project contributors and creators surged in 2020, as Alibaba, Huawei, Tencent and other leading Chinese tech companies are playing an increasingly important role in the open source development community worldwide.
According to the recently released Open Source Contributor Index (OSCI) ranking, as of March 2021, Alibaba, Huawei, and Tencent collectively ranked in the top 20 worldwide for the first time. Rankings are based on the total number of contributors and contributions on GitHub. Microsoft, Google and Red Hat ranked first, second and third, respectively.
Alibaba, as well as China-based Pingcap, came within striking distance of reaching the top 20 worldwide open source ranking for 2020 measured in activity; the total number of forks, commits, stars, pull requests, issue comments and other metrics, according to the GitHub 2020 Digital Insight Reportreleased in April.
Authored by X-lab in conjunction with East China Normal University, Kaiyuanshe, Shanghai Open Source Information Technology Association and other unnamed “scientific research institutions and open source community institutes,” the X-lab report revealed Pingcap’s eponymous Pingcap (a distributed relational database) and Alibaba’s AntDesign (a Microsoft React framework) activity metrics of 210 and 193, respectively, in 2020. Meanwhile, jwasham (an open source study plan detailing how to become a software engineer) ranked 20th worldwide with an activity metric of 234.
Open Elastic’s Kibana, recently forked by Amazon Web Services (AWS) and Kubernetes ranked first and second worldwide with activity metrics of 698 and 602, respectively.
Torsten Volk, an analyst for Enterprise Management Associates (EMA), says the increased popularity of and activity in China-based open source projects are proof that the concept behind open source software actually works.
“This is the classic ‘one plus one adds up to more than only two’ theory, and that applies to most companies anywhere in the world. And if it was possibly to gain advantages by only using open source code but not contributing, companies anywhere else in the world would have done so right from the start,” says Volk. “Remember that the core idea behind open source software is not to give out your secret sauce for other companies to enjoy for free, but to spend the least possible amount of funding on building commodity code.”
What, if anything, China-backed open source projects means for the community worldwide — as well as China’s influence in the industry in general – remain to be seen. Tencent, which entered the top 20 in March ranked by contributors in the OSCI study, for example, has become a leading supplier of components for machine learning (ML) databases in, for example, Kubernetes and cloud-native environments.
“This is great for everyone, and there is no benefit for anyone to purposefully not contribute to a project they benefit from. The benefit comes from your own contributions, in terms of reputation and credibility gain, across your industry. This motivates others to also contribute, as there is little to no benefit in keeping your own code secret while self-serving from the GitHub buffet,” says Volk. “As in the case of Kubernetes, your own company’s differentiation needs to come from the manner your proprietary apps [integrate] on top of this platform, or from the way you are able to integrate Kubernetes clusters with machine learning databases and other elements higher up the stack. And that’s why open source works.”
Open source technology thrives during times of mass disruption, and this pandemic has been no different. Across the board, companies are accelerating their digital transformation and DevOps strategies, looking to open source technology as a way to streamline operations. While deploying open source software (OSS) in DevOps can help organizations lower costs and avoid vendor lock-in, the tools are often not backed by an ecosystem that makes them transferable across the enterprise, leading to interoperability issues across the board and creating a haphazard workflow.
Before embarking on an open source migration, companies need to plan out their strategy. Following these five steps will help companies create an organized plan and a seamless open source stack so that they can capitalize on the lower costs and tap into the benefits of the open source community.
Determine if you Can Self-Support Your Strategy
A recent Gartner study determined that at least 75% of open source policies don’t yield effective results. This stat is largely due to companies believing that they can self-support their open source stack. However, as technology becomes increasingly complicated, companies should take a step back and evaluate if they actually have the right resources and skill sets to get the job done. Enterprise architects with open source expertise are a niche group that’s in high demand, so don’t worry if you don’t have the resources – there are plenty of trusted vendors out there who have a proven track record of delivering results.
Consolidate
Fewer vendors equal fewer problems. When evaluating potential partners, keep in mind that working with a few key partners (versus several) will be beneficial in the long run by ensuring that applications will work together seamlessly, while also avoiding vendor finger-pointing if they don’t. Assess potential partners to see which packages, application stacks and infrastructure they support, and what level of freedom you have to switch out various components. Avoiding vendor lock-in is key, as switching vendors will be a costly undertaking if you ultimately decide to go in another direction.
Invest in Security
Security is a major concern in enterprise open source software, and it’s critical to make sure you have the ability to act quickly on potential issues and vulnerabilities. Consider partnering with a vendor who specializes in OSS security, and can keep clients informed of the latest security updates and bug fixes to ensure that your program isn’t vulnerable to security threats. Having a security specialist on standby is a must-have for organizations so that when security is breached, it can be remediated immediately.
Pick the Right Tools
Not all tools are alike. There are plenty of options out there that can help elevate your open source strategy, but consider how each will affect your overall program. At each phase of your pipeline, test the open source tools selected to ensure that they can integrate together within the broader toolchain and every layer of your software stack, including databases, platforms and monitoring solutions. If you have questions about their connectivity, either consult with an expert who understands how the software will truly behave in various environments or engage with free apps that help developers determine if their tools are compatible across the broader stack. Doing so will help enterprises choose the right open source technology early on, saving both time and money.
Adapt
Open source implementation in DevOps is more than a one and done approach; it requires adapting and tweaking in order to stay relevant, keep a competitive advantage and optimize new technology. Ensure that your open source strategy can be improved to include new offerings and services that the company will implement down the road and that your vendors—or internal team—can modify the framework fairly easily when necessary.
While open source technology continues to drive innovation in the DevOps industry, including it in a company’s DevOps strategy requires thoughtful planning. When done right, an open source policy will save a company time, money and people power, allowing them to collaborate seamlessly with the greatest minds in the industry.
During its online Red Hat Summit event, Red Hat today announced it has extended the Red Hat Insights predictive analytics cloud platform for managing IT to now include support for editions of Red Hat OpenShift based on Kubernetes and the Red Hat Ansible Automation Platform.
In addition, Red Hat has extended Red Hat Insights for Red Hat Enterprise Linux (RHEL) to include the ability to prioritize security alerts, streamline notifications and track Red Hat subscription consumption.
In total, since launching Red Hat Insights in 2019, Red Hat claims there are now more than 600,000 RHEL hosts analyzed per day.
Joe Fitzgerald, vice president and general manager for the management business unit at Red Hat, said Red Hat Insights provides IT teams with the equivalent of a co-pilot for managing IT environments. In general, advances in automation and artificial intelligence (AI) are making it easier to manage complex IT environments at scale, noted Fitzgerald. However, it’s not likely IT environments will be automated to the point where lights-out management without human intervention is likely to be achieved any time soon, added Fitzgerald.
However, it’s also becoming apparent that it’s not possible for IT teams to manage complex IT environments without help in the form of advanced analytics tools. In fact, while many IT professionals are leery of automation tools because of the perceived threat to their jobs, it’s also becoming apparent that IT teams will not be able to manage modern IT environments without these tools. Organizations can’t afford to hire small armies of IT personnel. In addition, finding and retaining IT professionals that have, for example, Red Hat OpenShift skills remains a significant challenge.
Red Hat Insights provides IT teams with additional levels of context required to manage these environments that goes beyond simple monitoring, noted Fitzgerald. That’s critical, as the IT environment becomes more extended in the age of hybrid cloud and the rate at which platforms are updated steadily increases, added Fitzgerald. Platforms such as Red Hat OpenShift, for example, are now typically updated every three to four months.
DevOps, of course, has always been about ruthlessly applying automation whenever possible. As analytics applications become more robust, IT teams gain the visibility required to automate a wider range of complex tasks, noted Fitzgerald. In fact, in the absence of that visibility, automation can be a dangerous thing when mistakes caused by a lack of visibility and insight are made, added Fitzgerald.
In the longer term, Red Hat expects to see continued convergence of job functions and roles as IT teams become more cross-functional, said Fitzgerald. Platforms such as Red Hat Insights will provide a single console around which these teams can collaborate, added Fitzgerald.
Going forward, there won’t be a handful of administrators with augmented capabilities. Rather, IT specialists that have a particular set of skills will be able to collaborate more easily in a way that both creates a better outcome and ultimately keeps a lid on the total cost of IT.
