devopsy.kinsta.cloud

Category: Enterprise DevOps

Empowering DevOps With Cloud Desktops

Today’s organizations need to enable their IT teams to rapidly deploy, manage and maintain their applications and services. This is a primary driver behind the growth in adoption of DevOps. By uniting the IT operations and software development teams, organizations are helping to provide continuous delivery and accelerating the systems development life cycle.

At the same time, the chronic cyberskills shortage makes it hard for organizations to find the talent they need to hire and collaborate with. The cloud, and specifically cloud desktops, can address many of these challenges and help organizations get the most bang for their buck when it comes to their DevOps teams. In fact, the two technologies have a symbiotic relationship.

DevOps Hiring Challenges

Due to the shortage of individuals with key skills, organizations are facing a significant challenge these days as they try to find the right developers. In fact, a recent report by the Linux Foundation and edX finds organizations are searching for more people with open source DevOps skills (65%) than developers (59%) for the first time.

It is possible, in some instances, to hire remotely, but there are potential snags. For instance, hiring people in another country will likely entail a visa process that can take several months to complete. And collaboration with external project partners can create project bottlenecks that inhibit productivity.

Once the people you need have been hired, the onboarding process begins. Getting new hires settled in a workflow and procuring and shipping the laptops or workstations they need takes at least a couple more weeks before they can even begin to become productive. But organizations want to be able to hire developers anywhere they can find the right people and they need them to be productive within hours, not weeks or months.

Collaboration Woes

DevOps teams cannot function without collaboration, but this, too, can be difficult – particularly if those teams are geographically dispersed. Developer teams have attempted to solve this problem by adopting a variety of technologies, such as legacy VDI solutions, VPNs for remote work, physical workstations connected over a WAN and more. These technologies have helped solve some of the problems, but they’ve also introduced a host of other issues that negatively affect productivity and increase cost and complexity. That includes lack of performance, unreliable user experience, IP security concerns and data management problems.

Cloud Desktops: A New Approach

In light of all that isn’t working, it’s clear that a new approach is needed. Cloud desktops offer many advantages when it comes to addressing some of the key challenges DevOps teams face. For one thing, they make onboarding much easier. By using cloud desktops and workstations, all that the new, talented software developer needs is a device and an internet connection, and they instantly become a part of the development team. This resolves another headache that consumes unnecessary IT resources.

Shipping and hardware preferences are no longer an issue with the cloud desktop model. There is no more shipping, no more maintenance overhead, no more Windows-versus-Mac debates. Now, developers can pick the device they want, depending on their role requirements. They can even use smartphones and tablets in docking stations instead of laptops to connect and work in the fully configured and secure cloud desktops.

Benefits for Developers and Testers

Because cloud desktops support multiple desktop images, they are ideal for DevOps teams. For developers, this means that they can have multiple desktops, all with differing versions, all kept separate. This is great news if you don’t want to have to keep reimaging a physical device.

Giving a developer a persistent desktop is one option that cloud desktops enable. Another option is the ability to give the developer a brand-new, “clean” cloud desktop every day (non-persistent). For enterprises, this means they can control the developers’ IDE so code leaks don’t happen from one release to the next, intellectual property is better protected and they can enforce stronger overall data security.

Testers benefit as well, as they know they’ll have a totally clean, brand-new cloud desktop every day. This allows them to test and test again in isolation, knowing nothing was left behind from a previous test. In addition, the right cloud desktop enables anytime, anyplace collaboration; geographic limits become a thing of the past.

Empowering DevOps

The speed and agility of DevOps have made it a mainstay of software development, but certain criteria must be met for it to succeed. Its premise is faster delivery times, but companies cannot provide continuous delivery if they don’t have the skilled DevOps talent they need. Once they’re recruited and hired, provisioning often takes up more valuable time.

With the clock ticking, organizations need to select skilled individuals, regardless of their location, and get them working and collaborating as quickly as possible. Cloud desktops address both of these challenges. In addition, they improve the user experience compared to typical VDI solutions – even for compute-heavy users. Cloud desktops increase time-to-productivity, too. As you equip and add to your DevOps team, consider the benefits of adding cloud desktops to the mix.

April 12, 2021
Continuous Testing: The Quest for Quality at Speed

