devopsy.kinsta.cloud

Category: DevOps Practice

  • 3 Ways to Prevent Developer Burnout

    3 Ways to Prevent Developer Burnout

    Without developers, software companies wouldn’t exist—and yet, the experience of these experts can be far from ideal. A recent report from Haystack found that nearly 80% of developers report being burned out and the pandemic isn’t even one of the primary factors. Despite similar job requirements, the experience of developers significantly varies across the industry, adding complexity to an already challenging job. Conflicting coding styles, communication styles and requirements from different teams conspire to make the development process inefficient and difficult and leave developers feeling overwhelmed. Between different organizations and even teams within the same organization, the differences in team culture and educational opportunities can lead to radically different job experiences for the same job title. To retain talented developers in the workforce and maximize their potential, the collective developer experience needs to be improved through a developer-first and inclusive culture and better access to professional development for developers at every level.

    Build a Strong Culture of Documentation, Communication and Knowledge Sharing

    One of the biggest challenges team leaders encounter is how to communicate key information between team members. Many developers are incredibly skilled at their trade but aren’t properly trained or given the time to work on sharing that information with either colleagues or end users. Having skilled technical writers means that the team can provide consistent, clear information about the software—and this is crucial for company success. Having technical writers on the team improves communication and efficiency and enables developers to more quickly and easily locate the resources and support that they need to perform their tasks

    The developer’s goal is to innovate and build successful and maintainable systems. Achieving this requires good team processes and a solid system of documentation. Without user-facing documentation, adoption will suffer as users struggle to get things done with the system. Similarly, without documentation of the individual components, knowledge cannot be shared between teams and so the teams working on the application cannot collaborate effectively. A positive culture around documentation and investment in best practices by all contributors, including developers, makes a huge difference in how successful an organization can be.

    Welcome Employees with Comprehensive and Constructive Onboarding

    Strong communication is especially vital during the onboarding process; it’s one of the most important periods for developers early in their careers. Getting developers up to speed in a new team quickly is crucial—and streamlining education beginning during onboarding can make a big difference. Onboarding is a golden opportunity to bring new developers into the cultural fold and enable them to contribute to the team quickly. Doing so also reduces the risk of losing developers from the team.

    Prioritize an Inclusive and Supportive Culture at all Levels

    The experience of software developers is greatly influenced by the culture of the company they work for. The values of a company and the way that departments interact make a big impact on developers—and it’s not always a positive one. Opportunities for career development, promotions, mentorship programs and training are critical for all employees, but especially those in fields with the potential for high turnover or burnout like developers. Providing developers with resources to further their own understanding and mastery of the job—such as access to a budget for attending conferences and further study—is a critical investment for their success. Organizations both large and small must take initiative to ensure developers see a path forward for themselves at their current company and within the industry—or risk losing their talented developers entirely. 

    While developers’ experiences vary across the industry, between departments and even smaller internal teams, there is inherent value in improving communication, investment and culture on a micro and macro scale. To attract and retain highly skilled and innovative developers and ensure success for teams and companies as a whole, executive leadership must work with their developers to find a cohesive system and create an experience that works for everyone. Like any other specialized professional in a complex trade, developers are invaluable to their teams and community; advocating for the improvement of their work experience throughout their careers is the best way for tech companies to keep developers creating software that improves our world.

  • Sonatype Report Shows Spike in Supply Chain Attacks

    Sonatype Report Shows Spike in Supply Chain Attacks

    Sonatype today released a report that finds there has been a 650% year-over-year increase in supply chain attacks aimed at upstream public repositories. Cybercriminals hope to compromise these repositories by injecting malware into software components that many organizations might be using, according to the report.

    The seventh annual State of the Software Supply Chain Report is based on an analysis of 100,000 applications and 4 million component migrations made in the last month alongside a survey of 702 software engineering professionals. Specifically, the report focuses on demand and security trends associated with the Java (Maven Central), JavaScript (npmjs), Python (PyPI) and .Net (nuget) ecosystems. The top four open source ecosystems now contain a combined 37,451,682 different versions of components, a nearly 20% increase year-over-year.

    Over the course of 2021, developers also downloaded more than 2.2 trillion open source packages from the top four ecosystems, a 73% increase over the prior year.

    However, despite the huge available supply of open source software, use of this software is primarily concentrated in a small number of popular projects. Production applications are only using 6% of available open source projects.

    Not surprisingly, popular projects are more vulnerable to compromise. A total of 29% of popular project versions contain at least one known security vulnerability. Conversely, only 6.5% of projects that are not widely used have vulnerabilities.

    Stephen Magill, vice president of product innovation for Sonatype, said popular open source projects tend to have better security practices in place because of the larger number of maintainers and contributors working on the project. The paradox is that less-popular open source software is not likely to be targeted by cybercriminals who tend to focus on targets that represent the best chance to infect downstream applications, said Magill. Popular open source projects were 2.8 times more likely to contain vulnerabilities, the report found.

    Projects with a faster mean-time-to-update (MTTU) are also generally more secure. They are 1.8 times less likely to have vulnerabilities, the survey found.

    The report also found developers make suboptimal choices 69% of the time when updating third-party dependencies, even when newer versions of projects are generally available. Developers may be avoiding those updates because they may be perceived to be not as stable as they would like. However, those updates generally contain the latest security patches needed to address a recently discovered vulnerability. Commercial engineering teams only manage 25% of the components they use, leaving the majority of their open source dependencies stale and susceptible to increased security risks, the report found.

    Finally, the report suggested there is a greater need for automation. Equipped with intelligent automation, a medium-sized enterprise with 20 application development teams would save a total of 160 developer days a year. Sonatype estimated that could save organizations $192,000 a year.

    In general, Magill noted that the security of software supply chains should continue to improve in the wake of an executive order issued by President Biden. In the meantime, however, most organizations would be well-advised to start reviewing the components and dependencies that make up their software supply chain sooner rather than later. After all, chances are good that cybercriminals are already doing much the same thing.

  • Solving the DevOps Accountability Problem

    DevOps accountability is the idea that both the development and operations teams have equal responsibility for success. But putting this approach into practice has been a thorn in the side of DevOps teams for the past decade, largely due to outdated organizational structures that place responsibilities on a single employee or team.

    These outmoded structures restrict the lean flow of operations needed for DevOps and contribute to costly downtime when issues arise. But redistributing functions across the organization can help solve this problem. 

    For cross-functional teams that rely on organization-wide collaboration, redefining the org chart can clarify ambiguities about accountability and help organizations overcome internal obstacles.

    Legacy Organizational Structures

    Many organizations have not instituted an organizational structure that reflects a shared accountability model. This is partially due to leadership’s assumption that large teams work faster and more dynamically. In reality, after a team exceeds nine individuals, the rate of return diminishes and people are more likely to assume someone else on the team will take responsibility for a task. As a result, accountability falls through the cracks.

    Additionally, there is frequently an imbalance in assignments and responsibilities between junior and senior employees. When senior employees take on the majority of important or interesting tasks, junior employees can feel overlooked and less responsible for their team’s success. This is both an individual and a company-wide issue; younger workers tend to bring fresh perspectives and insights—they can also adapt more quickly to unprecedented changes and issues.

    Picture a team consisting of a line manager and team members, with a structure that places all major responsibilities on the manager. If the manager happens to be out of the office when an issue arises, the team would have to wait for their boss’s return to resume operations.

    But the consequences of single-point accountability go far beyond lost time and downtime costs. When employees feel like they don’t have a significant stake in a project, they feel less aligned with the organization’s overall purpose and are less likely to be engaged.

    DevOps is most effective when teams are built around a common goal rather than around the performance of individuals. If an employee can’t see the impact their work is having on the overall organization or project, it can create blind spots and disconnect between the business and its people. Shifting business frameworks is no easy feat, but with the right strategy, it can improve how tasks and responsibilities are allocated in your organization.

    Three Ways to Switch up Your Org Chart for Greater Accountability

    The days of allowing responsibilities to fall on a single employee are over. But to successfully embrace a shared accountability approach, you need to reimagine your entire organizational chart. Beyond de-prioritizing seniority and minimizing team sizes, consider these three initiatives to help settle DevOps accountability issues:

    1. Blueprint your organizational structure around products. Organize your work structure around products—not projects. Traditional project management models rely on passing responsibilities between specialized teams, which can slow down innovation and degrade the quality of work. With an organizational structure built around products, you can build a cross-functional team with all necessary skills for each system. For example, if you have a team that’s accountable for the payroll system, all necessary expertise you need to keep that system running smoothly is based on a single contact point.
    1. Redistribute talent. The product-oriented approach requires changing up talent distribution across teams. Let’s say you have a 24-person team for a single SaaS product and seven of those team members have similar skill sets and backgrounds. In this instance, you could move several of those workers to a different team where their skills are in demand.
    1. Establish hybrid workplace environment norms. Face-to-face communication has always been a critical part of successful teams. But in light of the COVID-19 pandemic, workplace norms are evolving and organizations need to adapt to new ways of working. Many teams are no longer able to participate in informal knowledge sharing and other typical in-office interactions, so it’s critical to identify new norms for your team. Initiate conversations about applying DevOps concepts in a hybrid world, along with creating rules of engagement and accountability that are realistic for remote work.

    The Great Redistribution

    As technology advances, so should your organizational structure. To optimize efficiencies and ensure products reach the market on time, consider rethinking your org chart. In practice, this will enable you to more seamlessly adopt a culture that celebrates shared responsibility and employees who feel they have a stake in your product’s future.

  • Meet the New(ish) Pipeline

    Meet the New(ish) Pipeline

    My company keeps a sample project running pretty much all of the time. Our current project (multi-target web/Android app using Java and Spring built with Gradle and Ant that we’ll call “Finder” here) is getting a bit long in the tooth, so we have been casting about for a new one over the last several months. From non-work sources, we came upon the idea of multi-targeted Godot with C# as a viable side project. Moving to a completely different set of tools is kind of the point; it makes us stretch, and that is the idea of our ongoing projects. The stated goals for these projects are:

    1. Stretch knowledge about different languages, DevOps tools and platforms.
    2. Keep doing what you all are doing. Too many pundits have “grown out of” hands-on work, and it shows.
    3. Try out new ideas/architectures.
    4. Avoid “kitchen sink.” We can’t have a current test app that includes all available technologies, so keep it streamlined. Approach this as a production app that we use for testing, not as a test app.

    That’s why we’re looking to replace our Java/Spring project. We’ve got that pipeline down, we’ve tweaked the app until we are happy with the core and it hasn’t changed in a good while. But change is a part of DevOps, so we’re off.

    The Obvious

    Let’s take care of the obvious elements in our toolchain right away:

    1. Git. We’ll use GitHub, but it was a given that some form of Git would be holding our code.
    2. Visual Studio Code. We’re doing C#, so this is going to be the most useful option for code editing. The built-in Godot editor is good and will be used, but VS-Code offers C# functionality add-ons.
    3. Antsle is the deployment tool of choice, though this has changed over the years. We’ll use it to set up install sets for clients.
    4. Jenkins or Hudson. We’re going to use this only for test management.

    The Less Obvious

    There are several constraints we want to (or have to) meet. First, we want to avoid using Jenkins or Ant to control the entire build process, mostly because we’ve done both in previous projects, and most DevOps teams are no longer using these methods for new projects. Second, this is a sample we keep, not an investment, so we want to use open source technology if at all possible, to keep expenses down. Third, we’re using a game engine to do app development. This has some impacts–like most game engines, it is in control at runtime and we need to bundle the engine in the final application.

    1. The Godot Engine. Godot is written as a game platform, but its graphics/cross-platform abilities make it useful for graphics-heavy apps like ours. But we have to include the engine and its config files in the pipeline.
    2. Code Scanning. Static analysis was a late addition to Finder, and it’s in Java. This project is in C# and Godot Script. We have not yet found a tool that supports Godot Script, but C# we can get; it just adds restrictions. So we will use a static analysis tool, but we’re still deciding which.
    3. Build Automation. We’ve used Jenkins, Gradle, Maven and Ant to handle this step at different times in the past, but something newer would be a good idea. We are still evaluating this step. We will likely end up back on one of those tools because they are still used today. Godot is a new element to us, so we are also evaluating what is required to hook into it and make functioning apps in a repeatable process.

    Fueled Innovation

    We’re having fun—first couple sprints have us running a working prototype, so we’re happy with that. There’s still a lot to implement in the app and in the pipeline, so we’ll no doubt have more to say here soon. We’re talking about putting a server component in—not because the original concept needs it, but because our outgoing app—Finder—had server and client sides, and our need for things like Postman go away without this architecture. And yet, API security, testing, etc. is an important part of the DevOps architecture. As you can see, we’re still iterating.

    As to Finder, we normally take down the pipeline for a previous playground project when the new one goes up, but Finder costs us little. There are five containers (three permanent for the app hosting; two for build/test) and some processing power, so we’ll probably keep it since it is using a different set of pipeline tools (and languages—it is mostly Java/JavaScript).

    Meanwhile, you all keep rocking it. We’re building an(other) app that no one but us will ever see—but you are keeping the enterprise humming. Kudos to you!

  • New Relic Survey Shows Greater Appreciation for Observability

    New Relic Survey Shows Greater Appreciation for Observability

    A global survey of 1,300 software engineers, developers, IT leaders and executives found half of respondents (50%) are in the process of implementing an observability platform. Another 23% of respondents said that they cannot gain end-to-end observability at all, while 26% said they believe they have mature observability practices in place. The survey, published today, was conducted by CITE Research on behalf of New Relic.

    The majority (94%) of IT professionals said observability is important for their job role, while nearly three-quarters (74%) said there is still room to grow their observability practice. In fact, 81% of the 450 C-suite executives that participated in the survey said they expect to increase observability budgets in the next year, with 20% expecting those budgets to increase significantly.

    Overall, the survey finds that lack of resources (38%), skills (29%), understanding of the benefits (27%) and strategy (26%) are top barriers to achieving observability.

    Observability, in one form or another, has always been a core tenet of DevOps best practices. Most DevOps teams have relied on monitoring tools to observe a specific process or function. The challenge is those monitoring tools track a pre-defined set of metrics such as resource utilization. Ideally, observability combines metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshot issues without having to rely solely on a limited set of pre-defined metrics.

    Nearly three-quarters of respondents (72%) noted that IT teams today need to toggle between at least two different tools to manage IT, with 13% having to use more than ten different tools to monitor the health of their systems.

    In contrast, observability platforms make it possible to correlate events across both applications and infrastructure. This capability makes it easier for analytics tools to identify anomalous behavior indicative of the root cause of an IT issue. Armed with these insights, it becomes a lot simpler for IT teams to resolve issues faster.

    The New Relic survey notes that 60% of respondents still monitor telemetry data at the application level, which indicates that a massive amount of valuable telemetry data is largely going unused. A full 91% of IT professionals that responded to the survey noted that observability is critical at every stage of the software life cycle, especially when it comes to planning and IT operations.

    Top benefits cited include faster deployments (27%), more cost-effective use of IT resources (25%), better digital experiences (23%) and improved productivity (22%). The top use cases cited involved digital transformation initiatives (42%) followed by cloud optimization (37%), DevOps processes (36%) and bringing products to market faster (36%).

    Buddy Brewer, group vice president and general manager for New Relic, said observability will become a more pressing issue in IT environments, thanks to the rise of microservices-based applications running on Kubernetes. A full 88% of IT decision-makers New Relic surveyed said they are exploring Kubernetes and containers at some level right now, but only 10% said they have deployed them in a production environment. A total of 40% expect to be in production within three years.

    In general, it’s become critical for IT teams to be able to query data in real-time to resolve issues that are becoming more challenging to resolve at a time when organizations have never been more dependent on IT. Sampling data in the hopes of discovering issues is no longer sufficient, noted Brewer.

    The challenge, of course, is that most IT teams have been using legacy monitoring tools for so long that it’s still hard to imagine there might be a better approach. That doesn’t necessarily mean all those legacy tools will be immediately replaced, but it does mean many of them may simply fade away over time.

    One way or another, most IT teams will soon be able to observe IT environments more deeply. Developers increasingly are taking advantage of open source tools like OpenTelemetry to instrument applications in a way organizations can more easily afford, regardless of whether they fully appreciate the nuances of modern observability versus traditional monitoring.

  • 4 Benefits of Integrating a Language With a Database

    4 Benefits of Integrating a Language With a Database

    One of the hallmarks of a truly modern programming language is the coupling of a language—for creating applications, devising algorithms and solving business problems—with an underlying database. When there is practically no separation between a database and its programming language, developers immensely increase their productivity, maximize the effectiveness of the code they write and provide unparalleled speed and flexibility in supporting business needs.

    Predicating a programming language on a database delivers these advantages by enabling developers to treat data as if it is in-memory, liberating them from the burden of manipulating how data is represented in the underlying database. This one simple advantage exponentially increases the flexibility for addressing business problems and, when used with advanced logic languages, enables developers to write applications in a fraction of the time and with less effort than it would otherwise require.

    Specific benefits of tightly coupling a database with its programming language include eliminating the time-honored mismatch between data structures and database representations, smart caching with transactional technologies for committing or rolling back database changes and automatically changing object definitions.

    These benefits remove the database as an otherwise complicating factor in supporting business use of data by freeing developers to flexibly innovate solutions—and speedily implement them.

    In-Memory Manipulations

    Developers focus on manipulating data structures to solve business problems. Traditionally, this concern was hamstrung by the onus of translating those structures into how data are represented in the database, a time-consuming necessity detracting from programmers’ attention to business problems. By fully integrating an object-oriented database or graph database with its programming environment, users can manipulate data objects in memory and they’ll automatically persist to storage. Developers can solely focus on working with data structures for business objectives without spending just as much, if not more, effort wrangling data’s representation in the database.

    Programming languages create this effect when they are imbued with an intelligent caching layer that persists in-memory data manipulations into the database. This advantage requires basing the programming language on a specific database. It eliminates the mismatch between working on data structures and toiling to get the underlying data to and from disk.

    Smart Caching

    The caching layer also tames the inherent difficulties in data objects pointing to other objects, which is a hallmark of object-oriented systems and graph databases. These databases require intelligent caching because one object can conceivably include the majority of the database by pointing to objects that, in turn, point to additional objects. Tight coupling between that language and its database fixes this issue so developers cache what is needed to work on data in memory while automating its impact on disk. Such caching is significantly improved with transactional technologies so developers can specify when they want their modifications saved in the database.

    This way, if they make a mistake they can simply go back in time before it was made and undo it. Conversely, after successfully completing their work, they can easily commit changes to the database. Like the other advantages, this benefit boosts developer productivity to match that of business requirements. It adds to the flexibility programmers need to innovate solutions for mission-critical objectives by writing or integrating applications.

    Object and Class Definitions

    The third boon of basing a smart programming language on a database is the capacity to dynamically change the definition of data objects. With conventional approaches, this task requires developers to stop writing or operating applications and manually write code to adjust the classification, which may involve either reading or writing the data in and out again. But with no separation between the database and its sufficiently smart programming language, such coupling can effectively keep track of classifications while automatically modifying them as needed.

    Developers can seamlessly add or delete features without manual coding, which also furthers their productivity. For example, if they add an attribute to an object, the next time they see it it’ll magically have the new feature. Alternatively, if they create a new feature of an old classification and decide to delete it, they won’t see it anymore. Best of all, these changes occur without rewriting the classification.

    Advanced Logic

    There is one more capability of very smart programming languages: They can combine these advantages with advanced logic languages such as Prolog. Prolog, or a subset of Prolog called Datalog, can instantly be used as a query language. In addition, it becomes very easy to create rule-based applications with Prolog because one can write declarative, logic-based rules with minimal coding. For example, they can specify a series of event-based rules detecting customer churn, money laundering or any important business outcome without being impeded by unnecessary database concerns to deliver time-to-value that’s unmatched without this method.

    Basing a programming language on a database improves developer efficiency and effectiveness by letting developers work on data in memory and persisting changes to storage, intelligently caching data and rolling back changes as required, and dynamically adjusting definitions.

  • 3 Building Blocks for Enterprise Digital Transformation

    3 Building Blocks for Enterprise Digital Transformation

    DevOps has gone from a new idea to a buzzword in every boardroom over the last decade. With society increasing its reliance on digitization and pushing their preferences for speed and convenience, enterprises of all types have had to change their business culture to help their teams to work together with greater speed and autonomy.

    While the pandemic has undoubtedly heightened the importance of DevOps in the workplace, its widespread use predates the last few years. HGS Digital research from as far back as 2018 found that only 3% of software development businesses had never heard of DevOps. The 2021: Future of the Atlassian Ecosystem report revealed that 54% of organizations have implemented a DevOps strategy—up from 48% in 2020. A further 27% of respondents are hoping to adopt a DevOps strategy in the next three years.

    Indeed, DevOps is now mainstream, and the uptick in job listings for ‘DevOps engineers’—as well as enterprises’ quickness to tout their ‘experienced DevOps teams’—is perhaps further evidence of this. However, some of these postings and sentiments can also be considered red flags as they suggest that organizations are applying DevOps practices to isolated teams. Or worse, they are simply labeling traditional engineering roles with the DevOps label rather than implementing a complete mindset shift that applies to the entire organization and enables it to release reliable products at a much faster pace.

    With this in mind, here are three key building blocks for enterprises looking to avoid common downfalls and effectively scale their DevOps strategies. These will help them change the way they work and think across all aspects of development and operations.

    Changing Culture and Empowering Employees

    Everyone needs to be on board for DevOps to be successful, and buy-in is strongly dependent on the business culture they are working within. For example, Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations. And the reasons why have to do with issues around organizational learning and change.

    To put it another way, if employees don’t understand DevOps’ deeper thinking and benefits both to them personally and to the wider group, they will naturally be resistant to the change. It is, after all, an entirely new way of thinking for many departments, especially operations teams who traditionally reduce risk by minimizing change and taking things slowly. DevOps encourages them to speed up with minor changes delivered through continuous integration operating in a fail-fast and often fail-forward pipeline.

    Therefore, educating employees is vital for success. In particular, organizations should give staff a clear idea of how it will feel to work differently. Shared definitions of success, shared vocabulary and shared visibility of the work to be done is key. With that—and along with sharing actionable insights that teams can apply to their work and then observe the results—no matter where they are in the pipeline, the real value of DevOps can be achieved.

    The reality is that people are the most critical component of any DevOps transformation, making their commitment to the cause non-negotiable for success. Despite the tech-heavy nature of software development, soft skills like communication, collaboration, flexibility and decision-making must be prioritized as much as security, coding and infrastructure knowledge. It’s imperative that all businesses look to adopt a DevOps mindset and implement these traits into their culture in the future.

    Applying Four Fundamental Processes to the Foundation of DevOps

    That said, a successful DevOps transformation can’t happen unless enterprises step away from traditional IT’s ‘trust but verify’ methodology. Instead, they must incorporate a set of essential processes that empower everyone to work more efficiently and effectively toward achieving faster, high-quality software delivery to suit the end-user’s needs. These fundamental processes include collaboration, automation, continuous integration and continuous delivery (CI/CD) and monitoring.

    While collaboration has been one of the most significant rallying cries for enabling globally distributed IT teams to align their goals and meet their objectives, automation has also been highly crucial. Many of those ingrained in DevOps environments will tell you that automation is what makes DevOps highly valuable. It helps teams achieve high levels of efficiency and allows employees to focus more on complex problems and less on repetitive tasks. When a company’s automation strategy is aligned with its broader business goals, it can help deliver value at scale.

    But as is the nature of software development, problems can arise. And this is where continuous integration and delivery come into play; it forces developers to merge their source code updates with others far more frequently than they might otherwise choose to. Operations teams can ensure they’re not creating a bottleneck with manual testing to get releases out to users. The approach means smaller changesets; helping to identify, target and resolve bugs more efficiently. This increases the flow of work, the quality of releases and helps to avoid nasty problems at the end of the development cycle.

    But there’s no point in having a speedy, heavily automated CI/CD process with a genuinely collaborative culture if enterprises don’t take the time to measure what’s working and assess which actions need to be improved. This is why an effective DevOps plan needs to be built on the mantra ‘implement, measure and improve’. After all, DevOps is about maximizing value and efficiency through increased visibility of work and constant feedback. Measuring real-time metrics becomes vital to ensure business’ transformations are in line with their objectives at all times. If enterprises stick to these fundamentals, they’re well on their way to a successful DevOps strategy with complete buy-in.

    Adopting the Right Tools for Transformation

    As teams grow and DevOps processes scale, predictable performance is imperative. Therefore, the enterprise’s tools must be available around the clock and should perform at a high level to support their collaborative pipeline.

    But using DevOps tools doesn’t automatically mean organizations are applying DevOps principles. The value of tooling is limited by businesses’ commitment to using them holistically with the sort of culture and processes mentioned above. It is this combination that allows them to transition how they develop and deliver their products. With all that said, it’s important to understand how important it is to adopt the proper toolchain—and the wide variety of choices and combinations available—this is why it’s easy to understand why decision-makers might become overwhelmed.

    After all, there’s a lot to keep in mind. They need to choose tools that step up their collaboration, keep context-switching to a minimum, aid automation, encourage visibility and allow for effective monitoring. But there’s also the risk that they’ll pick the solutions that they feel most comfortable with, which can be counterintuitive to transformation. This approach can lead to a tool binge, bringing on too much technology where integration isn’t a priority, and leaving enterprises with nothing that does the job they need.

    With this in mind, enterprises need to take the time to consult on which tools are right for them while constantly keeping the fundamentals of DevOps in mind. To illustrate just how valuable this is, DORA and Google Cloud’s 2019 State of DevOps report found that the highest performing engineers are 1.5 times more likely to leverage easy-to-use tools. Meanwhile, failure to do this is perhaps a primary reason why a separate study from the DevOps Institute uncovered that the DevOps transformation journey is still arduous for more than 50% of respondents.

    Taking the Next Step Toward DevOps

    A successful DevOps transformation rests on in-depth understanding, mass buy-in and an organization-wide adoption of fundamental principles and practices. When this agile mindset is applied to the people, processes and tools that make up an organization, enterprises can drive significant change across their teams while increasing their products’ reliability, stability and security.

    It’s always important to keep in mind who DevOps is designed to benefit the most—the customer. This mindset is particularly valuable in today’s landscape, where businesses and consumers alike are flush with more choice than ever. With speed and convenience now at the forefront of most people’s purchasing decisions, DevOps can play a huge role in helping organizations strive for greatness and offer the customer something they didn’t even know they needed. Using the above building blocks, organizations of all sizes can dramatically improve their customer experiences and work more efficiently to quickly get the right products into their hands.

  • Do’s and Don’ts of Phased Rollouts Software Delivery

    Do’s and Don’ts of Phased Rollouts Software Delivery

    When it comes to app stability and user experience, the “move fast and break things” approach is a recipe for disaster. To protect brand reputation and to stay ahead of evolving needs and customer expectations, leading Silicon Valley companies’ software engineering teams have adopted phased rollouts, a software development method that involves the gradual implementation of a new feature to a smaller cohort of users at one time rather than all users at once.

    Phased rollouts help companies maintain the highest-quality customer experience (CX) for their users while making changes and software updates. When significant features and updates aren’t rolled out to production all at once, the organization’s software engineering team doesn’t have to deal with all the potential implementation issues at once. With phased rollouts, engineering teams catch issues early in the process so they can quickly fix them and resume the rollout of the experiment, which prevents issues from impacting millions of users down the road.

    While companies everywhere try to emulate the app development techniques of these Silicon Valley tech leaders, many are unable to achieve successful phased rollouts at scale. What they often don’t realize is that before even implementing a phased rollout approach—whether it be to 5%, 10% or 15% of their user base—there are a few steps that must be taken to ensure success. Below, I’ll walk you through the do’s and don’ts of a successful phased rollout plan.

    Do: Release Stability Management

    Companies must drive consistently stable app and web experiences in order to succeed in the market today. Therefore, it’s critical to continually monitor the stability of releases throughout development and testing to catch problems early and decide when to roll features out to users. By measuring and monitoring app stability in real-time, release managers inject accountability, predictability and complete peace of mind into the organization. Taking control of release stability management helps engineers deliver stable applications to drive world-class digital experiences.

    On top of that, software development teams must constantly improve mobile and web apps with new features and capabilities that better enable users to accomplish what they want to do. These kinds of improvements give companies the competitive edge they need to survive in today’s competitive business environment. In addition, monitoring release stability provides engineering teams with real-time visibility into every issue impacting application stability and CX. This level of visibility is critical for quickly diagnosing and understanding the root cause of errors so that engineers can roll out fixes before users are negatively impacted.

    Do: Testing and Early Access

    For a phased rollout, engineering teams must run A/B tests and quality assurance (QA) testing. A/B testing (also referred to as split testing or bucket testing) is a method of comparing two versions of a web page or app against each other to determine which one performs better. This includes trying out features like different screenshots, videos and even different app icons to measure which format users like the most.

    QA testing ensures that the organization delivers the best products or services possible by detecting usability issues that might not be technical. It tests for any problems that impact the end-user experience, from poor navigation to slow load times or unclear web copy.

    With phased rollouts, you must also provide early access to new features for select users to collect feedback and stamp out critical issues before launch. Many software products collect user feedback by including a small checkbox somewhere asking users to help make the software better by sending insights into how they use the application. In addition, social media has become an undeniable avenue for collecting candid user feedback. We’ve all seen it—when a platform changes its interface for certain users before others, users will post on social media sites about whether they are pleased with the new update or not. Historically, there has been backlash when significant changes are made and the company then has to decide whether to keep, change or cancel the new changes to the platform.

    As mentioned above, with an app stability monitoring tool, you can see if new features or experiments are introducing new stability issues and make decisions about pulling back or rolling out to a larger subset of users. By conducting testing and allowing early access to only a specific cohort of users, software engineering teams can balance release speed with application stability to create the best experience possible.

    Do: Allow for A Staging Period Before Going into Production

    As you launch new features, you’ll want to test them in a production-like environment after they go through QA testing. This is called staging, and it has become a popular concept with Silicon Valley companies. Staging is a near-exact replica of a production environment for software testing. Staging is meant to test code, builds and updates to ensure quality under a production-like environment before application deployment.

    A production-like environment is similar to when the app is released into production for users, but it’s not public yet. It provides an accurate view of how the update or new feature will operate and look in a production environment to avoid glitches that are only noticeable in production. Staging can include manual tests or, in some cases, engineering teams use automated software testing, which is more costly to implement and may only be attainable for larger enterprises.

    In this phase, software engineers should conduct additional tests and experiment with the new features to ensure that these capabilities—when released to production or to the larger user base—will not compromise the app’s stability. The last thing you want is for a new feature to break the user experience.

    Don’t: Try to Fix Every Bug or Error as it Occurs

    Since engineering teams often don’t have the bandwidth to fix every coding error that should arise, they need to prioritize and fix the errors that impact customers directly in order to protect revenue. Although organizations should have visibility into every error or bug, not all of them are worth fixing. This causes the signal-to-noise ratio that plagues developer efficiency.

    This is where app stability management plays an essential role. However, many of the app stability monitoring solutions on the market today can help with identifying errors, but leave it up to development teams to figure out which ones need to be prioritized. Engineering teams have to quickly determine which errors are the most urgent to fix, so they need to have reliable tools such as an app stability and error monitoring platform to provide them with visibility to make these important decisions in real-time.

    Phased Rollouts for Progressive Delivery

    Phased rollouts allow software engineers to continuously optimize the digital experience, without impacting the whole user base and negatively affecting the brand. Once mastered, phased rollouts can be used as part of a cutting-edge progressive delivery approach to software engineering and development.

    A progressive delivery approach includes shipping code (sometimes unfinished code) to a production environment multiple times a day, exceeding many companies’ risk tolerance. In order to do this successfully, engineers must have control over who can ship releases and when, and which users can access certain features and updates at what time. Phased rollouts provide a way to shield the majority of customers from the failures that occur at those rapid release speeds. To ship new software releases faster, engineers have to spend less time on QA and testing, but that doesn’t mean they should be overlooked completely. Then, by delivering the new release to a small subset of users first, you can manage risks more effectively and iterate accordingly.

    It’s important to call out that if the engineering team is making minute changes that no users will see or care about, you don’t need to use a phased rollout approach. That said, if it’s a significant cosmetic or operational change, such as updates to the UI, then phased rollouts are crucial. A phased rollout strategy is key for making software or app updates at scale that are necessary for a successful launch in today’s highly competitive market.

  • Driving E-Commerce Transformation with Microservices

    Driving E-Commerce Transformation with Microservices

    It’s no surprise that COVID-19 has accelerated digital transformation, but just how fast these changes have occurred is incredible. According to recent research, companies have accelerated their share of digital or digitally enabled products by up to seven years.

    These changes are impacting every sector in every region around the world, but they are being felt acutely by companies that sell their solutions online—which I imagine includes your company. To thrive in the new normal of digital commerce, businesses need to be supported by a fast, flexible technology architecture that can adapt to new products and go-to-market strategies and can be spun up on the fly. The best—and really, the only—way to do that is with a microservices architecture.

    Why Monolithic Architectures are Uniquely Bad for Commerce

    While monolithic architectures can be simple to develop, test, and deploy, their limitations, especially in the age of digital, quickly become apparent. Software becomes too large and complex to make changes quickly, or correctly. Bugs can be a disaster, and monolithic architectures are often a barrier to adopting new technologies since any change requires significant time and monetary investment to update the entire application.

    These limitations are even more glaring in the age of subscriptions. In today’s market, if you are selling products or services online, you are likely offering subscriptions. In fact, 95% of companies offer at least one subscription-based product. For subscription commerce businesses, the need for microservices architecture is even more critical. A recurring revenue strategy requires frequent adjustments and easy integration with other systems, requirements that a monolithic architecture often can’t accommodate.

    Scale Is the Critical Factor

    One of the greatest benefits of a microservices architecture is the ability to scale quickly. Monolithic architectures are much more rigid because everything has to be scaled at the same time. In contrast, a microservices architecture allows organizations to scale individual components of an application to meet niche use cases. Moreover, because microservices give you the freedom to update individual components, organizations can make changes without any interruption to broader systems. In other words, with a microservices architecture, developers are able to upgrade the airplane while it’s in flight.

    There’s internal scale, but external scale through ecosystems is also an important consideration. Recent research found that 56% of executives believe engaging in ecosystems is the most effective way to access new markets, while 55% believe that the new capabilities gained from partnering are essential to building new capabilities. Ecosystem participation—whether as an operator or a participant—requires timely integration and development, a reality that monolithic architectures just cannot support.

    Microservices as a Recruitment Tool

    Innovation and digital transformation aren’t just business needs. They can also be one of the most powerful recruiting tools available to draw in the best talent. The job market is rife with opportunity for prospective employees—especially now, during the Great Resignation, where a significant number of employees are looking to change jobs—and businesses need to embrace every advantage they can to attract top talent.

    Legacy technology can have its place, but it can also be a red flag for job candidates. Most developers want to join an organization that values innovation and gives them the freedom to build unique products and solve meaningful business problems, which microservices development offers. A microservices architecture can also make onboarding new talent easier, since developers aren’t obligated to learn every facet of the architecture. It’s a win for new employees and existing organizations alike.

    Driving Transformation Through Microservices

    The needs of any given business are always changing, but digital and subscription commerce businesses have proven to be extraordinarily dynamic. Monolithic architectures of the past simply aren’t equipped to power digital transformation or support commerce businesses when they emerge on the other side. Microservices may come in a smaller “package,” but they will deliver much bigger benefits to your business in the long run.

  • Accelerating Software Testing

    Accelerating Software Testing

    Yves Junqueira is the CEO of YourBase, a software testing accelerator for large codebases. He talks with Alan Shimel about the company, accelerating software testing and the impact on developer productivity. The video is below, followed by a transcript of the conversation.

    Alan Shimel: Hey, everyone. Thanks for joining us here on another segment for our TechStrong TV. My guest this segment is a new company, first-time guest on our TechStrong TV, Yves – and I’m gonna really mispronounce his last name, Junqueira. I’m supposed to have that rolling R, and I just don’t do rolling R’s. Yves, I’m sorry, man. Welcome to TechStrong TV.

    Yves Junqueira: Thank you, Alan. It’s great to be here. You did it good.

    Shimel: Not so good. You know what? In case your mom or your family’s watching, say your name correctly for ’em.

    Junqueira: Yves Junqueira.

    Shimel: Junqueira. Okay. We’re gonna call you Yves, and we go from there.

    Junqueira: Sounds perfect.

    Shimel: So, looking from your background, are you up in Seattle, Toronto? Toronto?

    Junqueira: That’s Seattle.

    Shimel: Seattle. Yes, the mountains. And you know what? Welcome. I’m gonna let you give a little introduction to your company, and you’re a cofounder of it, but go ahead.

    Junqueira: Gladly, yeah. Our company’s called YourBase. We build developer tools for very large code bases. Specifically, we are a software-testing accelerator for large code bases. I used to work at Google for almost ten years, and my cofounder, John, was a principal engineer at Amazon, at AWS. And, yeah, we’re excited to – I’m very excited to be here, Alan.

    Shimel: Absolutely. Well, I’m excited to hear about what you’re doing. So you’re a code accelerator?

    Junqueira: We are a software-test accelerator, yeah.

    Shimel: Software-testing accelerator, excuse me. What exactly is that?

    Junqueira: Yeah, so it’s very important when you’re building software that you actually know that the software is working. You usually have very large teams that’re creating code, and you don’t want one developer to be stepping on each other – on the other’s toes. And so you need a lot of testing to make sure that when you make changes to the software, it’s still working. But as you’re adding new features, you’re adding new tests, and you add new features, and you add new tests, and over time the number of tests in your code base can grow very, very quickly, and it can become a very big problem for developer productivity and developer happiness, because it can take a very long time to actually test code. If you’re making even a small change sometimes in a large code base, it can take hours to ensure that that change works, to run all the tests. So that’s what we help with.

    Shimel: So you’re automating testing. Is that fair?

    Junqueira: We automate the test selection of testing. So, yeah, we help run the tests, but most importantly we help select what are the right tests that are safe but that have to be run for each change. Without having to test the entire world, we use a process called – we use tracing of code to build a dependency graph to then select the right test to run and then just make things more productive for developers.

    Shimel: Sure. Of course, our audience is a very technical audience, familiar with QA and testing and developing. So you’re running a trace route on the code as it’s entered into Git or – because it’s pre-deployment code, right?

    Junqueira: That’s right. It’s pre-deployment code, yeah.

    Shimel: So as the code is put into Git or some other sorta repository, you select what’re the right tests to run and run it on the code. So this all takes place within the repository like a Git-ops kind of thing?

    Junqueira: Yeah. It can take place in the repository connected with a CI, with a continuous-integration tool, or it can also happen during local development. You can have multiple developers working at the same time on the same code base but perhaps making slight – different code changes. And with your base, they are testing their code but also using their colleagues’ testing to – so that they don’t have to repeat the test that their colleagues already ran for the same code base. So they only have to test exact the small changes that they made on their code.

    Shimel: I love it. Sounds great. And then I don’t wanna use the buzzwords, but is it some sort of AI/ML that is picking what’s the right code – what’s the right test to run for this particular code for these particular changes?

    Junqueira: That’s an important question. It’s not AI. We use just simple data structure and algorithms that we collect when doing tracing. And this is actually important, because if we were using just AI or any sort of statistical approach, we would only get a limited confidence that we are testing the right things. So imagine that you’re a financial institution, right, or a hedge fund, where tests are very important. If you don’t catch certain bug, it can cause millions of dollars in losses, right, in lost revenue, for example. So it’s very important that you actually detect the correct regressions in your code, and if we were using just a simple AI approach, we would only, let’s say, have 90 percent confidence that we were running the right tests in your code. That is not enough. So our customers need assurance. They need full confidence, so we use an approach that is a little bit more intrusive, let’s say, because it’s detecting every single function called that is happening during the tests. So it has a little bit of a performance impact during the initial test. But on the other hand, it just provides full confidence rather than being 90 percent confidence that an AI approach would have.

    Shimel: Got it. I mean, big companies using this, small companies, anyone? Who’s the target user here?

    Junqueira:Fortunately, we can scale from small to very large code bases. So we have customers that are very small, just small startups that are getting started but that really want to have the fastest possible development process. But we also have very large code bases of very large companies, public companies, Fortune 500s, that want to keep moving fast. It’s difficult. Imagine if you have a software product that really needs to evolve quickly. Customers these days demand that software developers – that software companies evolve their products quickly. The customer needs are changing fast, and so they need to be able to make software changes very quickly and do it at – have high velocity with the most productivity possible. So what we allow those companies to have is even though they have a very large code base, the larger companies, they can be almost as productive or as productive as if they had a small code base, and this is really magical. This is something that we’re very proud of providing to these companies.

    Shimel: Absolutely. You know what? People always wanna know this, and I realize it might be coming outta left field. Interesting. You worked at Google ten years. Your cofounder’s an AWS guy. How did that come together?

    Junqueira: Yeah. It’s actually a funny story. We met at a random coffee shop. After I had left Google, I was working at random coffee shops here in the outskirts of Seattle, and I had my laptop with me with a bunch of developer stickers there like Linux and Python and GOAL like developers often have. And John had the same, and so we just looked at each other’s laptop. We were at this coffee shop here, and we – okay, we should chat, ’cause we us a lot of the same technologies. So we started talking, and over time I invited John to come to my weekly table games at my house. I host a game night every week, and John started coming, and I started talking about my project, and he was fascinated by it, and he said that software testing and developer productivity are a huge thing for him. And over time, he decided to join. I’m very lucky that he joined me at YourBase.

    Shimel: Love it. And then talk a little bit here about going to market. How’s it been so far?

    Junqueira: Yeah. We spent a long time perfecting the technology. This is a very tricky software. If you get things wrong, you may end up – your customers may end up shipping bugs. My customer’s gonna end up shipping bugs that should have been caught by the tests. But if I don’t decide to run a test or if I don’t give them right insights, they might actually introduce bugs and be less reliable than they were before. But we started just last month. We launched our first public beta now, and we’re very happy about that. So we have a number of design partners that are working with us on this initial release, and people – customers are very happy. The feedback has been fantastic. So last month we launched it to the outside world, and we made a public beta. Now people can just download it from just going to the website, yourbase.io. Anyone can download and test it. We currently support Python as – for code bases. Our technology has to be implemented on a language-by-language basis. So for now we support Python, but we’re going to support Ruby sometime soon. And we’re very excited. The reception from people has been amazing. It’s really fun to be at this stage of the company, where we actually are ready to talk about it to the outside world.

    Shimel: Excellent, man. It is. Having founded more than one company, more than four companies, five companies, it is an exciting time, and I wish you nothing but great luck and success with this. I want to get into the kinds of testing you’re doing, functional testing, unit testing. Is it selenium kinda stuff? What are the kinds of tests you’re doing there?

    Junqueira: That’s a great question. We are very good at tests that don’t cross process boundaries for now. This can be sometimes unit tests and functional tests. We don’t currently support UI tests yet, in part because there are good companies out there that’re already serving this market, and there was just nobody that was focused on the backend and in unit testing and functional testing. But this is a big space, and we’re just getting started. We have feedback from folks that we – they want support for more things, so that’s something that we’re excited to work on.

    Shimel: Excellent, man. Yves, I wanna thank you for coming on and telling folks about YourBase here on TechStrong TV. Come back. Keep us posted on your progress, and best of luck.

    Junqueira: Thank you so much, Alan. It was great to be here, and, yes, absolutely, I would love to come back.

    Shimel: My pleasure. Say your name for us one more time so I don’t – just after I mangle it, at least they got it right.

    Junqueira: Yves Junqueira.

    Shimel: Junqueira. Yves, thank you, man.

    Junqueira: Thank you, Alan.

    Shimel: Oh, the website, yourbase.com?

    Junqueira: Yourbase.io.

    Shimel: IO, yourbase.io, Y-O-U-R-B-A-S-E-dot-I-O. This is Alan. We’re gonna take a break. We’ll be right back with our next guest.

    [End of Audio]