staging-devopsy.kinsta.cloud

Category: Features

  • Why Your Next CIO Will Be a CPO

    Why Your Next CIO Will Be a CPO

    Here’s what the transition to CPO means for everyone in IT

    Over the last 20 or so years, the evolving role of the CIO, or chief information officer, has been a hot topic of conversation in most large enterprises. It’s a topic that doesn’t just affect those breathing the rarefied air of the C-suite but has concrete implications for everyone in the IT organizations these CIOs lead.

    For these last two decades, most larger companies in traditional industries have vacillated between periods of enthusiasm for technology and so-called “digital transformation”—in which CIOs are viewed as wizards bringing new wonders, changing their entire business models and growth trajectories for the better—and periods of disillusionment, with late projects, missed requirements, user and customer dissatisfaction and cost overruns—in which the CIOs become scapegoats. In these latter times, they often are replaced by CIOs of a different stripe, often moved laterally from finance or general management roles and charged with cost-cutting and predictability as top priorities. Even if the existing CIO keeps their job, they’re often pushed to change the way they operate and lead. When this happens, the entire IT organization finds it needs to change its pitch and priorities to sustain funding for every project and every function, resulting in whiplash. That itself contributes to the perception, and often reality, of late and unfinished projects and unpredictable IT outcomes. It is usually at that point someone realizes the newly efficiency-focused organization is losing market share, brand perception or customers to competitors that are more technically innovative (often digital-first upstarts challenging incumbents in a given industry), and the organization pivots back to “techthusiasm” and a different kind of CIO again. And more whiplash. And so it goes.

    During the periods of techthusiasm, some organizations replace or supplement the CIO title with newly coined titles such as CDO (chief digital officer), CAO (chief analytics officer, an uncomfortable namespace collision with the established corporate title of chief accounting officer), or chief experience officer (no one dares make that into a redundant CEO three-letter acronym).

    In the disillusioned periods, the CIOs stay CIOs as long as they can hang onto their jobs. Title creativity is as suspect as any other kind of creativity.

    Meanwhile the vicious cycle continues: techthusiam -> disillusionment -> retrenchment -> falling behind -> renewed techthusiam.

    As a longtime CPO (chief product officer) for enterprise software companies whose customers predominantly have been these seesawing IT organizations, I’ve been seeing of late the start of a powerful conceptual shift that is the escape route from this vicious cycle.

    So what’s the magic shift in thinking?

    If you’re in a traditional business in which the technology your IT organization delivers merely facilitates people doing their jobs and interfacing with each other and customers, your primary threat in the 2020s—especially with a pandemic interrupting face-to-face interactions—is digital-first, new entrants that conceive of their product as the software and the people as the behind-the-scenes back office and failover when the software doesn’t work. Every business is now a software business, and the software is now the product; some companies in a given industry just happen to be better software companies than others. Such digital-first entrants range from Amazon to Netflix to Workday to Sofi to Wealthfront.

    However, you don’t leap from being ADP to Workday simply through what so far has passed for “digital transformation” led by a CIO, CDO, CAO or whatever another newfangled c-level tech title, as a peer to product leaders whose organizations came from the pre-digital business and look to the CIO, CDO, CAO, etc., to simply execute the technology support.

    What do true software companies in traditional industries have in common? They have CPOs! (Chief product officers, not chief procurement officers or even chief pandemic officers.) Analytics and digital are not in their titles because these are assumed means at their disposal. (I’m thinking of taking on the excesses of our fetish for data in IT and software today in a future column. Send me thoughts if you have them.)

    The role of the CIO was to deploy technology efficiently to support the company’s strategies and plans. The role of the CPO, as inherited from pure technology companies, is to develop and maintain a deep understanding of the customer and market and guide the delivery of products to best meet and monetize their needs, and do so ahead of any and all competition. The traditional CIO derives the why and what from other parts of the organization and supplies the how. Transitional versions of the CIO and the CDO and other neologisms may start to encroach on the what. But the true CPO drives the why and what—and the how if they also have engineering, or collaborates on the how with a CTO or head of development if not. (My friend Kaj van de Loo has an excellent discussion of CPO vs CTO and the trend toward combining the roles here, implicitly focused on digital-first companies, here.)

    Does this sound broad, even encroaching on CEO territory? Well, yes. It’s no accident that former product chiefs are the new CEOs of Google and Microsoft.

    So what does that mean for you if you are in an IT organization?

    Well, first, while your organization may or may not change the actual title to CPO from CIO, it’s important for your career to recognize when the definition of their job becomes that of what a CPO would do in a “pure” software company. If you see the signs that the CPO is guiding the IT organization to become the experts on the market and customers and invent new digital-first products, that shift is underway. It’s good news for those in IT because it means you no longer are simply a cost center to be minimized and even offshored but a driver of the business and value.

    Once you realize you are now in a product organization and not an IT organization, you need to start thinking about what a (software) product actually is and how that differs from what IT delivered before.

    IT traditionally operates on a project and service maintenance basis. Projects have a defined scope and concrete, finite objectives to be considered complete. They have beginnings and ends. Projects either result in the existence of a service that is operated and maintained on an ongoing basis or deliver a discrete set of changes to a service that already existed. Project teams form, deliver the project, and then break up and are reassigned to the next project. Much smaller maintenance teams (usually as low-cost and low-skill as the organization can get away with) make sure that the resulting services stay alive and maintain agreed service levels and consistent, fixed functionality (until the next project to evolve the service is funded).

    True products are quite different. Products have many yearslong life cycles, from inception through launch, constant active enhancements and growth and then eventual end of life. During these life cycles, customers reasonably expect new capabilities to increase and existing capabilities to evolve for better usability and effectiveness.

    Products are not defined by a particular architecture or features but their mission on behalf of the market, users and customers. During a product’s life cycle, the product team may discover new feature ideas or develop new architectural implementations to replace or enhance old ones, all within the umbrella of the same product and mission.

    Product teams maintain staffing levels throughout a product’s life cycle to continue delivering new capabilities and technical enhancements, not just keep the lights on. Every member of a high-performing product team takes the team’s mission as its own and strives to build holistic knowledge of the mission and the product, and contribute new ideas and challenge existing ones—not just a defined role of a product manager or product owner or architect.

    Product teams are acutely aware of competitive and substitute products and strive to become and stay their target customer’s first choice in the face of competitive product teams doing the same. Product teams regard selling, evangelizing and making their products available to their market as being as much a part of delivery as software development and integration. Product teams see opportunities to interact with target users and customers as invaluable two-way dialogue during which they get to show and get reactions to the shiny features they’ve built, as well as discover latent needs that drive ideas for new features and maybe even entirely different conceptions of the overall product.

    In an IT organization that is transforming itself into a product organization, these ideas and this approach apply not just to teams working on “external” products for paying customers outside the organization but also in equal measure to internal products that either serve internal end users, such as a finance or payroll system, or become services that developers on other teams incorporate into their products or platforms on which other developers build, such as a common identity service, customer data pipeline or private cloud. In today’s world, every such official internal service resides in an environment with competitive third-party services and possibly competing internal approaches, and in which what was state of the art yesterday is not viable today.

    Conversely, a well-conceived, designed and managed internal product may turn out to be the basis of a massive external business. Witness AWS and countless DevOps startups that began with the old story, “We built this thing to support our social media/dating/gaming/whatever B2C startup and it turned out to be something other companies wanted to buy more than people wanted what our startup was doing.” Managing internal services and platforms as products is the way to both ensure that the original mission is fulfilled and new opportunities are discovered, too.

    I’ll come back to some of these themes in future columns, but for now, I’ll leave you with this link to a podcast featuring a small Brazilian fintech startup that I believe is one of the best recent examples of a true product team’s approach: Their level of customer intimacy enabled them to identify a new product that solved problems within the scope of their mission and on behalf of their target users that a lesser product team would not have done. How would this kind of product thinking apply to the products in your IT organization?

    Until next time,

    Christina

  • Rewind Acquires BackHub to Protect GitHub Repositories

    Rewind Acquires BackHub to Protect GitHub Repositories

    Rewind, a provider of a software-as-a-service (SaaS) platform for backing up cloud services, today announced it has acquired BackHub to gain control of a platform for backing up GitHub repositories.

    Based in Germany, BackHub adds a data protection platform to a Rewind portfolio that includes offerings for backing up everything from QuickBooks to Shopify. Fresh from raising an additional $15 million in funding, Rewind CEO Mike Potter said BackHub addresses a critical issue involving the protection of some of the most valuable intellectual property any organization has in a cloud service. GitHub, a subsidiary of Microsoft, is the largest host of source code in the world, with over 40 million users and 190 million repositories. BackHub claims it protects data in those repositories for more than 1,000 organizations.

    Rewind GitHub backup

    While GitHub itself is a reliable cloud service, the code residing in GitHub is subject to the same potential threats as it would be in any other cloud service. It’s not uncommon for a malicious actor to gain access to credentials that they exploit, for one reason or another, to delete or alter data – or, in the case of GitHub, code. BackHub makes it possible to back up code stored in GitHub to another cloud service where it can be easily recovered.

    Potter said the ultimate goal for Rewind is to make it possible to back up the entire cloud. Achieving that goal will require both additional acquisitions and internal product development, said Potter.

    In the meantime, the company is focused on providing data protection for specialized cloud services usually overlooked by other backup and recovery tool providers. For now, it leaves the backup and recovery of data stored on widely used cloud services, such as Microsoft 365, to other vendors. Rewind claims more than 80,000 organizations are using its platform to protect data, stored in a wide range of cloud services, that address a specific niche use case.

    Given the prominent role GitHub plays in software supply chains, it is not surprising that the code stored in Git repositories becomes a target for cybercriminals. Much of the intellectual property stored in those repositories is a high-value target for organizations looking to reduce the amount of time required to re-engineer a rival company’s functionality.

    Nation-states around the world have cyber-espionage programs aimed at gathering any type of digital asset that might benefit their military or economy. Naturally, copying code isn’t always enough when, in one fell swoop, add code that might derail that project long enough for them to catch up.

    Unfortunately, there have been some high-profile breaches involving software supply chains. The best way to determine if a project has been compromised is to compare code bases. Repositories, by definition, provide application development teams with version control capabilities. However, backing up a GitHub repository provides one extra layer of security that can make it easier to recover from a breach.

  • EraDB Launches Log Management Alternative

    EraDB Launches Log Management Alternative

    EraDB today launched EraSearch to provide IT teams with an alternative to open source ElasticSearch software for managing logs at scale.

    Todd Persen, EraDB’s CEO, said EraSearch is based on a modern database that decouples storage and compute. In this way, EraSearch can scale more efficiently than ElasticSearch, while providing IT teams with the same familiar construct for managing logs.

    Persen said EraDB also uses true zero-schema data representation, and an indexing engine based on machine learning algorithms, to enable EraSearch to scale better. This approach also cuts cloud and operational costs by as much as 30% and 70%, respectively, by relying, in part, on object-based storage systems to store log data.

    As IT environments become more complex and continue to scale, organizations that standardized on ElasticSearch are discovering that a platform based on decades-old search engine technology is not keeping pace with their needs.

    EraSearch provides an alternative, based on a commercial time-series database platform that EraDB created, to address such use cases as an alternative to database platforms such as InfluxDB.

    The question is whether IT organizations, that have relied on ElasticSearch for years, are ready to abandon an open source platform in favor of a proprietary platform, even if it provides a similar user experience. EraDB, however, is betting there are enough IT organizations willing to make that shift to justify its investment in EraSearch.

    Persen said one issue with ElasticSearch is that, as log volumes increase beyond a few terabytes, the platform becomes inefficient and difficult to efficiently scale. That leads to higher costs in terms of both raw storage, as well as all the manual effort on the part of software engineers, required to maintain the platform.

    EraDB, of course, is making a classic case for a proprietary platform over an open source platform: that open source, while free, often proves more expensive to support. Persen said EraDB decided to eschew the open source model altogether, because it is too difficult to prevent nullification of the benefits open source could bring to a small company by open source project forks.

    The ElasticSearch community, meanwhile, is roiled by Elastic’s decision to change the licensing terms under which it makes ElasticSearch available. Elastic is shifting away from an Apache license to a dual-license strategy that includes a Server-Side Public License, or SSPL, along with an Elastic License. That shift was made to help ensure more of the revenue generated by Elastic search winds up in the hands of Elastic, rather than cloud service providers, such as Amazon Web Services (AWS), that routinely launch paid services based on open source code. AWS responded to the Elastic move by announcing plans to fork ElasticSearch code that it will now curate.

    Regardless of how that battle ends, however, EraDB is making it clear it views its platforms as too critical to its customers’ IT operations to get caught up in a similar maelstrom over business models and associated licensing terms.

  • Dynatrace Extends Reach of Observability Platform

    Dynatrace Extends Reach of Observability Platform

    Dynatrace this week updated its observability and software intelligence platform as part of an effort to expand its reach across modern enterprise IT environments.

    Announced at the online Dynatrace Perform 2021 conference, the company’s namesake platform can now capture logs from Kubernetes and Red Hat OpenShift as well as Amazon Web Services, Google Cloud Platform and Microsoft Azure cloud platforms.

    In addition, Dynatrace is adding support for open source log data frameworks such as Fluentd and Logstash. Those logs can now be centrally viewed via a Dynatrace Log Viewer that enables IT teams to search, analyze and segment both real-time and historical log data.

    Dynatrace also added a Cloud Automation Module based on Keptn, an open source tool for automating configuration of observability tools, orchestrating code tests and quality checks. Keptn was created by Dynatrace and is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    The company also launched a Software Intelligence Hub to make it easier to access more than 500 pre-configured integrations, as well as access tools for creating integrations without having to write code.

    Dynatrace also announced it has extended a previously launched Application Security Module to now include support for Node.js applications. In addition, the module includes the ability to enforce security policies against applications instrumented with its agent software, and offers extended capabilities to enable the detection of Kubernetes cluster vulnerabilities, as well.

    Finally, Dynatrace has added a Session Replay capability to its Digital Experience Module to enable IT teams to capture a mobile application experience.

    Steve Tack, senior vice president of product management at Dynatrace, said the company is moving quickly to add support for platforms and technologies widely employed within cloud-native applications to provide IT teams with a single platform through which they can manage monolithic and microservices-based applications.

    With the rise of microservices, IT environments are becoming too complex to manage without some type of observability platform. Historically, cost concerns limited IT teams to employing application performance management (APM) platforms, such as Dynatrace, only for their most mission-critical, monolithic applications. It’s now become apparent that observability platforms capable of correlating log and telemetry data captured from applications and infrastructure are required to effectively manage a modern IT environment.

    As part of that effort, Dynatrace is now collecting data from additional sources alongside the agent software it provides. That data is then fed into an observability platform, that Dynatrace has augmented with a Davis AI engine, to identify anomalies and other potential issues by employing machine learning algorithms.

    It’s not clear to what degree IT teams completely trust the recommendations surfaced by any AI engine. However, as platforms such as Dynatrace collect more data from an IT environment, the more accurate AI models tend to become. In fact,  IT teams that don’t have access to AI capabilities might soon be at a distinct disadvantage, compared to other IT teams that do.

    In the meantime, the battle for observability supremacy continues to intensify, as incumbent providers of APM platforms such as Dynatrace look to forestall a host of startup rivals, all promising greater visibility into IT environments at a lower cost. The challenge now is determining what level of visibility is achieved, and at what total cost.

  • New Relic Adds Visualization Tool to Observability Platform

    New Relic Adds Visualization Tool to Observability Platform

    New Relic announced today it has added a visualization tool, dubbed New Relic Explorer, to make it simpler for IT professionals to discover the root cause of issues that adversely affect application performance.

    Buddy Brewer, global vice president and field CTO for the Americas, New Relic, said the goal is to make it simpler for IT professionals to navigate and, ultimately, act on, all the metrics collected by the New Relic One observability platform.

    New Relic Explorer includes a New Relic Lookout capability that enables IT teams to drill down into telemetry data gathered from New Relic One, as well as other third-party sources, and a New Relic Navigator capability for determining the health of relationships between services, said Brewer. These capabilities make it possible to more easily identify correlations, abnormal history and traces that would be, for example, indicative of blind spots or unknown relationships between IT services, Brewer said.

    Just as importantly, IT professionals can more easily discover recent changes to an IT environment, which are most likely the cause of any new issue that is adversely affecting the IT environment, Brewer added.

    New Relic Explorer requires no configuration, and will be included as part of the existing New Relic Full-Stack Observability offering to give IT teams a single unified view of their IT environments, said Brewer.

    As IT environments become more complex, the amount of time spent looking for the root cause of an issue that might only take a few minutes to fix has substantially increased. As a result, organizations are allocating a significant amount of time to convene “war rooms” to identify the source of problems; those problems can now be more readily identified using New Relic Explorer.

    In general, Brewer said, New Relic remains committed to opening up the platform to external telemetry sources, including data collected using open source tools, such as Prometheus and OpenTelemetry agent software, both advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    New Relic, like providers of similar tools, has recently begun repositioning itself as a provider of an observability platform, rather than of application performance management (APM) tools, that provides insights into both applications and the infrastructure on which they depend. That approach promises to provide IT teams with more context any time an issue arises. As part of that shift, New Relic is making it clear that while it views its agent source as a richer source of telemetry data, its platform can consume relevant data wherever it can be found. New Relic will also remind customers that its agent software, and the other data collection tools it provides, are simpler to install and update.

    The tradeoff, of course, is cost. While open source software itself is free, the total cost of implementing and managing that open source software can be substantial. Regardless of approach, however, the days when IT teams only applied application monitoring tools to their most mission-critical applications because of cost concerns are coming to an end. It has become impossible to manage a modern IT environment made up of both monolithic and microservices-based applications without such capabilities.

  • How the SRE Role Is Evolving

    How the SRE Role Is Evolving

    In recent years, site reliability engineering (SRE) has garnered much interest. In 2019, LinkedIn listed site reliability engineer as the second most promising job in the United States. Now, in 2021, the role continues to grow and evolve within many organizations.

    Initially spearheaded at Google and credited to engineer Ben Treynor, the strategy seeks smarter accountability for application reliability. An SRE team sets service level indicators, makes error budgets for new features and uses tools like application performance monitoring (APM) to visualize performance insights, among other tasks. SREs are quickly becoming a key check to increase business output in response to new digital innovations.

    I recently met with AppDynamics Regional CTO Gregg Ostrowski to discuss the emergence of SRE and how the approach is evolving. In short, it appears SREs will only continue to grow in importance across more companies, adopting new tactics like chaos engineering, and diversifying their teams with new domain knowledge in response to increasing technological complexity.

    What is an SRE?

    Traditionally, organizations employed system administrators, or sysadmins, to maintain operations for large computing systems and services. However, this typically produced a dichotomy: product developers want to push new features, while operations teams (sysadmins) want to make sure the existing service doesn’t break. The split between developers and operations can be unhealthy and cause friction.

    Whereas sysadmin positions are detached from development and involve a lot of manual work, an SRE approach, on the other hand, takes a more engineering-focused approach to automate operations. Google’s SRE book, which has become a bible of sorts, defines the role as “What happens when you ask a software engineer to design an operations team.”

    So, what does an SRE do? Well, at Google, they are in charge of availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning for the services they operate. At Google, they spend no more than 50% of their time on traditional “ops,” like tickets, on-call and manual tasks, and are encouraged to use the remaining 50% of their time to develop automation that will replace human operations labor.

    5 Ways the SRE Approach is Evolving

    It’s been a few years since Google introduced the SRE concept, and naturally, unique iterations have popped up within other enterprises. But, on the whole, where is the concept heading? Ostrowski sees SREs evolving in a few key areas: growth and maturity, increased diversification with domain-specific experts and new monitoring tactics.

    1. Increased Adoption

    First, not all companies have embraced an SRE model. A recent study by Blameless found “… 50% of respondents employ an SRE model with dedicated engineers focused on infrastructure and tooling, or an embedded model where full-time SREs are assigned to a service.”

    The SRE model is gaining momentum, but there is still room for greater adoption. There is also room for internal growth. Ostrowski sees a single SRE team as a single point of failure. “It needs to be a whole department,” he said.

    In addition, SREs are gaining a more prominent voice at the table, influencing feature rollout. “With proper and mature SRE involvement, teams can’t willy-nilly deploy,” he said. Ostrowski views these teams as maintaining a critical balance between business risk and introducing new technology.

    2. Larger, Diversified SRE Departments

    Many companies are experiencing rising user demands, and thus must rapidly scale their application networks. Simultaneously, there has been a Cambrian explosion of deployment types — systems could be using any assortment of legacy infrastructure, mainframe, microservices, cloud environments and multiple cloud vendors. “The complexity and topology of the IT space has grown substantially, with many interdependencies,” Ostrowski said.

    Due to increasingly complex technical stacks, SRE must now cover many domains. Thus, SRE departments will likely require a more diversified team of domain experts. Ostrowski likens SREs to “Navy SEALs of the IT team.” For example, assigning them with experience navigating the nuances behind Google Cloud Platform (GCP) or Microsoft Azure could maintain service reliability in respective clouds.

    Individuals’ personality matters for suitability to SRE, too, said Ostrowski. The role requires a specific type of innovator who considers the repercussions of code, and loves improving processes and performances.

    3. New Testing Tactics Will Emerge

    Ostrowski also foresees SRE departments introducing new monitoring and testing approaches to maintain reliability. One of these is chaos engineering, which champions the idea of intentionally breaking application systems. Different strategies will undoubtedly emerge to help drive user experience (UX) and ensure that performance is always top of mind.

    4. Businesses Rely on SREs to Mitigate Risk

    All things will inevitably fail, at some point. SREs accept failure and learn to manage it, designing repeatable operational mitigation structures. “As companies become reliant on the consumerization of IT, business is dependent on SREs to drive business,” said Ostrowski. This reliance will likely increase as businesses tap SREs to maintain stability.

    Whether it’s reducing mean time to repair (MTTR), programming service level indicators to monitor website load time, or forecasting error budgets for new feature introductions, SREs will be increasingly relied upon to maintain business stability and high performance.

    “The SRE mindset is about coming to terms with a blameless environment,” said Ostrowski. They can help “balance a risk between the business and application team,” described Ostrowski.

    5. SREs Steer UX

    In this digital-only environment, “The application has become the business,” described Ostrowski. If the application is core to the business, monitoring the user journey is necessary to improve it. Ostrowski believes SREs oversee a unique territory that could produce valuable business insights too.

    In addition to monitoring uptime to ensure URL response times meet SLAs, SREs could track UX-related insights, such as conversion rates or cart abandonment percentages. Tracking such analytics and setting standards baselines could help pinpoint problems affecting UX. It could also assist product development in designing better-performing software.

    Final Thoughts

    “Anything that you do more than twice has to be automated.”
    -Adam Stone, CEO, D-Tools

    Traditional operations teams are typically detached from product development and are culturally very different. However, within an SRE approach, operations instead aim to run systems that automate work typically performed manually by sysadmins.

    In this brief introduction, we barely scratched the surface of the topic. And of course, each company is unique in its approach to hybridizing product development and operations. DevOps tenants are closely aligned with SRE — often they are intermixed or one and the same.

    Ultimately, truly reaping business value from this approach will depend on breaking down silos and opening conversations — or at least automated notifications — between disparate units. Only then can operations and development coexist in the most productive way.

  • Survey Shows DevSecOps Progress in Larger Organizations

    Survey Shows DevSecOps Progress in Larger Organizations

    A survey of 250 U.S. and UK large enterprises with more $1 billion in revenue conducted by Security Compass, a provider of a platform for automating security tasks as application are developed, finds three-quarters (75%) have implemented DevSecOps processes on current application development projects.

    Rohit Sethi, CEO, Security Compass, said the State of DevSecOps Report published today makes it clear more organizations are starting to embrace security by design as they develop their applications. Nearly three-quarters of respondents (73%) said their organizations follow a “by design” approach that enables them to proactively address cybersecurity and regulatory compliance.

    The primary reasons respondents cited for embracing DevSecOps best practices were to improve security, quality and/or resilience (54%), followed by the ability to bring applications to market faster (30%). One of the misconceptions about DevSecOps is that it slows down application development and deployment. However, Sethi said, in practice, DevSecOps enables organizations to address security and compliance issues that would otherwise result in an application not being promoted into a production environment. Almost three-quarters of respondents (73%) noted that manual security and compliance processes slow down code releases. A full 96% said their organization would benefit from the automation of security and compliance processes.

    The biggest DevSecOps obstacles cited by survey respondents included technical challenges (60%), followed by cost (40%), insufficient time (39%), lack of education (38%), lack of skills (36%) and organizational inertia (35%).

    In terms of deploying applications, the biggest reasons cited by the 51 C-suite executives that participated in the survey were insufficient automation and lack of tooling, at 51% each. Organizational barriers came in a close third (50%).

    In the longer term, Sethi said it’s clear most organizations are shifting toward zero-trust architectures to make their application environments more secure. However, achieving that goal across a broad application portfolio will require more investment in both automation and, eventually, various forms of artificial intelligence (AI), said Sethi.

    It’s not clear to what degree smaller organizations will have the tools and resources required to fund adoption of the automation platforms needed to advance DevSecOps more broadly. There’s more awareness of DevSecOps than ever. The challenge is the tools and processes required to achieve it are not uniformly being pushed into the hands of the individual developer. In some cases, organizational leaders are encouraging developers to embrace DevSecOps without any practical guidance.

    Eventually, of course, every organization will embrace DevSecOps best practices, but the real question is, at what rate? The number of applications organizations are rolling out continues to accelerate, but reliance on DevSecOps best practices to ensure security and compliance remains uneven, at best. Larger organizations that have the resources required to fund these initiatives tend to be further along in their adoption journey. However, there is no correlation between organizational size and the ability to build and deploy secure applications. After all, a smaller organization may make up for what they lack in resources with a greater commitment to DevSecOps best practices.

  • BluBracket Community Edition of Secrets Discovery Tool now Available

    BluBracket Community Edition of Secrets Discovery Tool now Available

    BluBracket today announced general availability of a community edition of a tool that employs machine learning algorithms to discover passwords, tokens and other security vulnerabilities in code.

    Prakash Linga, BluBracket’s CEO, said application secrets stored in code enable cybercriminals to compromise applications in ways that can impact an entire software supply chain. The community edition of the company’s namesake tool scans commits to determine if any new risks were introduced, and will then block the staged files from being committed. It works with any continuous integration/continuous delivery (CI/CD) platform or integrated development environment (IDE) that supports pre-commit hooks, including VSCode, Jetbrains IntelliJ and PyCharm.

    Developers are then presented with a risk score based on the number of secrets discovered in their code. For example, an active token for Amazon Web Services (AWS) would receive a high score, while a a password in a test environment would be rated low.

    The Community Edition of BluBracket can be accessed via GitHub. The free version of BluBracket can be employed to scan up to 10 repositories and sharing reports in real-time, covering more than 50 types of secrets that might be employed using any programming language.

    Linga said BluBracket also cuts down on false positives by combining machine learning algorithms with a built-in rules engine. In contrast to open source tools, BlueBracket generates far fewer false positives, said Linga.

    Linga said the Community Edition is intended to help foster adoption of DevSecOps best practices among individual developers, in hopes that when those developers are hired, their organizations eventually license the full instance of BluBracket. The company views its tools as being complementary to both tools that surface vulnerabilities in code as well as secrets management platforms, which are often not employed as widely within an organization, Linga said.

    In the wake of recent high-profile breaches that embedded malware in widely-distributed applications, there’s increased focus on securing software supply chains. In some of those instances, Linga said, it’s probable cybercriminals discovered passwords and other secrets that were inadvertently exposed in code.

    However those breaches were enabled, it is apparent cybercriminals are becoming more adept at exploiting a weakness in one application to inflict maximum damage across an entire environment. It’s hard to say exactly what role secrets discovery is playing, but cybercriminals tend to prefer the path of least resistance when it comes to exploiting application vulnerabilities.

    Of course, the hope is that adoption of DevSecOps best processes will reduce the number of breaches by shifting responsibility for cybersecurity further left toward developers. However, that’s difficult to achieve without finding the simplest way possible of getting the security tools required into the hands of the developers that need them most.

  • Sauce Labs Acquires AutonomIQ to Advance App Testing

    Sauce Labs Acquires AutonomIQ to Advance App Testing

    Sauce Labs is acquiring AutonomIQ, a provider of a scriptless test automation platform based on machine learning (ML) algorithms.

    Matt Wyman, chief product officer for Sauce Labs, said the acquisition of AutonomIQ will play a critical role in enabling Sauce Labs to push testing further left toward developers and, ultimately, “citizen testers” that are becoming part of the DevOps testing tool chain.

    The acquisition of AutonomIQ comes on the heels of the company announcing its intent to acquire API Fortress, an application programming interface (API) testing platform provider. Terms of neither acquisition were disclosed.

    Wyman said the rise of DevOps coupled with an increase in the volume of applications being developed using low-code tools are the primary drivers of a need to shift testing further left. As more citizen developers are building applications, they require access to a testing platform that doesn’t require them to know how to write scripts to test applications, said Wyman.

    The AutonomIQ platform employs machine learning to understand, for example, natural language descriptions of test cases or captured mouse clicks. It then generates synthetic data and test cases that can self-heal when an application changes, said Wyman.

    That approach to testing is more feasible in software-as-a-service (SaaS) environments, where a custom application based on a platform such as Salesforce, ServiceNow, Workday, Oracle or SAP doesn’t tend to change as radically as an application being built from the ground up, Wyman said. Those classes of applications will still require either developers or a dedicated team of testers to build tests using scripts, said Wyman.

    In fact, Wyman said testing those applications is becoming more challenging in the age of microservices. The API Fortress acquisition addresses that issue, because microservices are dependent on APIs to communicate with other microservices, said Wyman. In general, Wyman said Sauce Labs is now moving beyond being focusing only on functional testing of user interfaces.

    It remains to be seen how quickly testing will move to the left. Developers are being held more accountable for the quality of their applications, so testing integration within the application development process has increased. This has led to application testing becoming more tightly integrated with continuous integration/continuous delivery (CI/CD) platforms. Less clear is to what degree those efforts might have reduced the burdens of a dedicated application testing team that typically evaluates applications after they have been constructed.

    Exactly where and how citizen testers are being incorporated into those processes is also unclear. In theory, citizen testers can bring more business process expertise to the testing process. Getting individuals with that level of expertise to make time to participate in application testing while an application is being built can be a challenge.

    Regardless of approach, however, it is already apparent that machine learning algorithms, along with other forms of artificial intelligence (AI), will play a much larger role in application testing in the coming months and years.

  • Amid COVID-19, Developers Struggle to Keep Pace

    Amid COVID-19, Developers Struggle to Keep Pace

    It’s been a wild ride for digital innovation. It’s also been a stressful year for developers. At most organizations, the pandemic has increased reliance on digital experiences (and its programmers) exponentially. IT spending is rising, and competition is skyrocketing. More than ever before, the pressure is placed on developers to meet rigorous demands.

    A recent study by Couchbase revealed how developers are revolutionizing digital transformation efforts throughout the COVID–19 crisis. Yet, this output may not be sustainable. The 2020 Tech Lead Survey, which surveyed 450 senior IT decision-makers worldwide, exposed stressors for development teams, which, if not mitigated, could easily result in fatigue and burnout.

    So Much To Do, So Little Time

    Some digital transformation efforts that were slated to take five years have had timelines reduced to a matter of months. In this unprecedented era, flexibility is an indispensable characteristic to adapt to change. In fact, 63% of respondents said that flexibility to change direction on a whim is critical to meeting digital transformation goals.

    But, extreme flexibility comes at a price. Forty-nine percent of respondents indicated their development teams have been asked to do too much in too little time. As a result, 40% of respondents said their development teams were behind schedule with their current projects.

    “In a year when organizations have had to struggle to adapt to new decentralized ways of working and rapidly evolving markets, developers have come under severe pressure to help their organizations adapt,” said Steve Yen, co-founder of Couchbase.

    It’s apparent that developers are under escalating pressure. If the weight continues to pile on, exhaustion could bring overall production to a grinding halt. At least leaders realize who is driving digital innovation — 92% acknowledge developers are the unsung heroes of current digital transformation initiatives.

    Lacking Clear Direction From On High

    Eighty-six percent of respondents experienced challenges with their development teams. However, this does not wholly reflect poorly on developer inabilities — managers have a responsibility to set more explicit guidelines.

    Another obstacle: goal setting. Forty percent of respondents reported that setting clear, measurable goals for their team is a serious challenge. In addition, ensuring developers use the right technology, and ensuring teams understand overarching strategic goals were oft-cited pain points, as well.

    Resolving these issues will be critical to reducing developer complaints and remediating the stressors outlined above. “There needs to be investment in not just people, but also in the technology, management and communication that will help individuals succeed,” said Yen.

    Solution: DevOps

    So, where should architects direct new investments? Well, of the 450 IT leaders surveyed, 92% believe DevOps could have a revolutionary impact on their digital transformation efforts.

    The report refrains from offering specific technical advice, but makes the following general recommendations:

    • Don’t rely on legacy technology ill-suited for the tasks at hand. Current investments must be future-proofed for tomorrow’s scalability and integration requirements.
    • Don’t assume onboarding new tech will be easy. As digital innovation matures, new technology becomes more refined and specialized. As I’ve covered, whether it’s Kubernetes, service mesh or multi-cloud strategies, all require time to learn, along with some pretty specialized skillsets.
    • Take time to communicate with developers and understand obstacles. Be realistic with timelines, and do not ask for too much. Plan out project goals strategically, because haste does not equate to overall speed.

    Under pressure to perform and maintain flexibility, it makes sense that engineers are feeling the pressure of an amplified development pace. As that pace is likely not to decrease in 2021, finding methods to better support developers is key for long-term sustainability.

    At many organizations, a greater DevOps investment equates to operationalizing and automating processes for areas like microservices CI/CD, and networking and zero-trust security. It could also mean supporting developer workflows with some-code tooling. Other institutions are even introducing low-code tools to democratize the development process, intending to relieve some burden from professional engineers.

    Invest in Developers, Invest in Smooth Operations

    On average, development teams grew by 20% in 2020. As expectations for developers rise, so will investment in developers and the processes that support them. As teams move forward, it will be critical to gather feedback and understand what’s causing gridlock so that developers maintain agility and avoid burnout.

    In this competitive climate, choosing the correct people and systems to support new digital advances will be a competitive advantage. “Investing in [developers] in the right way will help them play to win,” said Yen.

    Since 2017, Couchbase has surveyed IT decision-makers on the challenges they face throughout their digital transformation efforts. Here, I highlighted the major takeaways from the 2020 report. You can view the full findings here.