The DevOps goal to reduce lead times by accelerating software deliveries presents a serious challenge for assuring the quality of the software that is delivered. As I indicated In my SlideShare post, “The Quest for Quality at Speed,” testing activities span end-to-end software value streams and often account for more than 50% of bottlenecks.

The answer to these DevOps testing challenges is referred to as continuous testing (CT), which is more than simply automating tests. My blueprint for continuous testing identifies eight pillars of practices, each with strategies to reduce bottlenecks. In this article, I enumerate the strategies for each of the eight pillars of continuous testing and explain how to approach implementation for greater adoption of CT across an organization.

Continuous Testing Pillars

Continuous Testing Tenets

There are five tenets which are guiding principles that enable continuous testing:
• Shift Left: Conduct each test as early in the pipeline as possible.
• Fail Early: Arrange the tests so the most likely problems are found during the earliest possible stage in the DevOps pipeline.
• Fail Often: Run tests frequently and with many different conditions.
• Test Fast: Arrange tests to run in quick cycles.
• Be Relevant: Focus on the most important tests and results.

Leadership and Culture

Leadership and culture practices have a major impact on influencing behaviors and habits of everyone involved in testing across the DevOps value stream. Bottlenecks to CT include inadequate funding of testing due to lack of quality vision and goals at the executive level, and bottlenecks caused by distrust and lack of cooperation between Dev, QA and Ops. Executive sponsors need to clarify the definition of quality for the organization, and emphasize quality’s importance. Executives can communicate the vision and goals for quality and establish incentives that foster a culture of collaborative behavior.

Test Strategies and Plans

Test strategies and plans are needed to guide testing approaches for each product/service pipeline. Bottlenecks to CT include confusion caused by lack of product/service test strategies, and unplanned testing activities and resources are not included sufficiently in planning process. It is important to establish test coverage standards, test case standards, gate criterion and planning process that include testing requirements. CT strategies include making sure test coverage requirements are defined, all types of tests required are identified, allocate tests that are required at input gates, indicate test results are required at output gates and enforce that test tasks are included in planning backlogs and sprints.

Test Management

Test management is needed to coordinate testing resources and test schedules. Bottlenecks to CT include poor utilization of test resources due to lack of visibility and schedule bottlenecks due to lack of coordination of test schedules. It is important to have a database of tests and test resources, and test scheduling tools. CT strategies include version management of tests and resources, an inventory of test resources and dynamic test scheduling.

Test Automation

Designing, creating, selecting and executing tests in an automated fashion to get to a verdict as fast as possible is the primary strategy to accelerate testing. Bottlenecks to CT include slow test creation, slow test execution and slow time to realize verdicts. It is important to have effective automation strategies for test design, test creation, test selection, and test execution. CT strategies include test design templates, advanced test creation tools (E.g., TDD, keyword, behavior, model-based), dynamic test selection, tests designed for fast verdicts and horizontal and vertical scaling tests.

Test Tools

Test tools are designed to automate specific types of tests and integrate with DevOps platforms through APIs for orchestration, execution and reporting. Bottlenecks to CT include test tools that are not designed to scale, limited test configurations and lack of complete APIs, which make integration with DevOps platforms inefficient and error-prone. It is important to have scalable test tools with good APIs. CT strategies include limiting the selection of test tools to ones that are DevOps-ready or DevOps-native and that have well-defined, stable APIs.

Test Environment Management

Scheduling and setting up resources into the needed topologies for running different types of tests for developers and testers can be a major bottleneck if not managed efficiently. Bottlenecks to CT include lack of test resource scheduling, which causes conflicts for resources, manual test setups, which are time consuming, causing long wait times for testing and delayed retesting. It is important to have test resources scheduling, test environment orchestration and resource utilization management. CT strategies include test environment inventory tools, test environment sharing tools, test environment orchestration tools and monitoring test environment utilization.

Test Results Analysis

Reporting and analyzing test results can be a major bottleneck after test execution is completed. Bottlenecks to CT include poorly written tests which can report confusing results and that take a lot of time to analyze. It is important to have design standards for test results and test results reporting standards. CT strategies include test verdict design in test cases, common test reporting tools and test analysis tools.

Steps To Implement Continuous Testing

Start with one or two services and a small set of critical CT practices, then expand to more services and more advanced CT practices.

