devopsy.kinsta.cloud

Tag: A/B testing

  • Working with SAFe and Microservices: Learnings from Developers

    Working with SAFe and Microservices: Learnings from Developers

    As developers, the prospect of working for a big company might bring about feelings of oppression, rather than opportunity. Envisaging endless team syncs, pointless meetings and processes wrapped up in bureaucracy inside a set of procedures. It’s easy to imagine why some are put off. For many though, the fear comes from the thought of being lost in a corporate structure where input is not valued, and skills are wasted.

    But every day, as developer concepts become further rooted into corporate behaviors, the line between the two worlds continues to blur. Products are no longer dreamed up in product silos, but from agile teams made up of a diverse cross section of a company. Marketing has dropped drip campaigns in favor of A/B testing, rapid iterations of messaging and data-driven analytics. Big companies no longer mean old school thinking, but fast-changing, inclusive places to really make an impact and be heard. 

    Working within the Scaled Agile Framework (SAFe) with an agile architecture of microservices helps us to do our jobs, but the learnings we’d like to share in this article are universal. An organization may not require the SAFe methodology, but the experiences and methods of working can be applied to many roles and are based on three fundamental questions every developer should ask themselves. 

    How Do I Plan My Day? 

    As with any role, a good start for us is knowing that the previous day went well; that the code we wrote meets the standards required for deployment. Before that, our individual microservices teams will meet to discuss immediate priorities. We let one another know what’s top of mind for us, and any issues we might be facing — and we resolve them together before a midday Scrum meeting.

    The Scrum meeting involves the Scrum master, product owner and the developer team and gives us a chance to give feedback and dive into the wider challenges or blockers we’re facing with our own tasks. We might be thought of as solitary creatures, but we actually tend to solve problems together. So, while we have ownership of our own tasks, problem solving comes from collaboration.  

    Whether working within the agile framework or not, communication is a huge part of our lives. Our advice to developers everywhere is to be vocal about the need to engage within their organizations. And to business IT decision makers, we know that not every firm has the deep pockets to fund a dedicated DevOps team to implement new tools, change culture or break down silos, but there are many communications and open source DevOps tools that boost collaboration and improve workflows — most are well-known to developers. So, give them the chance to explore how they might bring efficiencies to their work. Help them help the business and maybe suggest trialing some new tools. 

    How Do I Upskill on the Job?

    Developers are problem solvers. We love the opportunity to help each other overcome challenges. Peer-to-peer communication doesn’t just allow us to get back on course quicker, it lets different teams share knowledge and pitch in to solve problems. We don’t mind being transparent with our peers when we face an issue – in fact, we quite like it, as the offshoot of working together often leads to new skills and technical knowledge. 

    Learning the interactions between each microservice, for example, helps us map out the architecture and understand how our own work fits into the bigger picture. The more we talk, the more we see where bottlenecks might occur — and the better equipped we are to achieve larger objectives. As we have complete ownership of our services, from initial coding to deployment, it is our duty to ensure our services perform as they should in production. 

    This ownership is something all developers should aim for. Even when working in a more rigid waterfall approach, opportunities to collaborate should be seized and encouraged — even if the only payoff is personal development. Implementing a system of peer code reviews, for example, not only delivers more robust releases, it fosters a collaborative mindset.

    Do I Need to Be in this Meeting?

    Working with SAFe methodology allows the job to be broken down into iterations linked to business objectives. The most significant of these is determined by meetings that occur every four months, where goals are set and roadmaps established to achieve them. Engineering teams then divide up the features that will be passed on to the developer teams, who break them down into two-week sprints. 

    The sprints are what the developer teams work to, under direction from the Scrum masters and product owners. Breaking iterations into smaller sprints ensures we have defined goals, which keep meetings and interactions on track (i.e., daily Scrum meetings and bi-weekly sprint meetings). Without this focus, there’s a risk of derailing the prep required to focus on writing and reviewing code. If we need a discussion about certain features, we make sure to identify exactly who needs to be in that meeting. Above all, we’re all about optimizing our time together. The longer we spend away from our desks, the less time we have to perform our core roles. 

    Whatever your part in the software development lifecycle, never be afraid of asking the question, “Do I need to be here?” Your energies may be best used elsewhere.

    As you can see, these three questions are critical to developers but can be applied to just about any role in just about any organization. Planning, learning and focusing – seems we’re not so different after all.

     

    Tomasz Rumpca

     

    This article was co-authored by Tomasz Rumpca, Java developer and team lead at Finastra. Tomasz works on FusionFabric.cloud, Finastra’s open development platform solution. He is passionate about Java-related technologies and building user-friendly software. Outside of work, he enjoys spending time outdoors with his friends and family.

  • Akamai Extends Scope of DevOps Integrations

    Akamai Extends Scope of DevOps Integrations

    Akamai today extended its DevOps strategy to provide tighter integrations with continuous integration/continuous (CI/CD) platforms and IT automation tools such as Terraform from HashiCorp.

    In addition, Akamai is adding support for serverless computing functions to Akamai EdgeWorkers, a JavaScript-based framework through which application logic can be executed on the edge of the Akamai content delivery network (CDN) now as a microservice.

    Greg Griffiths, product marketing manager for DevOps solutions at Akamai, said the latest additions will make it easier for DevOps teams to view the Akamai CDN as a natural extension for deploying applications. Akamai launched its first DevOps initiative last year. The goal is to make possible for DevOps teams to spin up new properties and make configuration changes from within the context of their CI/CD workflows, he said.

    Terraform support, meanwhile, will make it possible for DevOps teams to programmatically provision and manage properties and DNS zones as code, added Griffiths.

    As part of that effort, the Akamai Pipeline can now synchronize with the Akamai Control Center to capture any manual configuration changes in a way that then allows them to be incorporated into a CI/CD workflow, he noted.

    Akamai has been making a case for deploying applications as close to the network edge as possible using its CDN to reduce network latency. As part of that effort, EdgeWorkers allows developers to spin up microservices as needed. Those microservices can now access data embedded in the function, including all the data from the HTTP request such as cookies, headers, URL and query parameters.

    DevOps teams can now also more easily conduct A/B testing and feature experiments using cached content in addition to delivering different application experiences by modifying the path to cached images and other content based on variables such as customer location or time of day.

    Other new capabilities being added by Akamai include the ability to modify both the path and query arguments for a request and determine to which origin any request should be routed.

    Griffiths said now that more organizations are leveraging the Akamai CDN as a vehicle for delivering applications at the network edge, the next big initiative will be to make it easier to leverage the company’s managed security services to embrace DevSecOps.

    It’s not clear to what degree DevOps teams have embraced CDNs as a vehicle delivering applications. Organizations have, however, been leveraging CDNs to deliver web applications for years now. By providing tighter integration with CI/CD platforms Akamai is essentially making the CDN just another target for deploying applications at the end of a DevOps workflow. That capability may prove critical as organizations move to deploy more application code on edge computing platforms involving use cases that require data to be processed and analyzed in near real-time.

    Of course, Akamai is not the only CDN providers with similar ambitions. It is, however, already the largest, so from a DevOps perspective most organizations will soon encounter an Akamai point of presence somewhere soon, if they have not already.

    — Mike Vizard

  • The Use of Feature Flags in Code: Too Many Flags?

    The Use of Feature Flags in Code: Too Many Flags?

    It is interesting to watch the growth of an idea over time. The idea of using flags in code to do different things is as old as programming itself. Old-school configuration files used them, and they worked, so they were adapted.

    Thing is, given an idea that works, humanity inevitably takes it too far, and flags to control software behavior seem to have reached that point. If you are using one set of flags for A/B testing, another to segregate code in development at runtime, another to turn functionality on for some users but not others and yet another set of flags to hide data based upon user…You’re buried in unnecessary code branches. If your organization isn’t great about cleaning up after flags are no longer needed, you are building spaghetti code that future developers will not thank you for.

    The best answer to this growing burden is focus. What is the best use of feature flags/toggles in your environment? They certainly speed the delivery process by having the code there, in nightly builds, just not executed until the flag is flipped. This helps in rollout also by allowing operators to turn a feature on when it is ready by changing config rather than redeploying the application.

    For A/B testing, in many cases it makes more sense to handle switching at a load balancer, where again it is a config, but separate instances serve the UI in question. This, like all decisions regarding flags, should be based upon the volume of change. Changing the contents of a list is likely easier to test with flags, but large volume of change is probably better run separately and switched off of a load balancer.

    The same is true with the volume of change in source. A rollout might be the best option for handling large volumes of change, and feature flags may simply create more complexity.

    As with everything, approach the problem with a plan that works best, in this instance, in your environment. There is no denying that the ability to turn on a new feature and then turn it off if something goes wrong is appealing, just use the idea judiciously. And clean up after yourself. No shop that uses flagging extensively will say “yeah, we don’t clean it up,” because the mess of nested checks for flags would slow the code and make it passingly difficult to even read, let alone maintain, over time. So approach it from the beginning with “It is a tool, and when it no longer serves its intended purpose (the feature is fully live or abandoned), we remove it.”

    And keep rocking it. You are the engine of business, and this is what you do. Make it great and keep it running.

    — Don Macvittie

  • Why Digital Transformation Can’t Happen without Experimentation

    Why Digital Transformation Can’t Happen without Experimentation

    A sure sign of a company’s successful digital transformation is when it can leverage data to optimize every area within the enterprise. As Forrester puts it, for a company to realize the return on investment (ROI) of a digital investment, “benefits from digital investments need to be aligned with the business requirements for a specific value chain stage.” All along, data-driven insights need to be tied to measurable gains and real-world business key performance indicators (KPIs).

    The reality, however, is that data-centric principles are easier to apply in some areas of the business than others. The ethos has certainly taken hold in the development world—with its whole culture around DevOps, continuous delivery (CD), continuous integration (CI) and related agile methodologies that emphasize constant, data-driven experimentation and frequent reassessment and adaptation of plans.

    Unfortunately, too many companies drop the innovative mindset once things progress to production and customer rollout phases. In doing so, they fail to spread the ROI from digital investments more fully across the organization. In other words, they fail to mount a genuine digital transformation.

    True digital transformation requires companies apply a stronger, more agile approach to product adjustments across the value chain. Nowhere is this more critical than the need to embrace “full-stack experimentation” to realize business value from the world of data-based product development and testing.

    The Limits of A/B Testing

    Especially in an era when the customer experience sits at the center of the value proposition for most industries, the ability to fine-tune everything about how we bring products and services to market—and how our customers use and feel about those products and services—is mission-critical, especially in the quest for true digital transformation.

    Unfortunately, no matter how agile and data-driven the development phase may initially be, we lose visibility, insight and, most importantly, revenue whenever we fail to infuse those same values into the later stages of production, QA and analysis around how customers are actually using what they buy.

    Perhaps the biggest sign of this is the over-reliance of marketing teams on signals from basic A/B testing.

    Industrywide, A/B testing is the most common approach to experimentation, but it’s far from ideal. A/B testing is typically used by marketing teams to test front-end changes at the user interface-level. It’s limited in its efficacy, as it does not take into consideration the deeper statistical nuances and resultant effects across the application stack—for instance, swapping out code to roll out an entirely new feature to a small set of users and measuring the results of that single deployment across both business and system metrics.

    Worse yet is the false sense of security that can come from the narrow scope of A/B testing. Any outcome can be easily misunderstood as the only improvement possible. That leaves countless other variables and opportunities for ROI unexamined. If Plato remarked, “The unexamined life is not worth living,” what does that say about the unexamined product development process? How do we know if it’s worth building?

    A Better Way

    While A/B testing is still appropriate for some limited uses, leading-edge companies are learning to expand inquiry across the “full stack” of their applications. Full-stack experimentation differs from traditional A/B testing in scope, purpose and the potential impact on a business. It examines not just user interfaces but also execution logic, technical services, APIs and the data infrastructure underlying it all. This fosters a market-driven approach that brings more insight and less guesswork to decision-making.

    To be clear, full-stack experimentation does not optimize part of a product or feature; it is about optimizing the process around experimentation and allowing development to more directly support and inform the evolution of the business. In this way, full-stack experimentation helps gain deeper value from the organization’s use of agile, DevOps and CI/CD so we can garner critical insights into how a product or feature is actually used by customers. More importantly, it measures the impact of every release on important key business metrics—which may be radically different from the developer’s intent.

    Full-stack experimentation unlocks value across the entire data ecosystem. It involves collaboration among the key stakeholders involved in the development of a product or application, from engineers to product managers, as opposed to primarily marketers. You can use full-stack experimentation to answer deeper questions and test deeper assumptions. For instance, does adding the ability to tag friends in a photo increase their likelihood of posting photos in the future? Does this result in more sessions per user and does that ultimately impact the ad revenue generated per user?

    Delivering Digital Transformation to More Companies

    The benefits of full-stack experimentation are well-known among organizations with the resources to build and manage this in-house. Microsoft, Etsy and Netflix, for instance, test everything from multiple angles, sometimes running 50 tests a day or more on a single feature. These companies have powerful instrumentation to capture and analyze the multitude of variables and metrics—including those that may have been unanticipated. This surfaces valuable insights to be quickly spotted and harnessed for value.

    Fortunately, modern software-as-a-service (SaaS) solutions are increasingly saving companies from having to create their own in-house, custom-built systems to get the benefits of full-stack experimentation. Unified platforms now exist that help engineering and product teams accelerate the pace of product delivery and make data-driven decisions without investing valuable development resources to build the tools themselves. Critically, these platforms have robust feature flagging and extensive experimentation capabilities that allow testing to happen well into production and rollout to customers—with strategic and incremental tests to examine and adjust logic, APIs, UX or other elements across the entire application ecosystem.

    On a tactical level, these new platforms make experimentation processes simpler and more accessible to more companies. But the bigger picture is that these new options for full-stack experimentation effectively remove the friction that exists in achieving true digital transformation—allowing more companies to completely revolutionize how they do business.

    — Kavitha Mariappan