devopsy.kinsta.cloud

Category: Features

  • LogDNA Adds Usage Quota Tools to Help Control Costs

    LogDNA Adds Usage Quota Tools to Help Control Costs

    LogDNA announced today it will enable IT teams to apply usage quotas to help rein in log management costs.

    Tucker Callaway, CEO, LogDNA, said as applications become more complex – thanks, in part, to the rise of microservices – the amount of log data that a DevOps team can collect has significantly increased. IT teams can now assign DevOps teams both hard and soft quotas to limit the amount of log data collected during a specific time period, Callaway said.

    IT teams can set a daily or monthly hard limit on the volume of logs stored or, alternatively, they can also set soft daily or monthly quotas that can apply throttling logic to ensure mission-critical log data will continue flowing through LogDNA as usage volume approaches the limit threshold. It will then be up to each IT team to determine, based on the tasks at hand, whether to enable a DevOps team to exceed those thresholds, Callaway said.

    IT teams can also make use of soft limits to reallocate storage resources from one DevOps teams to another based on how much log data might be generated in a specific time period, Callaway noted.

    LogDNA will notify team members any time a quota is hit, or when an exclusion rule is triggered because a quota has been reached. Those alerts can also be integrated with email systems or the Slack messaging platform. Logs that are not retained are not counted toward the monthly bill, but are displayed and will trigger other relevant alerts.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, IT organizations are, generally, more sensitive to costs. At the same time, many of them are encouraging developers to assume more responsibility for application life cycle management as they embrace DevOps best practices. The usage quotas are intended to enable IT teams to strike a better balance between what can be two competing agendas, Callaway said. IT leaders are not necessarily trying to discourage DevOps teams from collecting log data as much as they are trying to make sure costs are predictable, Callaway added.

    Log data, of course, is one of the core elements of any observability strategy. While observability has always been a core DevOps principle, the number of organizations that have been able to meaningfully achieve it has been limited. However, as organizations start to deploy microservices with multiple dependencies, the need to provide context when troubleshooting those applications has become more acute.

    It’s not clear to what degree more granular control over log data might sway an IT organization toward one platform versus another. However, when it comes time to justify a choice to senior IT and business leaders, it’s always a good idea to address, at some point, how one decision versus another might have a more positive impact on the bottom line.

  • GrammaTech Allies with GitLab to Advance DevSecOps

    GrammaTech Allies with GitLab to Advance DevSecOps

    GrammaTech announced today it has partnered with GitLab to integrate its GrammaTech CodeSonar static application security testing (SAST) tools with the GitLab Ultimate DevSecOps platform.

    Vince Arneja, chief product officer at GrammaTech, said integration with continuous integration/continuous delivery (CI/CD) platforms such as GitLab is critical because it enables security scans to run automatically any time code is merged. That capability reduces the amount of code that is scanned at any one time, Arneja said.

    GrammaTech is partnering with multiple CI/CD platforms and integrated development environment (IDE) providers to make it simpler to create multiple points for scanning code during the application development process, Arneja noted.

    GitLab, meanwhile, is providing its own tools for analyzing artifacts as they move through the software development life cycle. The GrammaTech tools, available via the highest tier level made available by GitLab, analyze code at a deeper level, said Arneja.

    Ultimately, the goal is to enable developers to discover security flaws as early as possible in the application development life cycle. The later those flaws are discovered, the more expensive they become to fix, Arneja said.

    Developers, naturally, tend to postpone security scans as they race to meet an application deadline. That practice creates issues; the more code there is to analyze, the longer such scans take. It’s generally more efficient to scan smaller amounts of code more frequently. Otherwise, developers can become overwhelmed by the number of security bug fixes that need to be addressed at the back end of the application development process. Automating security scans allows an organization to move toward embracing DevSecOps best practices in a way that doesn’t rely on a developer remembering to initiate a scan.

    Most developers are not deliberately ignoring security issues – it’s just that the existing, manual processes for discovering those flaws is inefficient.

    Automated scans also provide the added benefit of simplifying discovery of common security flaws long before a code review, creating more time to address significantly more complex issues.

    Application development teams are also under pressure to reduce the total number of bugs that need to be fixed after an application is deployed. As the number of applications being deployed steadily increases, developers can find themselves spending more time fixing bugs than writing new application code.

    Most organizations are not very far along in their journey toward embracing DevSecOps. However, as it becomes easier to integrate a variety of scanning tools within DevOps workflows, the number of organizations moving up the DevSecOps maturity curve should increase. In the wake of some recent, high-profile attacks on software supply chains, the sense of urgency surrounding the adoption of DevSecOps best processes has undoubtedly increased.

    In the longer term, there may soon come a day when security is viewed as just one of many quality assurance gates that code needs to pass through before it’s allowed to be promoted. In the meantime, an ounce of cybersecurity prevention at the front end of any application development is most certainly going to be worth more than several pounds of cybersecurity cure applied too late.

  • DevOps Myths Debunked

    DevOps Myths Debunked

    Leaders need not be DevOps experts, but they need to distinguish DevOps myths and realities to lead their digital transformation projects.

    As I indicated in a recent article, Engineering Practices Can Overcome DevOps Challenges, leaders need to set an inspiring DevOps directional vision for the organization, and proactively stimulate and sponsor team activities toward goals. To be credible, communication from leaders need to distinguish between myth and reality. It is easy for leaders to get confused, because there are many popular myths surrounding DevOps. It’s important to remember that, in DevOps, definitions and engineering best practices for DevOps have not entirely been nailed down.

    As Doug Miller, senior director strategic partnerships, Perforce Software, said “Working in an industry that has yet to settle on an accepted ‘definition’ for DevOps makes each day a challenge. The ever-morphing landscape makes it difficult for technology vendors and consumers alike to ensure we’re all talking about the same thing in the same way.”

    Here are some of the most important myths that leaders need to be aware of.

    Debunking DevOps Myths

    Myth: “DevOps is a cultural movement.”

    The truth is that implementing DevOps requires a careful and balanced engineering approach that considers a wide array of people, process and technology aspects. In my article, The Time Has Come for an Engineering Approach to DevOps, I explained that while culture is a critical success factor, DevOps is much more than just culture. Furthermore, DevOps is not just a movement. In the larger context of software engineering history, the word “DevOps” is new, and perhaps it will be replaced by another word someday, but the underlying engineering principles and practices that constitute DevOps could apply to almost any engineering project throughout the ages.

    Myth: “DevOps requires continuous deployments.”

    The truth is that DevOps enables continuous delivery of release artifacts to a staging environment to be ready to deploy safely, but frequent deployments to production is not always a goal. There are valid customer use cases that do not desire frequent deployments to production. For example, customers may not want to receive a new version of a software platform product frequently, because each new version may be disruptive and risky for reasons beyond the scope of the product itself. The engineering benefits of delivering complete releases to staging without deployment to production are still considerable. Each release is produced and validated in a pre-production environment, and made ready for deployment on demand without disrupting customers that do not want to take a new release.

    Myth: “DevOps applies to any software product, service or application.”

    The truth is that DevOps engineering yields high ROI in many circumstances, but some cases do not warrant investment in the people, process, and technology changes needed for DevOps. For example, applications that rarely change do not warrant the cost of DevOps changes. Organizations that are heavily siloed will find it too frustrating and counterproductive to implement DevOps. The application of DevOps to some commercial off-the-shelf (COTS) products may not yield sufficient ROI, because business-to-business barriers may behave as impenetrable organizational silos. Applications that have few tools in their toolchains suitable for DevOps may find the transition to DevOps too expensive.

    Myth: “DevOps requires Agile.”

    The truth is that DevOps and Agile can be either complementary or competitive. The notions of working with small, incremental changes is common to both Agile and DevOps. However, organizations that embrace Agile are focused on optimization of the development end of the pipeline, and may struggle with DevOps, which emphasizes engineering of end-to-end process optimizations.

    Myth: “The scope of DevOps is the same as CI/CD.”

    The truth is that a well-engineered DevOps implementation encompasses continuous integration/continuous delivery (CI/CD), but also extend beyond integration and delivery into other practice areas such as planning, operations, governance, disaster recovery and other practices that must work together with CI/CD to accomplish business goals.

    Myth: “DevOps does not apply to platform products such as software code embedded in manufactured products.”

    The truth is that DevOps does apply to embedded code products, as well as web services, business applications and other types of products. It even applies to development of software and services for DevOps itself! In the case of platform products, typically, deployments are planned. They are not continuous, but, instead, continuous deliveries of candidate releases are delivered to a staging environment to make sure the changes implemented for the platform are fully developed and verified as the platform is built, instead of waiting for a big-bang release.

    Myth: “DevOps is an elimination of IT operations.”

    Jeremy Bosch, in his article, Top 9 Debunked DevOps Myths, “As per the NoOps concept, the IT sector will become so automated that it will not require any in-house team to manage the software. However, no matter how automated the services may become, there will always be a need for operations. Although there may be changes in operations, they will still hold significance in DevOps.”

    There are many persistent myths about DevOps, such as the examples in this article, that can confuse and misdirect uninformed leaders. Leaders that learn to distinguish between DevOps myths and realities are better able to communicate realistic goals to lead their digital transformation projects.

  • Scarf Gateway Tracks Open Source Software Usage

    Scarf Gateway Tracks Open Source Software Usage

    Scarf today exited stealth to launch a gateway that makes it simpler for individuals or organizations to track usage of open source software.

    Avi Press, founder of Scarf, said the Scarf Gateway is an online service through which providers of open source software can redirect downloads from a wide range of repositories and registries. That extra step then provides those entities with data and insights about the type of individuals and organizations using their software.

    Fresh off raising initial seed funding, Press said the Scarf Gateway will make it easier for developers of open source software to employ multiple repositories to distribute their code, because they won’t become overly dependent on metrics shared by the provider of a single repository.

    Most of those registries today only provide download counts for packages. Scarf Gateway will provide insights into, among other attributes, downloads by version, platform, location, company and cloud environment(s).

    The majority of organizations making open source software available don’t have a lot of visibility into how their offerings are being employed until organizations using the software sign up for commercial support. Armed with more insights into how their software is being used, many of those providers would be able to more proactively collect feedback, in addition to promoting their commercial services.

    Many open source project maintainers have a difficult time prioritizing what capabilities to add or fix, simply because they don’t know enough about how their software is being employed, Press said.

    The ability to more granularly track usage comes at a time when tensions over open source monetization and compensation are rising. In many cases, providers of open source software are changing the way they license their software to prevent cloud service providers from reaping most of the benefits of their work. Startups, typically funded by venture capitalists, make their software available as open source code in an effort to build a customer base on the strength of their support services. Cloud service providers have discovered they can take the code these vendors create to launch their own service. Those cloud service providers may contribute code to the project, but the startup vendor doesn’t typically enjoy any of the economic benefits.

    Many individual contributors don’t work for a company that sponsors their contributions, and also want to be paid for their efforts. A survey of 4,440 developers who actively participated in open source projects in 2020 finds more than half (54%) of respondents said they feel individuals should be paid for their contributions to open source projects. The survey, conducted by Digital Ocean, a cloud service provider, found only 14% of respondents are currently paid for their contributions.

    It’s too early to say what impact the ability to track usage of open source software may have. Many individuals using open source software may prefer their current level of anonymity. Others might participate more in a project if engaged. Like it or not, however, large swaths of the open source community want to know the degree to which their efforts are making an actual difference.

  • Lightrun Tool Now Debugs On-Premises Apps

    Lightrun Tool Now Debugs On-Premises Apps

    Lightrun today announced it has made its namesake debugging tools available for applications deployed in on-premises IT environments that, for one reason or another, can’t be deployed on a cloud platform.

    lan Peleg, CEO of Lightrun, said Lightrun is unique in that software teams can capture live production data from software installed on their customers’ sites via a set of command line interfaces (CLIs). That approach eliminates the need for the end customer to set up a separate environment to troubleshot an application, said Peleg.

    Instead, software teams can troubleshoot their software without requiring on-site visits by support engineers or even a phone call, Peleg said.

    Lightrun makes it possible to add logs, virtual “breakpoints” and metrics while an application is running. Those capabilities are critical because many applications are not fully instrumented. Lightrun makes it simpler to triage issues by adding a missing log line, instrumenting a new metric or taking a snapshot of an application as it runs in a production environment. Those capabilities make it possible to find bottlenecks and errors without requiring the application to stop running.

    The performance impacts of Lightrun range from tens to hundreds of microseconds per invocation to minimize overhead, Peleg said.

    In general, Peleg said, debugging applications is becoming more challenging. Monolithic applications continue to grow in size while emerging microservices-based applications have dependencies that make them challenging to debug. Many organizations are employing application performance management (APM) platforms and other observability tools to try and address these issues. However, those platforms require IT teams to continuously collect data, and even then there is no guarantee the insights needed to troubleshoot an application will be surfaced. Lightrun, conversely, makes it possible for developers to troubleshoot an application and capture the metrics needed in real-time. That data can then be shared with an APM platform to make it easier to address similar issues if required, Peleg said.

    As developers become more accountable for application performance, many of them are not going to want to employ the same tools and processes that IT operations teams have historically relied on. Lightrun provides a lighter-weight approach to troubleshooting applications, within the context of a DevOps workflow, that doesn’t require as much overhead, said Peleg.

    Although observability is a core DevOps principle, many organizations have been unable to achieve it in a meaningful way. There is no shortage of tools for monitoring IT environments, but correlating all the data those tools generate is problematic. It’s not uncommon for organizations to spend weeks trying to identify the source of an issue that only takes a few minutes to fix. Now that developers are assuming more responsibility for managing the entire lifecycle of an application it is likely different approaches to achieving observability will be considered.

    In the meantime, as the number of applications deployed in production environments continues to increase, different approaches to debugging software will be required. Otherwise, at the current rate of deployment, it won’t be long before developers find themselves spending most of their time debugging existing applications, versus actually writing new code.

  • Value Stream Management Consortium Makes Debut

    Value Stream Management Consortium Makes Debut

    A consortium dedicated to advancing the adoption of value stream management best practices is being launched today with backing from Digital.ai, HCL Software, Plutora, ServiceNow and Tasktop.

    The Value Stream Management Consortium (VSMC) will create an open community around which organizations that are seeking to expand DevOps workflows and processes across functions and organizations can more easily collaborate.

    VSMC chair Helen Beal said that while value stream management has been around as a concept for years, the number of organizations that have fully embraced the concept remains relatively small. The VSMC is dedicated to enabling organizations to orchestrate software development processes more flexibly, she said.

    VSMC Chair Helen Beal

    That goal has proven elusive, because it requires a level of collaboration between release managers, DevOps managers and product managers as well as IT and business leaders. Value stream management provides a framework for enabling organizations to embrace value stream management concepts as they become more adept at employing DevOps workflows to manage multiple application development initiatives simultaneously.

    Initially, Beal said, the VSMC will function as a central hub of information and education pertaining to value stream management. Ongoing research will track how organizations measure value. Eventually, the VSMC will provide certified training, Beal added.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is automated as much as possible using DevOps best practices, an appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business is growing steadily as organizations realize how dependent on software they have become.

    As organizations come to terms with this new reality, many also realize there is a much greater need to align software development with their core business processes. Value stream management platforms automatically take technical metrics, gathered via a DevOps process, and match them to a set of key performance indicators (KPIs) defined by business leaders. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics and then define the KPIs that truly matter to the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to the massive amounts of DevOps data they collect.

    Business leaders are especially anxious to understand how any software development project delay might impact future revenue projections. Rather than being a set of tools employed mainly by IT leaders to track software development projects, value stream management platforms make it possible for other stakeholders to track KPIs spanning multiple software development projects. It then becomes easier to make informed decisions about how to reassign resources across various projects as different bottlenecks are encountered.

    It may be a while before organizations achieve that level of DevOps sophistication, but as software continues to eat the world it’s only a matter of time before value stream management becomes the table stakes organizations will need to survive and, hopefully, thrive.

  • Cybersecurity 2021: Are You Really Prepared for a Cyberattack?

    Cybersecurity 2021: Are You Really Prepared for a Cyberattack?

    As the majority of businesses are increasingly moving to the online world, employees keep working remotely and more cyberattacks keep happening all over the globe, there is no doubt that embracing DevSecOps should be the new normal for every company. Organizations need to be able to adopt DevSecOps practices and adapt to new and evolving threats in order to protect their data and systems from malicious attacks.

    At Cybersecurity 2021: The New Normal Virtual Summit, taking place March 4 and 5, the brightest minds in the security and IT industry will come together to discuss new security threats, empower DevOps teams with the latest security tools and provide practical tips and guidance to help developers and ops teams make the right security decisions to keep their data secure.

    The two-day virtual event features thought-provoking discussions, networking opportunities and educational sessions focused on:

    • DevSecOps tools and practices
    • The main challenges of security and development teams when it comes to AppSec
    • Identity and Access Management (IAM)
    • Passwordless and the long-term future of identity management
    • Policy-as-Code and how it impacts security
    • How security threats changed with COVID-19 and what to expect in 2021
    • How to manage AppSec
    • How to mitigate API vulnerabilities
    • How to break the silos and advance towards DevSecOps maturity
    • How to expand your security program through low-to-no cost initiatives
    • Time series database for security monitoring
    • Machine identity management
    • Top 10 Hacks From the Past Decade
    • Runtime observability techniques for security and compliance
    • Securing AWS credentials on DevOps machines

    Cybersecurity 2021 features an outstanding lineup of industry leaders, including:

    • Ira Winkler, author and president at Secure Mentem
    • Chenxi Wang, founder and general partner at Rain Capital
    • Ron Gula, president at Gula Tech Adventures
    • Richard Stiennon, founding member of The Analyst Syndicate and chief research analyst at IT-Harvest
    • Joe Levy, CTO at Sophos
    • Rajat Bhargava, founder and CEO at JumpCloud
    • Myla Pilao, head of security research communications for TrendLabs at Trend Micro
    • Upasna Gupta, senior product marketing manager for Prisma Cloud at Palo Alto Networks
    • Julian Waits, general manager of cyber business unit and public sector at Devo
    • Joseph Feiman, chief strategy officer at WhiteHat Security
    • Ian Murphy, founder and CEO at CyberOff
    • Mike Jones, security researcher at H4unt3d Hacker Podcast
    • Rhys Arkins, director of product management at WhiteSource
    • TJ Jermoluk, co-founder and CEO at Beyond Identity
    • Jim Ducharme, general manager of the anti-fraud business unit at RSA

    Attendees will have the chance to enter a raffle for a chance to win a free copy of “You can Stop Stupid” by Ira Winkler and another one for a free copy of “Security Yearbook 2020” by Richard Stiennon. There will be valuable resources available for download and attendees will be able to interact with sponsors to learn more about their security tools and services.

    To see the full agenda and to register, please visit the Cybersecurity 2021 website.

  • Helping Bring Balance, Diversity to the IT Workforce

    Helping Bring Balance, Diversity to the IT Workforce

    It’s a fact: Minorities and women traditionally have been underrepresented in the IT space. According to the Brookings Institute, less than 7% of computing and math-related jobs are held by people who are Black and Latino. And while women are faring better, they still only represent about 30% of the workforce in computer and mathematical occupations, according to the institute. Clearly, there is more work to be done in creating a balanced, diverse IT workforce.

    At MediaOps, one of the traits I believe helps define this company is inclusiveness, recognizing the value each person in our organization brings to the table. Different educations, different backgrounds, different perspectives … they all help us see the world in a different light and make decisions that are rooted less in biases and more with a deeper understanding fomented by the populations each of us represents. This, I believe, is fundamental in achieving balance; by recognizing and celebrating our differences, we create a strong, unified organization.

    Be the Change

    It is with the goals of diversity and inclusiveness that MediaOps is proud to announce “Engineer the Change,” a scholarship program in conjunction with Boca Code, an immersive coding school that provides in-depth technical training. MediaOps will sponsor two scholarships annually to students from disadvantaged communities interested in pursuing a career in the tech industry. The scholarships, each valued at $10,000, will enable students to enroll in the flagship Software Engineering Career Course at Boca Code.

    The “Engineer the Change” scholarships will be awarded to two deserving recipients on an annual basis. To be eligible, applicants must be 18 years or older and be part of an underrepresented community. To be considered, applicants will be required to submit an essay detailing how they can serve as role models to other disadvantaged individuals hoping to acquire the skills to become successful tech workers, and what type of career in the tech industry they are hoping to pursue. While the idea is to help the South Florida tech community, applicants can apply from anywhere, as long as they include in their application essay why they are coming to South Florida to launch their tech career.

    Submissions for the first scholarship for the Software Engineering session, taking place April 5-June 4, are now open. The deadline to apply is March 15. The second scholarship application process will open Aug. 1 for the session taking place Sept. 20-Dec. 3.

    To learn more about how to apply for the scholarship, please visit: https://mediaops.com/engineer-the-change/

    Get Involved

    MediaOps is offering these scholarships because we believe diversity enriches everything. We encourage other companies to do their part to help promote diversity and inclusiveness, both within their organization and through programs targeting underrepresented communities locally or regionally. It is time for the IT sector to do its part in promoting technology to women, minorities and other traditionally underrepresented groups; only by getting involved today will we help shape the next generation of technology workers.

  • Datadog to Meld Observability and DevSecOps

    Datadog to Meld Observability and DevSecOps

    Datadog is planning to expand the scope of the security and observability services it provides following the acquisitions of Sqreen, an application security platform provider, and Timber Technologies, a provider of a tool, called Vector, for collecting and normalizing log data.

    Ilan Rabinovitch, vice president of product and community for Datadog, said Vector makes it possible to collect, enrich and transform logs and other observability data from both on-premises and in-cloud environments in a way that makes it easier to route that data to wherever it is needed via a data pipeline.

    Sqreen is a provider of a software-as-a-service (SaaS) platform that detects, blocks and responds to application-level attacks using runtime application self-protection (RASP) capabilities enabled by a web application firewall (WAF) embedded within an application.

    Rabinovitch said as IT continues to evolve, it’s clear organizations are looking to embrace DevSecOps best practices in a way that will require security tools that can be embedded within an application, coupled with observability tools that provide more context about the overall IT environment. That context is especially critical, given the amount of data that needs to be analyzed to determine the potential scope of a security threat to an IT environment, Rabinovitch said.

    The Datadog platform is already widely employed to monitor cloud computing environments. There is an industry wide effort to take monitoring to the next level by enabling observability, which applies analytics to provide more context. Surfacing that context, however, requires the ability to normalize data across a pipeline using Vector, Rabinovitch said.

    Of course, the Vector tools are equally applicable to DevOps workflows that have yet to incorporate security technologies. The goal, now, is to make it easier for IT teams, made up of developers, IT operations teams and security specialists, to collaborate by breaking down the various data silos created by IT and security management tools.

    It’s too early to tell what impact the rise of DevSecOps will have on roles within IT organizations. Most organizations will continue to employ a range of specialists that will be able to work more closely with IT generalists, Rabinovitch said. Managing IT is becoming the equivalent of a barn raising, in that it requires members of a community with different skills to come together for a certain amount of time to accomplish a specific task, Rabinovitch added.

    It’s also not clear whether IT organizations view observability as a distinct capability separate from monitoring, or whether they will simply view observability as the next logical extension of existing tools. At the core of that issue is debate over whether observability platforms need to be acquired separately, as part of an effort to replace existing monitoring tools, or whether those tools will evolve over time to provide observability capabilities.

    Regardless of the path forward, it’s apparent the increased complexity of modern IT environments – made up of microservices, containers and serverless computing frameworks – is about to force that issue.

  • Could No-Code Enable Everything Ops?

    Could No-Code Enable Everything Ops?

    It feels like DevOps principles are permeating every discipline, creating new buzzwords by the minute. DevSecOps. DatabaseOps. SalesOps. FinOps. MarketingOps. This “JargonOps” is clearly encouraged by marketing campaigns (and bloggers, wink, wink). Yet, the phrases do depict a real trend: all industries are getting an efficiency overhaul in the wake of increased automation.

    As I’ve covered before, low-code and no-code tools lower the barrier to entry to application development, enabling field experts to construct workflows as they see fit. For tech-savvy non-engineers, this could be a huge boon to transform copy-and-paste stopgaps into efficient workflow automations.

    I recently chatted with self-proclaimed “productivity geek” Sean Chou, CEO of Catalytic, to get his take on where this new era of automation is heading. From healthcare to logistics, advertising to supply chain management, every industry is likely to get an efficiency boost — and a lot of this digitization will be constructed using codeless environments.

    But first, how did we get here?

    From RPA to No-Code

    “The story of B2B software is largely about automation,” said Chou. If we consider classic examples of corporate applications, we see one common thread — B2B software has always sought to automate traditional office work.

    And so, it came to pass that computing and software devoured all these office tasks, from accounting to time-tracking, communications and many other areas. Though computer-based office work delivered huge efficiency boosts, these interfaces often introduced new hurdles; bad UI design, difficult navigation and a hundred open tabs, just to name a few.

    From there, robotic process automation (RPA) aimed to operationalize a growing number of tedious digital workflows across Excel spreadsheets, web apps and desktop apps. In Chou’s words, “RPA took the concepts of test automation software, and then pointed it toward production systems.”

    Though RPA’s process of recording screen interactions gathered much interest and attention (and funding), screen scraping is ultimately too fragile to be effective. It adds technical debt over legacy systems. It can be expensive to implement. Lastly, it’s not processes-centric and doesn’t implement reusable software-defined APIs.

    At that point, though, “Pandora’s box was open,” Chou said. Folks started to consider other ways to optimize, and reimagine how end users could automate workflows and stitch together interactions between disparate apps.

    Out of the ashes of RPA rose a new paradigm — low-code and no-code.

    No-Code Addresses Everything Ops

    With developer resources stretched thin and limited engineering talent available, it can be challenging to loop expert programmers into codifying traditionally non-IT processes.

    There’s not often enough developers to help with SalesOps, FinOps or any other Ops areas, explained Chou. “The only thing that can change the narrative is no-code technology that is effective.”

    Similar to how higher-level programming languages made low-level programming more accessible, Chou sees low-code and no-code unlocking accessibility for automation design by orders of magnitude.

    Four Examples of Everything Ops

    So, what are some examples of no-code use cases for automating operations? Chou outlined four specific categories that he believes will see much more citizen developer attention and action in the years to come:

    Customer Ops: “It’s really important to run customer operations as efficiently as possible,” Chou said. Especially in B2B interactions, people need to adopt various systems dictated by the customer. This can result in many ad-hoc implementations that beg for efficiency improvements.

    Financial Ops: Imagine the number of Excel spreadsheets that make up an account’s financial foundation. Consider the tedium of inputting data, generating reports or migrating calculations into other tools. There’s a ton to automate here. Providing no-code platforms to financial minds could have a “really transforming effect,” said Chou.

    People Ops: “The number of mini apps being developed for HR use cases is astounding,” Chou said. Think of all the digital tools HR must use: vacation requests, employee performance reviews, personnel databases – the list goes on. There’s a significant opportunity to clean up legacy applications within many HR departments to build a more coherent platform.

    SupplyChain Ops: Procurement and supply chain operations is another area where no-code could have an impact. Streamlining inter-company communications or engaging with potential customers are areas worthy of automation.

    No-Code? No Problem

    Across all these verticals, Chou notices three common patterns emerging.

    First, groups are using no-code to create standard operating procedures (SOP). SOPs could be used for onboarding or offboarding customers or ensuring compliance with a set of policies.

    Another everyday use is data pipelining — pulling information from many resources for analysis. A common use case is processing financial or customer data to generate a particular output. This is an area where embedded machine learning models could enrich the data.

    Lastly, a third common use case is creating workflow-powered surveys. These online forms could be used to measure employee engagement or to collect customer input. No-code workflows enable not only the collection of that data, but could allow for additional actions to be taken upon input.

    Implications and Governance

    Of course, giving non-developers the keys to the castle could have some downsides. Let’s face it — computer science is, well, a science. There’s a reason engineers are taught strict practices around version control, data governance and peer reviews. All of which must still be upheld when establishing a citizen development culture — especially at scale.

    When it comes to low-code and no-code, “governance is a huge thing,” said Chou. “Any company coming at this with no governance in mind can’t work beyond small teams.” Move beyond 10 or so citizen developers, and you’ll really need to establish some sort of shared framework or center of excellence.

    Making citizen development work in a large company requires IT visibility, data governance and a review process for new workflows, said Chou. IT will likely also want to verify that a new workflow doesn’t make permanent state changes. Otherwise, static apps that don’t touch core systems or affect persistent data stores are probably fine. “Having built-in governance is really key to making this successful,” Chou said.

    A Technology Leap

    No-code is giving more people the ability to produce unique workflows to increase their efficiency and do more with less. But with this movement comes worry. “With every technology leap, there’s always a wave of people concerned,” said Chou. Many naysayers are worried that automation will leave people out of work – “They’re coming for our office jobs!”

    Instead, Chou recommended we curb our expectations. Citizen developers are not going to build sophisticated iPhone apps any time soon. “If you think no-code is a panacea for all software, you’re coming at it all wrong,” he said. Instead, what they can actually can accomplish is far more practical.

    In reality, things are not as dire as some may make it seem. The new age of automation will likely open room for more jobs than it diminishes. “The net is always a plus,” said Chou.