A gap assessment is a great way to determine the current state of CT practices, and will help focus the implementation plan. Given a list of practices from each of the pillars in the continuous test blueprint, a cross-functional team of developers, testers and ops people can assign scores to measure importance and current level of practice to generate a gap score. The combined set of gap scores will give guide and direct current priorities for the CT plan.

For example, beginning CT priorities could be to establish a strategy sponsor, define quality goals, obtain an inventory of test resources and requirements, put in place version management for tests and test standards, tool selection and test refactoring to match the standards.

An intermediate CT goal could be to complete tool integrations with DevOps platforms, automate test scheduling, orchestrate test environments and optimize test results reporting.

With maturity, advanced CT goals could be to put in place advanced test creation strategies, accelerated test execution, automated test environment management and optimize test results analysis.

What This Means

Testing activities are typically a major source of bottlenecks that slow the quest for quality at speed. Continuous test strategies that accelerate all aspects of testing can have a major impact on speeding up lead time for continuous delivery of quality software. Implementation strategies that start by applying specific continuous test strategies to a targeted small number of applications, and then expand to more advanced strategies applied to more applications is an effective approach to CT adoption across the organization.

April 9, 2021
How lulu Became a Lemon: A Digital Transformation Fail
Many people sometimes have a tough time figuring out what exactly digital transformation is and why it’s so important. I want to tell you a real-life story of how a once-respected brand, lululemon, has failed the digital transformation journey and, as a result, may fail in a new retail landscape.

The story starts innocently enough with my desire to get my wife a lululemon gift card for her birthday. She has gotten her vaccines and is returning to the gym, so I figured it was a great time to get new workout clothes. I purchased a gift card on March 15 to be delivered via email a few weeks later on her birthday. It was a simple digital transaction that for any company that has its digital transformation act together would be a no-brainer. Well, this is where lulu turns off the tracks and turns into a digital lemon.

On the day of my wife’s birthday, I had planned that she would wake up and see how thoughtful I was in getting her the gift card. She didn’t say anything about the card, though, so I finally asked if she received the gift card. She didn’t know what I was talking about. I had her check her spam folder, nothing. Nope, no gift card.

Thus began a day that would see me reach out and communicate with the lulu team no fewer than six times. It seems that lulu uses a third party for digital gift cards. Each time I reached out to a lululemon “educator” (that is what they call them, and did I get an education), I was told a different story:
1. A simple apology and card being emailed, give it an hour.
2. Sorry, it must be that email address, do you have another email address? Give it an hour.
3. Hmm, seems our third-party gift card provider is having problems today.
4. We located your card, it was sent to: tlaynguyen@gmail.com could I check that email? (I would love to, but that isn’t an email address I have.)
5. Well, we have no control over when the third party sends emails.
6. Digital gift cards are non-refundable, even if you didn’t receive it. Sorry, can’t help you.
7. You have blocked our emails from your computer.
At this point I realized that lululemon, while maybe making great workout gear, is analog to the core. A simple digital transaction like this had them tied in knots, wasted hours of my time and so turned off my wife that she is looking elsewhere for her new workout gear.

This past year has taught us that retailers that can’t hop on the digital transformation train are heading for the precipice. It seems as though lululemon may have already gone over the deep end. The company better hope the malls fill up quickly because in a digital world, lulu is truly a lemon.
April 7, 2021
Languages and DevOps: Network

It is fun to discuss the changes in network operations over the last couple decades. We’ve come full circle, and, honestly, ended up in a better place. Network specialists were super command-line wizards who kept us going, with few GUIs in sight. Everyone thought the next iteration would be GUIs, so network operations could be accessible to more than a few command-line specialists. “Everyone” was mostly right; we did head in that direction. It was optional, and many network operations friends pointed out that you could still do more, faster with the command line. Before GUIs had the opportunity to catch up with command lines, though, automation came along. And then DevOps. And finally,* configuration-as-code. Pretty quickly, the ability to do everything through an individual product’s GUI was determined to be a weakness. Network operations personnel were dealing with more vendors to handle the networkification (it is too a word! I just made it up) of common development activities, like some aspects of security. And now, APIs and command lines rule the juncture of DevOps and networking.

*Finally – so far, at least

