Category: DevOps Toolbox

  • Logz.io Allies with Microsoft on Open Source Observability

    Logz.io Allies with Microsoft on Open Source Observability

    Logz.io this week announced an alliance with Microsoft that enables DevOps teams to deploy its observability platform—based on open source platforms such as ElasticSearch, Logstash, Kibana (ELK), Prometheus and Jaeger—on the Azure public cloud.

    Jonah Kowall, Logz.io’s CTO, said the multi-year effort enables those teams to deploy the Logz.io platform via the Azure Console with the click of a button. The Azure platform has a data collection capability that aggregates operating system events in a way that makes it simpler for the Prometheus monitoring solution to consume, he added.

    DevOps teams, however, will still have to collect data from the applications they instrument on the Azure platform, he added.

    Logz.io integrates multiple open source monitoring tools based on metrics, logs and traces within a single observability platform that otherwise would require considerable time and effort from internal IT teams on their own.

    Interest in observability is rising as organizations attempt to provide internal IT teams with more context when troubleshooting issues. Whenever there is an IT issue, most teams convene a “war room” where they attempt to discover the root cause of an issue by comparing analytics generated by a wide range of monitoring tools. Observability platforms promise to enable a DevOps team to replace many of those tools in a way that provides more context by integrating log data, metrics and distributed traces within a single platform.

    In many instances, existing application performance management (APM) platforms are being transformed into observability platforms by adding tools to monitor IT infrastructure. Conversely, platforms for managing IT infrastructure are adding support for tools to monitor applications. Elsewhere, a range of startups have emerged to offer observability platforms they have developed from the ground up.

    Regardless of the platform employed, the rise of microservices-based applications within many organizations is forcing the observability issue. The dependencies that exist within microservices-based applications are too complex to manage without a platform that provides some level of increased observability. Of course, most existing monolithic applications are not being retired any time soon, so the need for an observability framework for both legacy and modern cloud-native applications has only become more pressing.

    The Logz.io platform can, of course, be deployed on other cloud platforms as well as within on-premises IT environments. As hybrid cloud computing continues to evolve, it is apparent that observability platforms will need to extend their reach from the cloud to the network edge. Over time, artificial intelligence (AI) capabilities will be added to make it easier to, for example, streamline the number of alerts that are generated across complex IT environments.

    In the meantime, the most important thing with regard to observability may be simply getting started. Most IT teams start to analyze logs before moving on to metrics and then traces using the open source Jaeger agent software. After all, the only thing more difficult to instrument than an application before it is deployed is, arguably, one that is already running in a production environment.

  • WhiteSource Tool Automatically Fixes Code Vulnerabilities

    WhiteSource Tool Automatically Fixes Code Vulnerabilities

    WhiteSource today announced that it has developed the first-ever tool that automatically remediates vulnerabilities discovered in custom code.

    Rami Sass, WhiteSource CEO, said WhiteSource Cure surfaces recommendations for fixing security vulnerabilities in code that developers can then apply with a click of a button. WhiteSource has a long history of providing tools that discover vulnerabilities in open source software that it tracks via a database it manages, but Sass said customers are making it clear they need a way to automatically remediate those issues in a way that doesn’t adversely impact developer productivity.

    The average developer spends, on average, half a day fixing a single vulnerability, so the impact security issues are having on the rate applications are being developed is significant, added Sass. WhiteSource Cure gives each developer the equivalent of their own personal security expert, noted Sass.

    Developers can either apply the remediation suggested by WhiteSource Cure—that manifests itself as a pull request in a DevOps pipeline—or they can fine-tune it as they see fit, said Sass.

    WhiteSource

    WhiteSource Cure arrived as friction and tensions between developers and cybersecurity teams rise in the wake of a series of high-profile attacks against software supply chains. As a result, organizations are instituting more thorough security reviews of application development projects. The concern is those reviews will dramatically reduce the rate at which applications are being delivered.

    Of course, many organizations are looking to shift responsibility for application security further left toward developers to minimize the number of vulnerabilities that might need to be remediated either just before an application is deployed in an on-premises IT environment or, worse yet, after it is deployed. Trying to achieve that goal within the context of DevSecOps best practices, however, is challenging. Organizations first have to acquire vulnerability scanning tools that developers will actually use, and then provide developers with the training required to identify various classes of vulnerabilities.

    The other big challenge is the time it takes to train developers to recognize vulnerabilities. WhiteSource Cure eliminates the need for developers to become security experts, said Sass. In addition to a commercial offering, WhiteSource is also making available a Community Edition of WhiteSource Cure for open source projects that will forever be available for free to developers working on those projects.

    Sass said that rather than relying on machine learning algorithms and other forms of artificial intelligence (AI) to build WhiteSource Cure, the team that developed the tool found that more traditional approaches to software composition analysis (SCA) provided more reliable results.

    It’s unclear whether the ability to automatically remediate known vulnerabilities in code will render much of the DevSecOps debate moot. However, it’s clear that the simplest path forward toward achieving DevSecOps is, as always, to automate as much of the remediation process as possible. The challenge will be waiting to see how much confidence developers and cybersecurity teams will have in the recommendations generated.

  • Shoreline Platform Automates Repetitive IT Tasks

    Shoreline Platform Automates Repetitive IT Tasks

    Shoreline emerged from stealth today to make available a namesake incident automation platform that eliminates the need to manually perform the same repetitive tasks.

    Anurag Gupta, Shoreline CEO, said the platform is based on domain-specific language, dubbed Op, that provides a simple pipe delimited syntax to integrate real-time resources and metrics in a way that allows DevOps teams to invoke an orchestration engine to automate the execution of a task from the Linux command prompt. Op employs a syntax that is familiar to any IT professionals that currently use shell commands and scripting tools to resolve IT issues, said Gupta.

    That same Shoreline tool, however, can also be employed to create remediation loops that check for issues, collect diagnostics and apply repairs automatically in the background, he added.

    Shoreline

    Shoreline achieves that goal by first collecting metrics on a per-second basis via data collected from open source Prometheus monitoring software. Armed with that data, it then becomes possible to distribute queries to both collect data in real-time and run local loops in parallel to automate repairs, Gupta said.

    The platform employs the JAX and XLA frameworks for machine learning algorithms to reduce the amount of CPU resources required to compute metrics and create alarms. Wavelets are also employed to compress the input metric stream. Finally, queries are portioned across historical data stored in the S3 cloud storage service from Amazon Web Services (AWS) and real-time data collected from each node.

    All Shoreline components are designed to be fault-tolerant, added Gupta. Automation can still run locally to Shoreline backends, even when connectivity is lost. All processes have supervisors to restart when failing and reestablish connectivity.

    Finally, Shoreline provides controls to limit the scope of a manual operator action and automate executions in a given time period to help prevent any errors from cascading through an entire IT environment. That approach makes it possible to safely automate tasks in a way that makes it less likely outages will occur because, for example, a misconfiguration winds up being propagated across every system, noted Gupta.

    While IT environments are arguably more complex than ever, Gupta said it’s the repetitive tasks that take up so much of developers’ time. In the absence of any way to automate those tasks, an IT team will, over time, become increasingly burned out, which Gupta noted inevitably leads to mistakes being made.

    At the same time, Gupta noted the Shoreline platform makes it simpler to onboard new members of an IT team because much of the tribal knowledge that once had to be learned on the job has been captured within an automation platform.

    The arguments for automating IT have, of course, been growing louder and more frequent for nearly two decades. Most platforms that promise to automate IT have required a fair amount of expertise to implement and maintain. The Shoreline approach, in contrast, starts with a Linux prompt that many IT teams already routinely use to execute a range of tasks. The difference now is simply the level of scale at which those tasks can be performed with a minimum of programming skills.

  • Shopify Gives Devs More Creative Freedom

    Shopify Gives Devs More Creative Freedom

    Shopify’s Unite 2021 conference was held on June 29, 2021, and the e-commerce platform had some big, developer-centric news to share. Alan Shimel spoke with Shopify’s Glen Coates about the developer-first business model that is giving developers the most opportunity to build their businesses with a new 0% revenue share model, and how developers can leverage as much creative freedom as they want, from low-code capabilities in Online Store 2.0 to “max-code” custom storefronts. The video is below, followed by a transcript of the conversation.

    Alan Shimel: Hi, everyone. Welcome to another TechStrong TV segment. My guest this segment is Glen Coates. Glen is with Shopify. Glen, welcome to TechStrong TV.

    Glen Coates: Thanks, Alan. It’s great to be here, man.

    Shimel: It’s great to have you on. Glen, no pressure, but I think you’re the first person from Shopify who has been on TechStrong TV.

    Coates: There you go. _____ [inaudible due to audio distortion] it’s going to be all up from here, like you’re starting at the right place.

    Shimel: We’re starting at a low bar.

    [Crosstalk]

    ‒ it only gets better. We’ll see. Anyway, Glen, I think our audience doesn’t need an introduction to Shopify. We’ve all bought things online through Shopify storefronts and so forth, but why don’t we talk a little bit about you, your background, your position with Shopify?

    Coates: Right. I’ve been at Shopify a couple of years now. Before Shopify, I founded a startup called Handshake, and Handshake was a wholesale-focused e-commerce platform, so very much like Shopify but not focused on direct-to-consumer selling, just on wholesale. Handshake was acquired by Shopify about two years ago, so I’ve been at Shopify since the acquisition. In my time in the last couple of years at Shopify, I initially started out focused on wholesale, obviously, given my background. I spent most of last year focused on Shopify’s checkout, which is, obviously, a pretty important part of Shopify, and then about six months ago, _____ _____ product for what is called Shopify Core.

    If you’re a merchant, Shopify Core is like what’s in the box when you buy Shopify. It’s the online store, it’s the checkout, and it’s the back office admin that lets you set up and run your business. If you’re a developer, Shopify Core is the core developer platform, so the APIs, the dev tools, the docs, all the things that let you build apps and themes and work on the Shopify platform. Yeah, and, obviously, it’s a big responsibility and a really exciting role to be able to help the world of entrepreneurs start and try their business ideas.

    Shimel: Absolutely. Glen, just to give a little color, how many different Shopify merchant stores are there, whether it’s sheer number, percentage of commerce, or what have you?

    Coates: Yeah. Today, Shopify powers almost two million merchants. I mean, obviously, the last year has been kind of an accelerant to businesses going online, and that’s both been new businesses, people trying businesses for the first time, and it has also been traditional businesses going digital more quickly than they might have otherwise. But yeah, today, Shopify powers almost two million merchants worldwide, and it wasn’t that long ago that that was only a million. Even at massive scale, even being the world’s largest commerce platform in terms of number of merchants, it’s still growing very quickly, which I think just goes to the pace at which the world of business is going online, and how many people want some help with that.

    Shimel: Got it. Excellent. Thanks for all that info. If you don’t mind, let’s turn to the topic of today’s conversation, and I’m going to let you explain it, if it’s okay.

    Coates: Sure. Next week, it is Shopify Unite, which is our annual conference. Over the years, Shopify Unite has been focused on a combination of merchant and developer topics, but this year we’re really doubling down on developers, and really making it a developer-centric conference. The reason for that is sort of going back to the question you asked me a second ago, is Shopify was founded in Canada, and, if you go back five, six, seven years, Shopify’s mission has always been to make commerce better for everyone. But, if you go back half a decade, it was mainly North American merchants mainly selling apparel, mainly direct-to-consumer, which that’s a big market but it’s not the world of commerce.

    Over the last few years, Shopify has expanded considerably into new industries, new countries, new ways of welling, so wholesale as well as retail, and so we’re now in a much more diverse world of commerce, different businesses doing different things. As we sort of march down the road and try to fulfill that mission of making commerce better for everyone, that everyone is becoming a lot more diverse as we expand. Shopify can’t build all the solutions for everyone, all those different niches. While we have a great core product that includes many of the out-of-the-box things that people need to start and run a digital business, it’s not everything. We need the help of the world of developers to help build those solutions for the markets for the spaces that they are experts in to complement what is in Shopify Core, and really deliver everything that merchants need to successfully start, run, and scale a business.

    This year, we’re really focused on developers and helping them get onboard with our platform. There are really three main legs to that, I would say. The first one is mainly technical. I think for your audience, some of those details are important, like Shopify really is expanding to be PlanetScale commerce infrastructure, really becoming the power lines, the plumbing, the electricity grid that runs the world of commerce. So, we’ve done some things to really scale up our infrastructure that if you’re a developer building on Shopify, you can be confident your stuff is going to run at global scale without you really having to do anything. Our checkout can handle seven times the load that it could before. We’re now at greater than 30,000 checkouts per minute on a single shop.

    It’s interesting what’s happening to the world of commerce, like the world of social selling has made, and the way algorithms reinforce themselves in terms of distribution to drive traffic towards things that are trending. It’s become more important than ever that a merchant who blows up, whether it’s because of them being re-shared by an influencer or whatever it is, that they can capture that demand in the moment. Traffic is basically getting more spiky on the Internet. When things trend, they trend fast, and so Shopify already was the highest throughput checkout on the Internet but it’s now 7x higher, so merchants should never worry about not being able to make the most of those moments when they’re trending becoming more and more important.

    Shimel: It’s hyperscale, is what it is, Glen. We’re seeing it not only in merchants and commerce, but across everything. The Internet is big business, it is worldwide business, and especially with COVID, right? If you haven’t built your infrastructure to hyperscale, you’ve got trouble.

    Coates: Right.

    Shimel: That’s what digital transformation is about. That’s what the world is demanding right now, hyperscale.

    Coates: I imagine the readers, viewers of your site are not strangers to the world of what it takes to scale websites, and I think a lot of what Shopify tries to do is say, “Well, listen. We’ve figured that out for you. You’re a merchant with an idea. You’re going to come up with a new shoe or a new candle,” or whatever it is. Entrepreneurship is a risky endeavor, not everyone succeeds, but, when you succeed, like we really want you to be able to just capture the whole thing. The checkout works at one checkout a minute when you’re just starting out, and then, on your biggest days, it goes to 30,000 and you just don’t have to do anything. It just works, which is great. Kind of piece number one of Unite this year is Shopify really is PlanetScale infrastructure for commerce, and we already were the leaders and we’ve kind of gone up another multiple from there. Point two is really like, “As a developer, what things can I build on your platform? What are the opportunities for me to innovate, like where can I do that, and why is that exciting?”

    We’ve made some major updates to our online store, to our themes platform, which is obviously every merchant basically runs an online store with a theme on it. There is a new themes platform that allows developers to properly separate basically data and presentation into different layers in a way that makes themes more modular and extensible and kind of upgradable in the future. We have this powerful new data infrastructure that allows merchants and developers to essentially build custom data models inside a shop, and not just be confined to the out-of-the-box data model that ships with Shopify. There is now a much more powerful customization framework for both theme developers and app developers to integrate custom content into themes without having to hack the theme by hand and try to take it off the upgrade path, which is really great for merchants. We have also recognized that the Shopify online store is based on a web templating language called Liquid, which is similar to the templating languages that all developers are basically familiar with.

    We are also announcing, if you want to, you choose your own stack. If you want to build your website using React or something else that’s not our out-of-the-box stack, we’re also making available a new platform codenamed Hydrogen that will allow developers to basically choose their own stack, build online stores using whatever technologies they want, but ‒ and this is the crucial part ‒ still leverage a global infrastructure and hosting in scale and, “I don’t have to think about it. It’s just going to work,” on the Shopify platform, which is really great and really unique. Last but not least, I mentioned earlier that I spent last year on checkout. We are opening up for the first time the ability for developers to build checkout apps. Checkout is the piece of Shopify that it really matters. It’s where the money changes hands. It has to scale, it has to be super reliable ‒

    Shimel: Super secure.

    Coates: Super secure, super trusted, right, and trusted not just in the technical security sense of the word, but even just in the emotional sense of the word, like when I’m a buyer and I’m buying from an online store, when I see this checkout, does it feel familiar? Does it feel like something I can rely on? Am I comfortable handing over my money? Checkout is really where, in the _____ journey, the emotions shift from at the top of the funnel it’s kind of, “Okay, your brand, it’s really different. It’s exciting. I want to see differentiation. I want to be challenged and see new things.” But, when you’re handing over your money, the emotional tone is different, right? You’re not looking for excitement, you’re looking for predictability, right?

    Shimel: Yeah.

    Coates: Historically, Shopify’s checkout has been less customizable than the actual storefront pages higher in the funnel, and so now we’re opening up a new extensions framework for checkout that allows developers to build in apps that securely extend the function of Shopify’s checkout without compromising on the trust, the scalability, the speed, and all those kind of baseline, crucial things.

    Shimel: Very cool.

    Coates: That’s really cool. The last thing I’ll mention is we’ve talked about, “Okay, as a developer, if I build on your platform, is it just going to scale to the world?” The answer is yes. “Okay, so then what am I going to build?” Okay, so there are a bunch of new programming surface areas that we’re opening up for people to build apps and themes into, and then the last piece is, “What’s in it for me? Where are the dollars? If I start building your platform, am I actually going to make any money as a developer?” One of the things we’ve announced is _____ economic opportunities for developers. One is we’re cutting the rev share on apps in the Shopify app store to zero for the first million dollars in revenue per year, and, after the first million dollars, we’ve actually cut our rev share from 20 percent, which was already one of the lower rev shares in the industry, down to 15 percent. We’re really trying to help developers who have an idea for an app or an idea for a theme get that off the ground, no rev share on that first million bucks, and we really just want to help developer entrepreneurs get going as easy as we try to help merchant entrepreneurs get going ‒

    [Crosstalk]

    Then, the second one is that the Shopify theme store has historically not been open for submissions from any developer who wants to build a theme. There has been a sort of a curated set of themes there until now, but we’re actually opening up the theme store, so developers who want to build a theme and sell it to merchants will now have that opportunity that they didn’t before, which is also a huge market that is new.

    Shimel: Look, I think emphasizing the developer and the developer interaction in Shopify is huge. Glen, this is all great. I didn’t want to stop you when you were talking, but of course we’ve pre-recorded this show and it’s now playing after Unite has already taken place, I believe, on the 29th.

    Coates: Right.

    Shimel: But, for people who maybe want to see a replay of it or maybe get the highlights, is there a place we could send them to check it out?

    Coates: Yeah, if they just go unite.shopify.com, they’ll be able to watch the keynote and then dive into the other sessions that were part of the event and dig into whatever they would like.

    Shimel: Fantastic. Glen, thanks for a great recap on what happened at Unite and what’s going on at Shopify. Please come back on and keep us posted. You were wrong. You set a high bar. It’s going to be tough for people to beat, so come in and please keep us up to date on what’s going on at Shopify, especially with this renewed focus on developers and development options on the platform.

    Coates: I appreciate your time, man. Thanks for having me.

    Shimel: All right. Glen Coates on Shopify, about Unite, the Shopify conference here on TechStrong TV. We’re going to take a break and we’ll be right back with another guest.

  • Cycloid Brings Open DevOps Framework to the US and UK

    Cycloid Brings Open DevOps Framework to the US and UK

    Cycloid, a Paris, France-based provider of an open framework for implementing DevOps best practices, today announced it is expanding its operations into the U.S. and United Kingdom.

    Benjamin Brial, founder of Cycloid, said the Cycloid framework provides a lightweight approach to striking a balance between enabling developers to employ the tools they prefer and the need for centralized governance. The framework allows roles and policies to be pre-defined to ensure governance while service catalogs are used to deploy software using a set of drag-and-drop visual interfaces. There are also a set of management tools and features that provide additional visibility, automation, monitoring and financial controls to DevOps workflows.

    In effect, the portal that Cycloid provides to manage those workflows also serves to make DevOps more accessible to a wider range of IT professionals, added Brial.

    Cycloid

    Many organizations that embrace DevOps wind up building their own custom portal to achieve that same functionality. Rather than devoting resources to building and maintaining such a portal, Brial said Cycloid maintains and updates a portal platform that can be employed across any combination of tools that developers prefer. Other DevOps frameworks are often rejected because they require developers to adopt a specific set of tools, noted Brial. Without support from developers, it becomes nearly impossible to adopt DevOps best practices at scale, he added.

    After more than a decade of advocacy, adoption of DevOps within most organizations remains spotty. A significant factor in the lack of adoption is cultural issues involving skillsets. Many IT administrators lack the programming skills required to programmatically manage DevOps workflows. Cycloid is trying to establish a middle ground that enables IT operations teams to manage and govern DevOps workflows without having to acquire programming skills. The goal is to make it simpler for developers and IT operations teams to collaborate, said Brial.

    It’s not clear to what degree such an approach might increase adoption of DevOps best practices within enterprise IT organizations. However, it’s already apparent that the cost of hiring and retaining, for example, a small army of site reliability engineers (SREs) to manage IT environments at scale is often cost-prohibitive for many organizations.

    There’s no shortage of DevOps frameworks, but most organizations generally wind up crafting their own as part of an effort to tailor a DevOps workflow to meet their specific requirements. However, if there is a readily available framework that is highly customizable, Cycloid is betting more organizations would rather buy than build and maintain the entire framework themselves. Otherwise, DevOps teams would spend half their time performing the same repetitive manual tasks over and over, said Brial.

    One way or another, DevOps as a methodology for building and deploying applications needs to become more accessible. Proponents of DevOps have made a case for the methodology for the better part of a decade, with mixed success. The challenge continues to be finding a way to scale DevOps processes across the entire enterprise versus allowing each individual development team to define application development and deployment processes that, today, vary widely in terms of efficiency.

  • Using ML/AI to Support Infrastructure Monitoring

    Using ML/AI to Support Infrastructure Monitoring

    Successful infrastructure monitoring enables IT teams to ensure constant uptime and performance of their company’s systems. Technologies like machine learning (ML) and artificial intelligence (AI) benefit infrastructure monitoring by more quickly collecting and analyzing data from all of the hardware and software components that comprise the IT stack. Infrastructure changes are occurring faster than ever before, but complex systems, the unique nature of applications and lack of IT skillsets can cause challenges when integrating with these newer technologies. However, it’s more important than ever that sysadmins and DevOps teams understand how ML and AI can mitigate these roadblocks, support them in staying on top of infrastructure performance and rapidly address issues that arise.

    Intelligent Monitoring Support for Complex Systems

    The most tangible result of intelligent infrastructure monitoring tools and processes is near-immediate alerting of performance and uptime issues, which can then be addressed in an efficient and effective manner so no business interruptions occur. However, complex systems can stunt these benefits if ML and AI are not being used and manual monitoring protocols are still in place.

    Tools that use ML or AI lessen the work of IT staff immensely, freeing up critical business resources and aiding in overall productivity. Both technologies can automatically identify and update all IT stacks that comprise an enterprise’s infrastructure to keep systems up-to-date and aligned with established key performance indicators (KPIs). In addition, intelligent offerings can detect and factor those metrics against set standards so that early alerts to an “unhealthy” section of infrastructure can be identified, even as the IT stack is constantly changing. This drastically speeds up troubleshooting efforts.

    Differentiation in Applications

    The different applications supported by the various IT stacks will most often have unique service-level agreements (SLAs) for their performance and uptime, as well as remedies or penalties should those service levels not be achieved. Plus, system loads that stress the underlying infrastructure are frequently changed. For these reasons, it is important to identify what constitutes a “healthy” IT stack so that these minute parts of the infrastructure are not overlooked due to the variation involved.

    ML and AI can be programmed to track system baselines that support a “healthy” IT stack. These technologies are particularly great at finding novel and unusual patterns in data. As the monitoring and observability landscape becomes more complex over time, driven by real changes in how developers build applications and systems, the ability to spot and detect such patterns in data can be crucial in helping make sense of it, further cutting down efforts on manual searching, detective work and “death by dashboards,” which we’ve all experienced at one time or another.

    Supporting IT Team Skills with Intelligence Technology

    The role of sysadmins—and to a greater extent, developers—has shifted over the past few years to become nearly as complex as the infrastructure they oversee. Nowadays, it seems as though developers are required to have expertise in all aspects of infrastructure, from monitoring to Kubernetes to machine learning. This can take quite the toll on developers who possess such skills, but in a more realistic sense, developers that can do all these things are very hard to come by. The lack of these skillsets is pervasive in the industry, which is why ML and AI can be seen as supporting technologies—they can fill in these gaps, to an extent.

    With built-in intelligence and automation, ML/AI can enable even the most inexperienced sysadmin or DevOps professional to monitor complicated infrastructure like a pro, taking on most of the time-intensive work around collecting and analyzing the data and identifying where to troubleshoot. The main goal is to put humans in the driver’s seat, utilizing ML and AI for granular discovery of system issues, providing the metrics or charts that might be most relevant to IT staff as they troubleshoot their system and reducing the cognitive load of developers.

    With the vast benefits that intelligent technologies possess, integrating them into your IT stack can help mitigate challenges experienced with complex systems, application differentiation and the skills deficit experienced in the IT team. The important ingredient in making ML and AI effective in infrastructure monitoring is using tools that incorporate the right formulas, algorithms and automation that can best help determine success when it comes to your desired outcome.

  • Rocky Linux Emerges as a CentOS Replacement

    Rocky Linux Emerges as a CentOS Replacement

    Rocky Linux was created to offer the community an alternative following Red Hat’s recent decision to shift its focus away from CentOS—the open source version of Red Hat Enterprise Linux (RHEL). However, the Linux distro’s popularly can also be attributed to how its creator sought to offer a superior alternative based on lessons learned during CentOS’ development—and less as a perceived backlash to Red Hat’s controversial move, said Gregory Kurtzer, Rocky Linux’s creator, who is also founder and CEO of Ctrl IQ.

    “As one can probably imagine, there were a lot of lessons learned from the founding of CentOS—we did a lot of things correctly, but we made some mistakes, as well, that set into motion some of the difficulties the project went through,” said Kurtzer. “I was not—nor am I now—upset at Red Hat or anyone else. It’s important to understand that companies have a legal responsibility to do what they need to do. But I will say, this is why open source communities should not be controlled by a single company, especially if that company has a competing product to the open source project.”

    In addition to applying experience gained from the CentOS project to help “recreate the initial goals of CentOS in a new project,” Kurtzer said he was prompted to create Rocky Linux following Red Hat’s decision to end-of-life (EOL) CentOS. The move “affected my company, our customers, as well as the entire industry,” said Kurtzer.

    “To be blunt, my knowledge—in terms of doing it myself is severely dated. Luckily, after I made the announcement that I was considering recreating CentOS, thousands of people reached out to me wanting to be part of the project and contribute,” said Kurtzer. “From that, our development team and open source community was born.”

    Additionally, CentOS Stream offers value to the community by allowing “us and others” to take part in developing the upstream Enterprise Linux standard, said Kurtzer, who added that his team will continue to debug Rocky Linux so that solutions are properly integrated into the Enterprise Linux Standard.

    “The necessity was absolutely clear, so I founded Rocky Linux and the Rocky Enterprise Software Foundation (RESF),” Kurtzer explained. “Together with our contributors, sponsors and partners, we all have united for a common goal: to create an open source community that will provide us all with an enterprise operating system to stand the test of time, attrition and commercial agendas.”

    Interest in the development of a CentOS alternative was strong when Kurtzer first floated the idea of the project to the community. Since its release in June, the total number of ISO downloads is 56,000, according to Rocky Linux Tier0 mirror data.

    “We have zero visibility as to any other ISO downloads from any of our other mirrors, but if I were to guess, I’d say it would be about two to three times more, in total,” said Kurtzer. “When we all get a moment to breathe, it will be fun to see how many people are using Rocky Linux, and take in all the feedback the community has provided,” he said.

    With this team of developers,  Kurtzer said it took about seven months to build the general availability  (GA) release. “We didn’t just jump right into building the operating system because the goal was to create an infrastructure where many contributors and developers can take part without putting the security of the product at risk. Building that infrastructure took about four months,” Kurtzer said. “Once the infrastructure was completed, we spent about two months building the first-release beta candidate and then spent the following month ensuring that we did everything correctly.”

     

  • Copado Acquires Qentinel to Gain AI Testing Tools

    Copado Acquires Qentinel to Gain AI Testing Tools

    Copado has acquired Qentinel as part of an effort to incorporate AI-infused application testing within a DevOps platform and build applications using low-code tools across multiple software-as-a-service (SaaS) platforms.

    The Copado continuous integration/continuous delivery (CI/CD) platform was originally created to accelerate the development of low-code applications on top of the Salesforce platform. Now, however, Copado is expanding the scope of its DevOps reach to include other SaaS platforms.

    Andrew Leigh, chief marketing officer for Copado, said as organizations increase the number of SaaS platforms they employ in the wake of the COVID-19 pandemic, it quickly became apparent there would soon be a need to build applications that enable organizations to unify business processes spanning multiple SaaS applications.

    As part of that effort, Copado’s acquisition of Qentinel aims to advance that goal by making it simpler for both developers and end users to participate in the application testing process, Leigh said.

    Qentinel is accessed mainly via the cloud to automate the creation of application tests. Rechristened Copado Robotic Testing, the core of the Qentinel platform is based on the open source Robot Framework that understands scripts, executes them and generates logs and reports. A set of built-in libraries comes packaged with Robot Framework and addresses a wide range of testing scenarios. Qentinel customers include Brunswick, Elisa and Konecranes.

    Copado AI testing

    Gartner is forecasting that, by 2024, 75% of large enterprises will be using AI-enabled test automation tools to advance continuous testing across different stages of the DevOps life cycle. Much of the interest in AI-infused application testing tools is being driven by necessity as the pace of low-code application development exceeds the pace at which manual testing processes can work. As application testing becomes a bottleneck, organizations will naturally look toward automation platforms that employ machine learning algorithms capable of testing applications at scale.

    It’s not clear to what degree those platforms might eliminate the need for humans to test applications. The expectation is humans will be able to test application functionality at a deeper level versus, for example, merely checking to see if compliance mandates have been met. Many smaller organizations building low-code applications don’t have any meaningful application testing capabilities at all. Testing platforms infused with AI will prove to be especially crucial for citizen developers that require guidance to build a secure application that can actually scale, noted Leigh. The more SaaS application environments those applications span, the more critical testing becomes, added Leigh.

    One way or another AI is coming to application testing. After all, machine learning algorithms don’t ever need to take a day off or suddenly leave to take a better offer elsewhere. In fact, soon, most organizations soon won’t even consider a test automation platform that doesn’t have AI capabilities as they attempt to reduce the level of manual, monotonous and repetitive testing tasks. It may take a while for everyone to gain confidence in the algorithms, but it’s now more a question of the degree to which AI will be employed rather than if.

  • BMC Extends DevOps Reach from the Mainframe

    BMC Extends DevOps Reach from the Mainframe

    BMC today announced it has extended its DevOps platform for mainframe environments to provide integrations with GitHub Actions, a framework for managing workflows, and HCL Launch, a continuous delivery platform from HCL Software. BMC gained the DevOps platform with the acquisition of Compuware in June 2020.

    John McKenny, senior vice president and general manager for intelligent Z optimization and transformation at BMC, said those integrations—along with existing support for DevOps platforms such as Jenkins, GitLab and VS Code—make it possible to accelerate the development of applications that include mainframes as part of a larger distributed computing environment. DevOps teams, for example, can now employ an HCL Launch plug-in for the BMC AMI DevOps for Db2 tool to automatically capture and propagate database changes across IBM Db2 databases.

    At the same time, BMC also enhanced a BMC AMI Ops Monitor for Java Environments that automatically discovers all Java virtual machines (JVMs) running on z/OS environments on a mainframe. The BMC AMI Ops Monitor for Java Environments now includes the ability to discover the application programming interfaces (APIs) and services invoked by those JVMs.

    BMC also revealed today that its Workflow WiZard tool has been accepted as part of the open source Zowe initiative launched by the Open Mainframe Project. The Workflow WiZard makes it easier to install, configure and maintain software installed on mainframes running z/OS.

    Finally, BMC revealed it has extended its privileged access management (PAM) tools by enhancing the supervisor call screener and Unix System Service (USS) data enrichment capabilities of BMC AMI Security software. Based on technology BMC gained with the acquisition of RSM Partners, this enhancement increases the level of protection BMC AMI Security software provides to thwart attacks by surfacing suspicious activity, such as from malicious insiders that may have compromised administrator credentials, said McKenny.

    BMC mainframe

    These days, McKenny noted, everything is under attack because the minute cybercriminals discover a way to compromise one platform, they almost immediately try to apply that same technique against other platforms. Mainframe environments, which tend to process an organization’s most valuable data, naturally are a high-value target, added McKenny.

    In general, McKenny said IT organizations that rely on mainframes continue to make steady progress toward embracing DevOps best practices. A recent survey conducted by Forrester on behalf of BMC found 80% of respondents said their mainframe development tools needed significant improvement to provide more value.

    The need to accelerate digital transformation initiatives, which typically require access to data that resides on mainframes, are, in many cases, forcing the DevOps issue within many organizations. Software development teams that build mainframe applications are almost always required to create APIs that make it easier for other applications to consume that data.

    Not every organization, of course, has a mainframe. However, as digital business transformation continues to evolve, the number of applications that need to consume mainframe data will steadily increase. The challenge facing mainframe application management teams is finding a way to provide that access without using traditional waterfall processes to build the required APIs.

  • CircleCI CEO Sees Growing Need for Developer Experience Engineers

    CircleCI CEO Sees Growing Need for Developer Experience Engineers

    There is no shortage of titles to go with all the tasks that make up a DevOps workflow, but given the critical role developers now play within any organization, it might be time for organizations to start creating a developer experience engineer (DXE) function within DevOps teams that is specifically tasked with increasing developer productivity.

    CircleCI CEO Jim Rose said it’s become apparent there is more friction than ever in the application development and deployment process, as more complex applications are constructed, thanks, in part, to the rise of microservices.

    A DXE, as outlined in a report published by CircleCI, would be responsible for implementing a common set of DevOps principles, maintaining the right tools and putting in place a cohesive set of standard processes that ensure developer success. Today, there are simply too many languages, frameworks, engineering styles and processes being employed within the same organization, and that conspires to reduce overall developer productivity, said Rose.

    While software engineers are, today, addressing subsets of these issues, Rose said the time has come to assign these tasks to an engineering team that views itself as an advocate for developers by making available more responsive infrastructure.

    As organizations of all sizes increasingly realize how dependent they are on software to drive digital business transformation initiatives, Rose noted that developer productivity is becoming a major corporate issue. Revenue forecasts and profit margins are now being directly impacted by the rate at which software is being delivered and updated.

    Software engineers today routinely build DevOps pipelines for developers, but not much time and effort is put into optimizing the developer experience, noted Rose. That’s become not only a major productivity issue, Rose said, it has a material impact on the ability of organizations to attract and retain developer talent. One of the reasons so many developers prefer to work for smaller startups than large enterprises is because their daily work experience is simply better. Large organizations need to reduce the amount of friction developers experience if they want to be able to compete for that same talent, said Rose.

    A DXE would also be more inclined to solicit input from developers on tool selection to best optimize productivity, noted Rose. Many software engineers today construct pipelines with little to no regard for how simple or hard it might be for a developer to employ tooling.

    Organization today are, of course, starting to become more obsessed with measuring application development velocity. However, in many cases, simply making someone responsible for achieving a goal is going to result in more gains at a lower cost. Analytics tools have a role to play, but obsessing over key performance indicators (KPIs) may not generate the same result as quickly as simply giving an engineer a specific mandate.

    As responsibility for application management continues to shift left toward developers, it should not come as a surprise that there is a lot more interest in automating the underlying infrastructure. The issue, at this point, is determining to what degree software engineers are going to achieve that goal versus forcing developers to seek out yet another platform that promises to do it on their behalf.