devopsy.kinsta.cloud

Tag: feature-flagging

  • How Healthcare Companies Can Optimize Software for Improved Patient Outcomes

    How Healthcare Companies Can Optimize Software for Improved Patient Outcomes

    Healthcare companies are more reliant than ever on software to help them achieve good patient outcomes. Recent research reveals that the use of software as a service (SaaS) solutions is growing exponentially in health care, covering a wide range of areas including:

    • Patient diagnosis
    • Medical imaging
    • Therapy and patient self-care
    • Data collection and analysis
    • Hospital management

    Due to the increased use of digital products in patient care, healthcare providers recognize the need to speed innovation and fundamentally rethink how they build software. This has led many engineering teams to move toward continuous integration and continuous delivery (CI/CD) when building and deploying software.

    Considering the industry’s emphasis on improving patient experiences, it makes sense that healthcare providers are keener than ever to optimize their systems. In fact, around 90% of healthcare providers are implementing or already using customized software solutions and development.

    As teams look to improve these critical processes in software development, feature flagging is one way to speed up development and optimize software performance in the healthcare industry.

    CI/CD Challenges for Healthcare Companies

    The healthcare industry faces unique challenges when applying DevOps strategies such as CI/CD.

    Intense Regulation

    The main problem is that, for obvious reasons, health care faces stringent regulation and oversight. A high level of scrutiny is necessary in an industry in which one small mistake or misjudgment can cost patient lives; however, in terms of DevOps, waiting for regulatory evaluation and approval can slow down the entire software development process, which defeats the core purpose of CI/CD.

    Security

    Data security poses another challenge for healthcare providers, especially when dealing with cloud-based software solutions. Cloud-based systems will always have potential vulnerabilities, as they rely on infrastructure that connects a variety of devices and smart technology equipment. There will always be inherent weaknesses in remote systems, as opposed to on-premises, too. A recent survey revealed that 42% of respondents said their major security concern was unauthorized access to cloud systems through insecure APIs. Network configuration problems were a close second, with 40% of respondents citing those as a concern.

    In a healthcare setting, another issue is the high volume and high velocity of data. Even a small, specialist clinic that may only see 150 patients per day will still generate vast amounts of data over the course of a month or year. Most of the data is private and sensitive, which means that data privacy and cybersecurity are top priorities for healthcare companies.

    The Impact on DevOps

    At first glance, because of the high level of regulatory oversight and cybersecurity concerns, it might seem that health care is a less-than-ideal environment for agile DevOps processes. How can you adopt fast-paced CI/CD cadences and innovate rapidly when there are necessary, opposing forces?

    The answer is to leverage innovative software development solutions such as on-premises feature flagging.

    Feature Flagging and Its Impact on Software Innovation

    Feature flags are, essentially, toggles or switches that allow software development teams to turn features on or off. The main advantage of feature flagging is that it allows for faster software deployment. One or more features can be coded into the software during development and made ready to go, but it is turned off for the user and/or patient on initial deployment.

    The ability to embed features within software that can be toggled on or off is perfectly suited for the healthcare industry since that approach allows for the necessary regulatory approval(s) before full deployment.

    For example, look at the rapid rise of telemedicine during the COVID-19 pandemic. Doctors, hospitals and patients alike were forced, along with the rest of the world, into the “new normal” of virtual interaction to mitigate the spread of disease while still providing quality treatment.

    For most industries, adding video chat/conferencing capabilities to existing applications was relatively easy. But for health care, the approval process, privacy and security concerns slowed down the adoption of these features. In our experience, typical healthcare teams are, best-case scenario, running on monthly—or, most likely, quarterly—deployment cycles to align their deployment efforts with compliance and governance review boards. Product and engineering teams work to get their updates and improvements in line with this cadence, which can make innovation difficult.

    If teams wanted to deliver this capability quickly, they could adopt feature flagging to decouple the concepts of “deploy,” “approve” and “release.” To use the video chat example, here are the steps they’d be able to take:

    1) Build the videoconferencing capability into their app and deploy the feature to production with the capability switched on for internal users (IP targeting, specific email addresses, etc.) only.

    2) Now that the feature is in live production, they can perform actual field testing to ensure that the functionality is working well, while simultaneously moving through internal and external approval processes.

    3) Once the review is complete, move to the release stage by switching the feature(s) on and allowing (external) end users to access the capability.

    All this can be achieved without needing to redeploy the software, and the developers are still free to make iterative improvements to the application.

    Now that the regulatory hurdles are addressed, it’s important to acknowledge that security is still an issue for healthcare companies that employ a SaaS feature flagging platform.

    While most providers focus solely on SaaS, the ability to deploy feature flagging software on proprietary cloud infrastructure is important in the healthcare space. This model enables both extra security and HIPAA compliance, and also opens up important capabilities and performance results that SaaS-only providers have a hard time matching. Since this technology typically becomes deeply embedded in the fabric of an organization’s product and technology, feature flagging is well-suited to an on-premises implementation.

    The implementation of on-premises feature flagging is a great way for healthcare companies to increase deployment velocity from monthly to daily. It allows their software development teams to adopt CI/CD cadences and innovate more rapidly, without the risk of breaching regulations or making sensitive data easily available to hackers.

  • LogDNA Extends Log Management Reach

    LogDNA Extends Log Management Reach

    LogDNA has extended the reach of its log management platform to add support for a Node.js platform from Vercel and a feature flagging tool from LaunchDarkly.

    In addition, LogDNA has expanded an existing alliance to IBM to add support for instance of Red Hat OpenShift running on VMware platforms hosted on the IBM Cloud, which enables IT teams to centralize log management using LogDNA and IBM Log Analysis.

    Chris Nguyen, chief strategy officer for LogDNA, said the goal is to continue to establish partnerships that will enable DevOps teams to manage larger swaths of the IT environment via a single pane of glass.

    Vercel has been gaining  traction as a provider of an open source reactive programming framework that is being employed to build more interactive front ends for web and mobile applications.

    LaunchDarkly is a feature management platform that serves more than 6 trillion feature flags a day spanning 14 million mobile devices and 3 million servers. The integration between LogDNA and LaunchDarkly enables developers to rapidly iterate on feature flags using logging data surfaced by LogDNA.

    Nguyen said that as IT environments continue to become more complex, more organizations are relying on log analytics to reduce the noise level being created by all the tools and platforms that make up a modern IT environment. The challenge IT organizations face is most of them can’t find or retain a site reliability engineer (SRE), so they need tools that enable developers to make better-informed decisions.

    LogDNA is making the case for a log management platform deployable in the cloud or on-premises, designed for DevOps teams as an alternative to existing log management platforms that were designed for IT administrators who rely on graphical tools. LogDNA instead provides developers access to log analytics that are accessed via command-line interface (CLI) or a user interface.

    It’s not clear whether or how much IT organizations may be willing to replace legacy log management platforms. However, as more organizations embrace best DevOps practices that include observability as a core tenet, LogDNA is betting those organizations will prefer an approach to log management aimed at developers rather than IT operations staff.

    As DevOps teams assume more responsibility for the management of IT on an end-to-end basis, a seismic shift in IT tooling is underway. Providers of legacy IT tools are quickly shifting toward making APIs and CLIs available in response to a range of startups that are making available tools designed from the ground up to appeal more to DevOps teams. It’s too early to say how this battle for control over observability will play out, but the number of providers of tools for DevOps teams has never been greater.

    In the meantime, many DevOps teams are still sorting out when best to employ log analytics, metrics and distributed tracing to optimize IT environments. The challenge these days isn’t so much being able to discover what’s occurring in an IT environment as much as it is making sense of it all.

  • CloudBees Acquires Rollout for Feature Flagging

    CloudBees Acquires Rollout for Feature Flagging

    CloudBees today announced it would extend the reach of the Jenkins continuous integration/continuous development (CI/CD) platform by acquiring Rollout, a provider of feature flag tool that gets employed to simplify testing of new modules within an application.

    Company CEO Sacha Labourey said the acquisition of Rollout would result in a feature flag capability that is more seamlessly integrated with the gates that make up a CI/CD pipeline process. The goal is to make it easier for DevOps teams to apply A/B testing of new application features against a subset of users before deciding to update an entire application environment, he said.

    Feature flagging, also known as feature toggling, enables DevOps teams to hide features from certain users at runtime. In effect, this creates multiple branches from the same source code that DevOps teams need to manage. Rather than having to employ a separate tool based on an entirely different user interface, CloudBees is moving to make feature flagging a core capability of its extended toolchain.

    In theory, feature flagging should be more widely employed than it is today. Many organizations, however, have found it challenging to incorporate separate feature flagging tools within their DevOps processes. CloudBees is now using some of the money it has raised of late to address that issue.

    Feature flagging today is largely confined to testing. However, there may come a day when more organizations will employ feature flagging to make different classes of user experience available to different end users. That approach, in theory, would make it possible to charge different fees for disparate application experiences using the same core application.

    In the meantime, the goal is to garner more feedback concerning new capabilities that might be added to an application before the features are made generally available. Developers often spend months developing new features only to discover end users are not employing those capabilities because of some trivial glitch that could have been discovered easily using A/B testing.

    There currently is no shortage of options when it comes to tools for implementing feature flagging. Labourey said CloudBees elected to acquire Rollout because the team behind it was deemed to have the best cultural fit with CloudBees. It’s too early to say whether other providers of feature flagging tools will be rolled up into other CI/CD platforms—providers of those platforms can either develop their own feature flagging toolsets or move to absorb a third-party provider either by acquiring them or forming a technology alliance. The depth of the toolchain being provided these days often has as much to do with what CI/CD platform ultimately gets adopted as the core integration and delivery capabilities.

    Regardless of the path chosen, it’s apparent that thanks to feature flagging, continuous testing processes will become more sophisticated. That may require some adjustments to existing best DevOps practices, but the days when development teams blindly experiment on end users in the hopes they are building the next killer feature mercifully are coming to an end.

    — Mike Vizard

  • Split Launches Free Managed Feature-Flag Service

    Split Launches Free Managed Feature-Flag Service

    As part of an effort to attract more DevOps teams, Split is making available a free managed feature-flag service for up to five users within an organization.

    Based on the same commercial managed service Split provides today, company president Trevor Stuart said the free service provides those five users with unlimited feature-flagging and unlimited usage in the hopes that the number of DevOps teams employing feature-flagging will rise to the point where the organization will opt to pay to consume the paid managed service. The free managed service also includes user segmentation capabilities to provide control over how many end users might be exposed to any new feature.

    The paid managed service provides access to additional capabilities such as integrations, access and permissions, team collaboration and full-stack experimentation.

    Stuart noted many DevOps teams are today attempting to incorporate feature-flagging into their processes by implementing one of more than 40 different open source projects. However, many of them quickly discover that building and maintaining a feature-flag platform is a difficult undertaking. Many developers decide that building a feature-flagging platform is a challenge they want to take on because it provides a critical set of DevOps capabilities. But when those developers leave the organization, the DevOps team is suddenly left with a platform no one else in the organization knows how to support, he said.

    Feature flags, also known as feature toggles, provide a means for DevOps teams to test and add new capabilities to their applications without having to take the entire application offline. Feature-flagging also enables phased application rollouts that make it easier for DevOps teams to assess new functionality as it is added. Any problematic update can be turned off with a single click. The downside is they generally result in more branches of applications that need to be managed carefully within the context of a DevOps process. Because of that complexity, vendors such as Split have been making the case for employing platforms that enable DevOps teams to more easily incorporate feature-flagging within a DevOps process.

    Stuart said the ultimate goal is to provide a more controlled approach to experimentation. Instead of randomly testing new features on end users, feature-flagging makes it possible to more easily test features on specific end users, said Stuart.

    It may be a while longer before feature-flagging is adopted more pervasively. But as DevOps teams become increasingly more sophisticated, there’s little doubt feature-flagging won’t become more commonly employed. The simple truth is that uncontrolled application experiments on end users usually are not appreciated. Savvy DevOps teams are finding ways to test application functions in real-world scenarios with minimal disruption to the majority of end users.

    The only real issue now is determining how best to go about implementing feature-flagging at a time when most DevOps teams already are struggling to keep pace with their existing application development and deployment projects.

    — Mike Vizard