And that shows in languages. Shell scripting and Python run this show, with little competition from any other language. We could get into a massive discussion about whether shell scripting is programming, but we won’t, because at least in networking, it most definitely is considered to be programming.

One time, when we were tracking down a problem that involved all of IT, I was sitting with the serious network geeks and marveling at their ability to make everything they wanted happen from the command line in an instant, and their ability to parse command output. I’m no slouch when it comes to networking, but they easily put me to shame. I got to chatting with a few of them, and the consensus was that they loved computing but hated programming. Networking made sense to them. This explains why networking DevOps people are continuing to use Shell scripting and adopting Python at the same time.

Python and Shell

Shell is a given in networking. There are a lot of extant Shell scripts for doing all sorts of things, and the need to automate to keep up with Agile makes shell scripting a logical choice.

Python enters the picture because it is “common ground.” It is intuitive enough for most networking people to do what they need to get done, and known or knowable to most developers. When it comes to usage, Python has overtaken Shell; (don’t take my word for it, check out the excellent work of the NetDevOps survey on GitHub, or just glance at the graphic below, created by them) in fact, Shell and Python command so much of the network development space that you are probably better off just making sure you’ve got those down, and focusing your free time on other issues like completely different networking commands, or even skills for data center versus cloud. The ROI would be better.

But Wait, There’s More

The key operational changes recently have been around GitOps and reporting back into the DevOps toolchain. People no longer want your appliance or application to have a pretty GUI, they want it to report in to the tools that provide automation and a larger-picture GUI. Many vendors are there already, but many are not yet. That creates a need for tools – products, open source projects, or internally developed – to do that integration while waiting for the vendors to catch up. These, again, are well-served by Python, though other languages that can handle APIs are viable, too.

We’re headed for a world where systems detect anomalies and react to rectify them, but we’re not there yet – not on a strategic scale, at least. And we probably won’t be for some time, as automating massive network changes is a scary proposition and will take time to use these systems for detection, monitoring what they could have done, before organizations are willing to let them “just do it.”

Carry On

Meanwhile, NetDevOps is getting folded into DevOps proper, and in many organizations, using infrastructure-as-code or GitOps, is being deployed and managed like any other part of the life cycle. So we are moving along. For my network peeps, your job will continue to change, but it certainly won’t go away. You’re essential to smooth-running systems, and while the network may become even more virtual, it will still be networking. And under that virtual network will be … a physical network. So keep kicking it, and carving a path from users to apps, while protecting those apps and ensuring they have adequate resources. Oh, and if I spin up another instance at midnight, you’ll hop on and make sure it’s got traffic directed to it, right? RIGHT?!

April 7, 2021
DevOps Skills Increasing Among Salesforce Developers

A survey of 521 attendees at a recent online Future of Salesforce DevOps Summit event hosted by Gearset, a provider of a continuous integration/continuous delivery (CI/CD) platform for Salesforce developers, found just under half (47%) of respondents now release software at least multiple times a week, with another 29% releasing software weekly or biweekly.

More than half of respondents (52%) also noted they now can deploy software in less than an hour.

Gearset CEO Kevin Boyle said the survey suggested the level of DevOps maturity among developers building applications on top of the Salesforce software-as-a-service (SaaS) platform is increasing rapidly. In the wake of the COVID-19 pandemic, many organizations embraced SaaS platforms to accelerate their digital business transformation initiatives rather than building entire applications from scratch.

However, the biggest benefit cited by survey respondents was not the ability to release applications faster, but rather the improvements to application quality (77%), followed by increased productivity (69%) and enhanced collaboration (46%). Other benefits cited included reduced complexity thanks to automation; increased agility; more reliable releases and time and cost savings.

Overall, the survey identifies source code control, CI/CD, unit testing, change monitoring and backups of metadata and data as being the most widely implemented DevOps capabilities that have been adopted. Over the next 12 months, capabilities that will see the most increased adoption among survey respondents include CI/CD, static code analysis and sandbox seeding with data.

Survey respondents said their top obstacles to adoption of DevOps are ramp-up time, followed by difficulties adopting source control and a perceived steep learning curve. For many organizations that have adopted Salesforce, the intimidation factor when it comes to adopting DevOps best practices is still fairly high, Boyle noted.

Most recently, Gearset added a free training platform, dubbed DevOps Launchpad, that employs gamification techniques to make DevOps more accessible to developers. Topics covered include version control fundamentals, Git branching strategies and Salesforce backups.

