devopsy.kinsta.cloud

Author: Dave Karow

  • Feature Flags: The Cure for DevOps Remote Work Stress

    Feature Flags: The Cure for DevOps Remote Work Stress

    Feature flags can help reduce the stress associated with DevOps during WFH

    The world has drastically changed. As a result, we have had to adapt the way we shop, socialize, educate and work. Businesses have had to adapt to keep operations going, and the biggest change they’ve had to make has been the move to remote working. For most, this has meant bringing a laptop home from the office and setting up at a home desk or dining table. For teams used to collaborating in-person, it may feel like the world has turned upside down.

    DevOps teams have been thrust into a decentralized environment at the very time they are facing record traffic and the pressure to return to or even exceed their prior cadence. The current climate has accelerated demand for fast and efficiently running online services, such as e-commerce, streaming services and video conference platforms. Digital platforms not only are facing greater demand, but they are also seen as more mission-critical than ever.

    The stress of all this can be daunting, but it’s useful to remember that the very idea of DevOps emerged as a way to move faster with greater resilience. We need to trust the patterns and tools that were emerging as the “new normal” even before the current crisis emerged.

    One of those patterns, which is sometimes referred to as progressive delivery, is the idea of decoupling deployment from release. The tool many have chosen to accomplish progressive delivery, especially to meet the needs of decoupled and decentralized teams, is feature flags.

    Feature flags allow teams to deploy new features in production while restricting access to only a subset of users. The ability to control exposure without requiring further deployments or infrastructure changes in turn makes testing in production (exposing the feature to internal dev and test users only) and canary testing (exposing the feature to a small number of real users before ramping up to 100%) straightforward and repeatable processes.

    This “fewer moving parts” way of promoting features eliminates the need for the large-scale coordination that an all-or-nothing “big bang” release requires. That’s why feature flags are particularly well-suited for teams to work remotely, in decentralized environments.

    Feature flags allow for time to make sure everything is working properly before the switch is flipped. It is the equivalent of changing the plane while you’re flying, without the passengers falling. For this reason, DevOps teams that were using feature flags prior to global shelter-in-place orders were much better positioned to continue development efforts without interruption while working remotely. Feature flags allow for DevOps teams to operate in gradual stages with the ease of experimentation and rollbacks, significantly reducing the stresses of remote work.

  • How Product Managers Can Take Back Control with Feature Flags

    How Product Managers Can Take Back Control with Feature Flags

    Product managers live in a high-speed world and are always focused on releasing the most impactful features in the shortest amount of time. Since users have grown accustomed to regular UI updates and bug fixes completed in near real time, this frenetic pace at which product managers work will only increase.

    The process of pushing out new features or software fixes can be very stressful on product managers, and the one thing they crave to keep their sanity and ensure a successful release is control. Luckily, that’s exactly what feature flags provide.

    Dialing Up Feature Flags

    At their core, feature flags give development teams the ability to turn features on and off without deploying new code. Think of them as dials in the cloud. When the dial is attached to any feature in a product–whether a new one or an old one–it controls who sees it, who has access to it and how quickly it is delivered to an entire customer base.

    Feature flags let organizations break the tyranny of the Thursday night release by segmenting it into smaller bits to control exposure and enable a continuous release motion. You might start by turning on a feature to only internal users or beta testers so you can test in production to make sure nothing has been missed. From there, you have the freedom to ramp up the feature to your customers gradually before going to 100% availability.

    With this controlled exposure, development teams can lessen the panic and anxiety around the weekly release schedule. Having the ability to completely turn off features means feature flags also increase application stability and remove the need for hotfixes. It’s less often necessary to assemble a war room if there is a problem when you can simply turn off the feature in seconds. By working feature flags into the release process, teams take control of the who, what and when in terms of releases. They can also dictate types of users, demographics, locations and scale the release of the new feature.

    Feature Flags and Product Managers

    Outside of the DevOps team, feature flags can also be really powerful for product managers. Historically, the release of a new feature meant product managers had to coordinate with cross-functional teams to ensure the release was executed successfully. This meant making sure marketing was ready to publish a blog post about the feature, the sales team knew how to use and sell the new feature, and the product marketing team had documentation prepared for how the feature set works. Of course, all of this had to be perfectly synchronized with the engineers’ timeline for releasing the feature.

    With feature flags, product managers now essentially have the keys to the kingdom. It gives them the power to turn the feature on for some or all of their customers without waiting for engineers to complete their next deploy. Not having to coordinate that extra piece of the schedule gives a lot of power and time back to the product manager.

    A Deeper Look at Customer Feedback

    Another aspect of a product manager’s job is collecting feedback. They need to be able to answer questions related to business KPIs, such as “How is this feature performing for my customers?,” “Are customers able to do the action the feature is intended to perform?” and “Are we generating more revenue from the feature?” Feature flags can also help in this area.

    As product managers ramp up a feature, they are simultaneously shortening the feedback cycle. Since feature flags allow for segmentation, where one customer group sees one set of features and another customer group sees a different set of features, and since key metrics can be captured into separate buckets for each group, product managers can now run controlled experiments as part of the release cycle. Seeing KPIs aligned with the different customer groups helps them understand which features are performing the most successfully.

    Creating the Ideal Product Roadmap

    As product managers embrace usage measurement tied to feature rollouts, entire teams can better align with agile best practices to continuously push out the smallest incremental set of new features. By understanding the performance of every feature, you’ll be better equipped to iterate and refine your ideal product roadmap.

    — Dave Karow

  • DevOps Tools Democratize the View From Both Sides

    DevOps Tools Democratize the View From Both Sides

    How modern product decisions platforms marry the key metrics of features changes to organizational KPIs

    In 1967, Joni Mitchell released one of her most iconic songs, “Both Sides Now.” The song was inspired by the book, “Henderson the Rain King,” in which author Saul Bellow writes about flying to Africa and looking out the plane window, “Look at those clouds down there; it’s very strange to look at the clouds from up above them. I remember as a boy having dreamed up at clouds a lot and having seen the cloud from both sides now, I suppose I shouldn’t really be amazed by anything.”

    Although not her intention and slightly before its time of popularity, the song speaks quite accurately to the tensions between idealized DevOps and the reality on the ground that many organizations are struggling through. On paper, the core tenant of DevOps is about cooperation, seeing problems and processes from multiple team members’ perspectives from each side, but this is easier said than done.

    “But now old friends they’re acting strange
    They shake their heads, they say I’ve changed
    Well something’s lost, but something’s gained
    In living every day.”

    The Unicorns and the Rest of Us

    Some of today’s most successful and disruptive companies—including Google, Netflix and Facebook—have taken their market-leading positions precisely because they have developed strategy and culture around DevOps. It has been part of the company DNA since the beginning and every employee is bought into it. This means fast, agile development and experimentation is part of the culture.

    While many companies would like to capture some of the benefits that unicorns have realized from implementing these development methodologies, for many, this simply is not an option. There is legacy infrastructure, processes and people—who are sometimes the hardest to change. Often DevOps is embraced in small pockets of a company, by teams with newer members working on new projects. The mindset shift that needs to happen to have DevOps—and everything that comes along with it—become part of a company’s culture takes time, commitment and perseverance. However, a good way to start is by demonstrating the fresh, diverse perspectives that can be gained through experimentation and progressive exposure to encourage wider adoption.

    Leveling Up

    One of the ways modern app delivery, operations and business management teams at organizations all along the adoption spectrum are achieving governance, operational awareness and control at speed is by wrapping new code deployments in feature flags and using a centralized platform to control progressive exposure to users.

    By themselves, feature flags are not new. What is new is the centralized and externalized control plane as a service and, newer still, the idea of observing system and business KPIs at the user session or request granularity level for feature flag-controlled decisions.

    When something is rolled out to 5% of the users, it is not likely to light up global ops or business metrics dashboards, even if it is a bit broken—and that makes people cranky. If instead, tools are in place to monitor the KPIs within that 5% population and compare it to the other 95% looking for divergence, you have a much more powerful early warning system.

    These new centralized platforms also extend observability to stakeholders beyond the few wizards driving orchestration and ops teams watching dashboards. An anti-pattern to the local control autonomy spiel modern DevOps patterns call for, this wider visibility protects against local optimization traps in which one team improves its KPI while degrading other KPIs it doesn’t know or care about.

    It can be beneficial to have the idea of key metrics tied to a feature and organizational metrics that look after larger organizational concerns. This inspiration can be traced back to what LinkedIn does with its XLNT experimentation platform, where it calls the organizational metrics “guardrail KPIs.” By always tracking a set of metrics that are critical to the business as a whole, organizations gain a clearer view of the impact that both the granular updates and the larger rollouts are making to the business.

    As Joni said in all her wisdom:

    “I’ve looked at life from both sides now
    From up and down, and still somehow
    It’s life’s illusions I recall
    I really don’t know life at all.”

    No team or organization can know everything all the time, but we can build in visibility to the process of rolling out functionality to our users and create a shared vision of our intentions and the results we achieve. I would argue that if you do look at DevOps from both sides, up and down, you will know the benefits.

    — Dave Karow