Gearset counts McKesson, Zillow, Traction on Demand, Intercom, Accenture, IBM and Johnson & Johnson among its customers. It’s not clear to what degree appreciation for DevOps has risen among smaller companies. However, as the number of custom applications deployed as extensions to the Salesforce platform increases, it is apparent that manual processes for building and deploying applications will not scale. The Salesforce platform itself is uniquely constructed using a set of objects and tables that generally lead organizations to adopt a DevOps platform built for that environment. However, it is possible to build and deploy applications using a DevOps platform designed for building and deploying applications that might need to span multiple platforms. Those applications would be integrated with the Salesforce platform at an application programming interface (API) level.

Regardless of how custom applications are built and deployed, it’s clear Salesforce platforms are becoming more widely used in enterprise IT environments. Each DevOps team will need to determine how best to integrate those platforms within the context of their overall DevOps strategy.

April 6, 2021
Enterprise ML Investments on the Rise

The second wave of enterprise artificial intelligence and machine learning (AI/ML) adoption is building, and is expected to crest in 2021, as many organizations increased and accelerated their investments in tools and people.

That was one of the unmistakable conclusions of our 2021 enterprise trends in machine learning report: 83% of the companies we surveyed said their AI/ML budgets had increased year-over-year, and we found that the average number of data scientists they employ has increased by 76% year-over-year. These changes came even as many organizations tightened their overall spending and refocused their strategic priorities amidst all of 2020’s disruption and uncertainty related to the COVID-19 pandemic. These companies aren’t simply moving forward with their AI/ML initiatives in spite of the pandemic; they’re doubling down on their investments because of it.

Many organizations have begun to understand just how critical ML is to remaining competitive in uncertain and rapidly evolving conditions. When we ran a separate survey during the summer of 2020 to find out how businesses adapted to the pandemic’s impacts, it revealed a renewed sense of urgency around AI/ML investments: 43% of respondents said that AI/ML mattered “way more” to their business than they’d previously realized.

Our independently conducted 2021 report included input from more than 400 leaders and practitioners across a diverse mix of technical and business functions, all of whom have a stake in their organization’s AI/ML strategy. They’re not just increasing their spending and staffing, either – they’re accelerating their pursuit of a growing number of enterprise ML use cases, with customer experience and automation leading the way.

You need to be doing this, too. The second major wave of enterprise AI/ML adoption is underway, and you can still capitalize on the immense opportunities ahead. But the time to act is now. Organizations that take a “wait-and-see” approach are at risk of being left behind, particularly as so many other companies are scaling up their investments. Not only are your competitors increasing their AI/ML budgets (evident in the 83% YoY increase mentioned above), but they are moving their initiatives to the top of their strategic priority lists. Approximately three out of every four respondents (76%) in our 2021 report said they are prioritizing AI/ML over other IT initiatives, with 28% reporting that it is their top priority overall. These companies have realized that their success is directly tied to their ability to adapt to rapidly changing business conditions — and that AI/ML is the key to doing so.

This is no longer the sole purview of elite technology companies. Companies of all sizes, across just about every industry, can get up and running with AI/ML, thanks in large part to the spread of easy-to-use tooling. The opportunities are more accessible than ever. You don’t need a ton of time or resources to get started — and it’s absolutely crucial that you do so soon.

Your competitors are actively pursuing AI/ML initiatives today, regardless of your specific industry. We’re seeing many longstanding enterprises begin to drive huge transformations of their businesses and industries with AI/ML. More and more use cases are being pursued in legacy industries, from insurance to agriculture, healthcare to financial services and more. The bellwether financial firm JPMorgan Chase, for example, has even built an entire AI research program and data platform. There are virtually no industries where this is irrelevant. So, you need to act with urgency, as this second wave of enterprise adoption intensifies.

You also need to build for operational efficiency and scale. We think of this as industrializing your machine learning operations (MLOps). While easy-to-use tools reduce the barrier to entry, they only get you partway to your destination. Invest in repeatable, automated processes or you’ll hit a wall of technical debt and other potential issues. MLOps paves the road to tightly integrated, well-aligned technology stacks, processes and teams that make it easier, not harder, to deploy more models in the future. This isn’t something you can wait on; if you’ve manually bootstrapped the deployment of even a handful of models to production, you need MLOps. Without it, you’ll quickly accrue unnecessary technical debt that will inevitably hinder your organization’s ability to scale and deliver meaningful business value.

This is already a significant issue. Our 2021 report found that, while many organizations are increasing budgets and prioritization, it’s taking them longer to get models into production. Data scientists are still spending too much of their time on operational tasks, a problem that worsens as the number of models in production increases. This tells us that even as many organizations increase their spending and hiring, they’re actually allocating more of their growing resources toward manually scaling their AI/ML initiatives instead of investing in the operational efficiency that will maximize results.

There’s a better way. Organizations no longer need to take a DIY approach to MLOps. There are robust solutions that can simplify many of the complex issues involved in scaling your AI/ML initiatives in production. Our report found that companies that use third-party MLOps solutions see improved outcomes compared with companies that go it alone and build and maintain everything themselves. They spend less on infrastructure, deploy models to production faster and tie up less of their data scientists’ time on model deployment.

The pattern here is clear. Regardless of your particular industry, more and more businesses are identifying a growing list of use cases for AI/ML that can help transform their businesses and boost their competitiveness. They’re industrializing their AI/ML initiatives with MLOps to ensure their technology stacks, processes, and people are well-aligned. And, by doing so, they’re positioning themselves to rapidly adapt to and act on changing signals in their businesses.

Don’t make the mistake of thinking AI/ML doesn’t apply to you or your industry. Doing so would mean missing out on potentially massive strategic opportunities, from new or growing revenue streams to increased efficiencies throughout your business operations. Your competitors are doing it; it’s easier than ever to get started and third-party MLOps solutions can help minimize technical debt and other operational complexity that will otherwise limit the positive business impacts of your initiatives.

You can absolutely get in on the second wave of enterprise adoption, but the time to act is now. You can’t afford to wait.

April 6, 2021
BMC Tightens Integration Across DevOps Tools for Mainframes

BMC has extended its BMC Automated Mainframe Intelligence (AMI) and BMC Compuware portfolios as part of an ongoing effort to make mainframes just another platform for DevOps teams to build and deploy applications on.

John McKenny, senior vice president and general manager for Intelligent Z optimization and transformation at BMC, said the DevOps technologies that the company gained last year with the acquisition of Compuware have now been fully integrated with the rest of the BMC mainframe portfolio.

The BMC Compuware continuous integration/continuous delivery (CI/CD) platform has been integrated with Visual Studio Code, a free tool from Microsoft that is employed widely by developers, he added.

The BMC Compuware ISPW solution integrates with Visual Studio Code to enable developers to compile changed code on the mainframe with a right-click.

In addition, the BMC Compuware Topaz platform for applying DevOps practices to the development of mainframe applications has a new command-line interface (CLI) along with support for multiple application programming interfaces.

A BMC Compuware File-AID 21 tool now makes it possible to reduce the time required to search billions of transactions and log files on a mainframe, while the BMC AMI Security tool has been integrated with the BMC Helix IT service management (ITSM) platform.

Finally, the BMC AMI Ops Insight tool has been updated to provide diagnostic capabilities to more easily identify the probable cause of an issue, while the BMC AMI SQL Performance for DB2 tool now includes a plug-in for the open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

McKenny said the goal is to integrate mainframes with any DevOps workflow as part of an effort to either deploy new applications or modernize legacy applications already running on the platform. Modernization of mainframe applications is being driven by the need to add application programming interfaces (APIs) to mainframe applications that need to be integrated with a much broader array of distributed applications, he noted.

Much of the demand for those APIs is being driven by digital business transformation initiatives that require applications to be able to access backend transaction processing and analytics applications running on mainframes, added McKenny.

It’s not clear at what rate IT teams that build and deploy applications on mainframes are moving away from waterfall-based processes to embrace best DevOps practices. However, McKenny noted, the rate of changes being made to mainframe applications has accelerated significantly over the last few years.

While large numbers of applications have been migrated off mainframes over the last decade, the number of enterprise IT organizations that continue to rely on the venerable platform to process transactions remains considerable. Many organizations aren’t convinced that it’s worth rewriting the applications they have relied on for decades when it’s easier to make them more accessible to other applications by adding an API. In effect, McKenny noted, mainframe applications are becoming just another microservice that can be invoked by a developer.

Regardless of the motivation, it’s clear mainframe applications will continue to run well into the next decade. The challenge IT teams now face is finding a way to make those mainframes just another platform on which to deploy applications at the end of a DevOps toolchain.

April 5, 2021
AlmaLinux Foundation Delivers on CentOS Promise

A nonprofit organization launched this week to oversee future development of AlmaLinux, a distribution of Linux based on code originally contributed to the open source CentOS project.

At the same time, CloudLinux, which created AlmaLinux in response to a decision by Red Hat to pull financial support for CentOS, announced that a stable version of the operating system is now available. CentOS itself was based on the Red Hat Enterprise Linux (RHEL) distribution that is made available via a subscription.

Jack Aboutboul, community manager of AlmaLinux, said AlmaLinux is the result of the $1 million that CloudLinux committed toward creating a distribution of Linux based on a CentOS project used by hosting providers, such as CloudLinux, to run RHEL-compatible applications at a lower cost. AlmaLinux OS is a binary compatible fork of RHEL 8, which the foundation pledged to update to maintain that compatibility.

AlmaLinux is one of two distributions based on CentOS that have been created. The other, RockyLinux was created by Gregory Kurtzer, one of the original creators of a CentOS project. Red Hat, in the meantime, has moved to make RHEL subscriptions available for free to individual developers.

Aboutboul said AlmaLinux is more mature than RockyLinux, because it is based on a Linux distribution that has been battle-tested by IT service providers. AlmaLinux also added a SecureBoot capability as well as support for VMware and the Amazon Web Services (AWS) public cloud, noted Aboutboul.

The AlmaLinux Foundation also decided to publicly share errata about the ongoing development of the operating system, to make it easier for IT teams to troubleshoot issues that might arise in a production environment.

It’s not clear yet how much support either AlmaLinux or RockyLinux have. However, at this juncture, forks are becoming fairly common across the open source community. Those disruptions, however, don’t seem to be dampening enthusiasm for open source software. A global survey of 1,250 IT leaders conducted by Red Hat finds nearly 80% of respondents expect to increase their use of emerging open source software technologies over the next two years, with the top three use cases being infrastructure modernization (64%), application development (54%) and digital transformation (53%).

As Winston Churchill famously said, democracies are messy, and the open source community is no exception. Passions run high. At the same time, the various business models that spring up around open source projects often conflict; because of animosity, greed or differences of opinion, it is not uncommon for multiple forks of an open source project to emerge and evolve over time.

Despite that issue, IT organizations remain committed to open source for two primary reasons. First, no one needs permission to download open source software to a laptop. That enables developers to more easily experiment with new technologies. Second, cost. Many IT organizations prefer to use free open source software, rather than paying to license commercial software. They may one day pay for support, but the number of open source software users still dwarfs the number willing to pay for support; especially since knowledge and expertise is freely and equally shared across a growing open source community.

Given those benefits, any friction in the open source community itself is largely seen as an acceptable risk and just the potential cost of doing business.

April 2, 2021
Red Hat Survey Reveals More Confidence in Open Source

A recent Red Hat survey revealed how DevOps teams increasingly depend on open source to support their shift to cloud-native environments and digital transformations, and to maintain security in these highly distributed environments.

Based on a survey of 1,250 IT professionals, Red Hat maintains that the survey respondents — from organizations that were Red Hat customers — were unaware that Red Hat sponsored the study to help avoid “biased or influenced responses,” Red Hat said in a statement.

During the past two years, the number of organizations that deemed open source necessary for their digital transformations increased 11% to 53%, representing the majority of the respondents’ organizations.

The vast majority (87%) of the respondents considered open source to be “more secure” than or “as secure” as proprietary software, while 84% indicated that enterprise open source “is a key part of my organization’s security strategy.”

While the survey reflects open source’s importance for security for IT professionals in DevOps, its support of the overall business mission is key, as well, says Momodou Jaiteh, application security consultant at nVisium, an application security provider.

“Information security is about reducing and mitigating risk to enterprises, from technology, people and process perspectives. It helps enable the business to operate securely in the best interest of its shareholders and customers,” Jaiteh said. “Thus, security typically plays a supporting, [but] nonetheless critical role in the success of the business, especially in a digitally connected world.”

Open source software often helps businesses reduce overhead cost in delivering services to their customers through reduced time to market, Jaiteh said. One major additional advantage is “visibility and input from a lot of different people,” Jaiteh added.

“Greater visibility often translates to more observing eyes on all aspects of the open source software, which often translates to better security. This is even better for mission-critical software that deals with sensitive information, such as cryptographic algorithms, etc.,” Jaiteh said. “It is not a surprise to see open source used more in infrastructure modernization, because as we move to DevSecOps models of software delivery, infrastructure often is the bottleneck. Therefore, solving for infrastructure helps developers focus on aspects that are unique to their business.”

While survey respondents ranked improving collaboration between IT and business stakeholders to achieve a digital transformation as their highest priority, implementing cloud technologies or infrastructure ranked second. Infrastructure modernization is thus seen as a prerequisite for a full digital transformation, said Dirk Schrader, global vice president, security research at New Net Technologies (NNT), a cybersecurity and compliance software provider.

“Open source plays a vital, pivotal role in almost all digital trends driving any industry sector today,” Schrader said. “Cloud computing or containerization is rooted in open source technology, many development libraries are open source, and the market for open source solutions has been a model for servitization; the changes in one’s business model away from selling a product to selling a service, or an integration of service, and product that focus on additional value-add for the customer.”

For security, the main advantages consist of being able to review, inspect and audit “each and every piece of code,” Schrader said.

“The ability of open source to be a base for services makes it the natural companion for any digital initiative,” Schrader said.

April 1, 2021
Linux Foundation Takes Control Of AsyncAPI Specification

The Linux Foundation announced today that it now plays host to an AsyncAPI Initiative that has developed a specification and a suite of open source tools for asynchronous application programming interfaces (APIs) and event-driven architectures.

Founding sponsors of the AsyncAPI Initiative include Ably Realtime, Apideck, Bump, IQVIA Technologies, Slack, Solace and TIBCO. Most recently, Postman, a provider of API management tools, committed to providing engineering resources to the project as well.

AsyncAPI provides a language for describing the interface of event-driven systems, regardless of the underlying technology, and supports the full development cycle of event-driven architecture. That approach helps unify documentation automation and code generation, as well as managing, testing and monitoring asynchronous APIs.

Chris Aniszczyk, CTO and vice president for developer relations at the Linux Foundation, said the Linux Foundation will work with the member organizations to facilitate a governing framework similar to the frameworks other open source projects have adopted under its auspices.

In general, reliance on event-driven architectures is on the rise thanks, in part, to the rise of digital business process initiatives that require the processing and sharing of data across multiple platforms in near-real-time. The AsyncAPI Initiative makes it simpler for disparate event-driven platforms to be integrated. It’s unlikely multiple organizations involved in a digital business initiative are ever going to standardize on the same event-driven platform, so an AsyncAPI specification provides a critical linchpin.

Usage of the AsyncAPI Initiative is already fairly widespread, with Adidas, PayPal, Salesforce, SAP and Slack all employing it in production environments. In fact, the Linux Foundation cited research that identified AsyncAPI as the fastest-growing specification being implemented by developers, after seeing adoption rates in production environments triple from 2019 to 2020.

Event-driven IT architectures have, of course, been around for decades. However, as they have gained traction in the modern era of software development, the need for the equivalent of a REST API for asynchronous communications between platforms, based on different event-driven architectures, became apparent. The AsyncAPI doesn’t replace the need for other types of API specifications, but Aniszczyk noted that, over time, it will soon player a larger role, especially as cloud-native application environments become more distributed and the number of use cases that can’t be addressed using traditional batch-oriented techniques continues to rise.

In the meantime, the number of providers of event-driven platforms based on proprietary architectures spans vendors ranging from Oracle and IBM to cloud service providers such as Amazon Web Services (AWS). At the same time, open source messaging platforms such as Apache Kafka are starting to have a significant impact on how IT teams build their own event-driven platforms.

The level of enthusiasm for an API specification that makes all those platforms more interoperable than they would otherwise be is unclear. However, as modern IT platforms continue to evolve, more IT teams are becoming aware of the crucial role API specifications play in preventing them from becoming locked into one platform.

March 30, 2021