Category: DevOps Practice

  • Low-Code Has Taken Development by Storm. Why Not the Web?

    Low-Code Has Taken Development by Storm. Why Not the Web?

    For more than a decade, development tools increasingly have made their way into the hands of less-technical people. On the web in particular, we’ve eliminated the webmaster as the middleman with content management systems and moved progressively toward a model where non-technical users could assemble their own sites with little to no coding experience of their own.

    Fast forward and today, the terms “no-code” and “low-code” are used to describe this idea. Furthermore, no-code and low-code tools have been on a decade-long rise, with an increasing impact on the web. Examples include:

    While this has been a strong, decade-long market trend, we’re only at the beginning. This trend won’t stop until new website experiences are automatically generated and optimized by machine learning.

    Trends Driving the Low-Code and No-Code Movements

    According to Wave, “In our survey of global developers, 23% reported using low-code platforms in 2018, and another 22% planned to do so within a year.”

    Major market forces driving this trend include a talent shortage among developers, with an estimated 1 million computer programming jobs expected to remain unfilled by 2020 in the U.S. alone. What’s more, the developers who are employed are often overloaded with work and struggle with how to prioritize it all. Some of this burden could be removed by low-code and no-code tools, allowing marketers and other non-technical professionals to do some of the development work themselves. In addition, the fact that technology has permeated every aspect of our lives, from our smartphones to our smart homes, has driven the need for more people to become creators.

    “As creating things on the internet becomes more accessible, more people will become makers. It’s no longer limited to the <1% of engineers that can code, resulting in an explosion of ideas from all kinds of people,” said Ryan Hoover, founder of Product Hunt, in a blog post.

    In other words, the supply of web creators must keep up with the demand for more digital experiences across more channels.

    But this does not only apply to individuals. Consider this: The typical large organization has to build and maintain hundreds of sites. These organizations need to build, launch and customize sites in days or weeks, not months. Today and in the future, marketers and other non-technical stakeholders can embrace no-code and low-code tools to develop websites rapidly.

    Abstraction Drives Innovation

    As predicted in my middleman blog post, developers won’t go away. Just as the role of the original webmaster has evolved with the advent of the CMS, the role of web developers is changing with the rise of low-code and no-code tools.

    Today, developers tend to focus on creating next-generation digital experiences that require new and emerging technologies not yet available in no-code solutions. In the process, they help invent and build new technologies such as React, Vue.js, etc.

    Successful no-code approaches abstract away complexity for web development. This enables less-technical people to do things that previously only could be done by developers. When those abstractions happen, developers can move on to the next area of innovation.

    Such abstractions are a good thing for both developers and non-technical website creators. When everyone is a builder, more good things will happen on the web. I was excited about this trend more than 12 years ago and remain excited today. I’m eager to see the progress no-code and low-code solutions will bring to the digital world in the next decade.

    — Dries Buytaret

  • Machine Learning and Predictive Analytics Are Reshaping Manufacturing

    Machine Learning and Predictive Analytics Are Reshaping Manufacturing

    Regardless of industry or vertical, companies everywhere are encountering a new generation of customers with ever-evolving expectations. These new demands are forcing brands to redefine the way they do business.

    Today’s customers overwhelmingly favor the simplicity of subscription models, in which they pay a flat monthly fee for access to a product in the form of a service. For example, consumers no longer buy or rent DVDs; they subscribe to Netflix. And more prefer to use the services of Uber or Lyft over traditional car ownership. As these digital-age consumers enter the industrial workforce in large numbers, they are causing business models to be redefined, leading to an increasing trend toward subscription-based services in manufacturing industries.

    This shift toward a subscription-based business model in the manufacturing industry is being referred to as servitization, wherein manufacturers no longer strictly sell new products but instead sell access to and the outcome those products deliver. This new way of delivering services is forcing manufacturers to shift to subscription-based pricing models, where product-as-a-service is the norm. Manufacturers of complex industrial equipment, because they operate in a B2B environment, can attribute this shift to another major cause: Their customers are also dealing with complex operating paradigms, forcing them to improve productivity and capital utilization. In these scenarios, customers are looking to simplify their businesses and increasingly favor suppliers that can help minimize their risks in operating a profitable business.

    The full realization of servitization, which could take up to 15 years, especially impacts manufacturers’ after-sales service organizations (the service delivered after the initial sale of a product). In today’s current reactive, break-fix service model, the responsibility to maintain and ensure equipment availability falls on the customer. In a servitization model, however, manufacturers own the responsibility of maintenance and repairs and need to focus on maximizing product uptime, since revenue can only be earned when their products are available to generate output in the field.

    Machine Learning and Predictive Analytics in Manufacturing

    The use cases of machine learning and predictive analytics are as varied as the industries within manufacturing. However, there are a few common use cases that apply to most manufacturing verticals, typically grouped under terms such as smart manufacturing, industry 4.0 or industrial internet of things (IIoT).

    1. Predictive Maintenance: Predictive maintenance is the most well-understood and varied use case in most manufacturing industries. Here, data from process monitoring sensors such as temperatures, pressures, flows, vibrations and more are captured in real-time and used in pattern recognition software to detect the earliest symptoms of wear and tear predictive of eventual functional failures. Early detection and prediction can help prevent failures or at least plan for eventual corrective actions leading to minimized downtime. Downtime—especially unplanned downtime—can be a very expensive event, possibly leading to millions of dollars in losses. Some analysts estimate unplanned downtime in certain industries is worth $20 billion.
    2. Process Optimization: Process optimization, in which existing processes are updated and optimized based on historical data, is a critical use case, especially in industries such as power generation, oil and gas refining, petrochemicals and chemicals. In this instance, sensor data feed machine learning algorithms for yield and quality optimization of output components for different combinations and quality of input raw material feedstocks. This also helps with energy efficiency, thus improving sustainability and profitability for these process manufacturers. In the global airline fleet, for example, a 1% fuel savings would save $30 billion over the next 15 years.
    3. Supply Chain and Inventory Management: High levels of raw material, work-in-process and finished goods (e.g., replacement service parts) inventory are one of the highest contributors to inefficient capital utilization for discrete manufacturing industries. Using machine learning to improve raw material and demand forecasts while meeting dynamically changing production goals helps improve capital utilization and supports lean and just-in-time manufacturing production goals.

    In today’s customer-driven world, manufacturers no longer can rely on selling expensive spare parts and services, since these become costs of supporting a single-price subscription. This shift will require manufacturers to completely re-think how they operate—new organization structures and skilled resources, new incentive models, new KPIs to measure success and new processes replacing ones developed over decades and centuries. They will have to become data-driven organizations, investing in technologies to connect and track products, collect data and efficiently analyze these massive amounts of operational and service data, using technologies such as IoT, machine learning and predictive analytics. This will strain manufacturers’ existing organizations and IT infrastructures, necessitating investment in highly scalable cloud-based solutions to lay the foundation for a successful future.

    Manufacturers that embrace these changes will be the winners, while others will struggle to stay relevant. In fact, the ones who can successfully adapt to these paradigm shifts will be able to gain a significant competitive advantage over their competition.

    — Vivek Shah

  • How Continuous Testing Advances Your Business Goals

    How Continuous Testing Advances Your Business Goals

    The goals of any successful business fit into two broad categories: driving higher revenue and greater operational efficiency. Finding solutions to achieve both of these is an organization’s goldmine.

    Considering the ease of access to new, alternate products from developers across the globe, competition continues to grow. In the software industry, customer expectations magnify cut-throat competition. Users expect newer features, faster releases and ever-improving optimal performance.

    To achieve these core business goals, DevOps teams now develop software with a mindset of continuous delivery. This practice helps organizations achieve faster release cycles while delivering newer features to meet customer demand.

    For most teams, there remains a major ongoing challenge: effective testing within this high-speed delivery cycle. Traditional (non-automated) testing methods became a bottleneck in the CI/CD pipeline mindset, forcing organizations to choose between quality and speed to market.

    Continuous testing helps overcome this problem by weaving testing throughout the delivery cycle by leveraging automation. But what tests should be automated?

    In late 2018, KMS surveyed 135 professionals who successfully implemented continuous testing, for their insights on the process. Of the organizations surveyed, the following tests were always automated:

    • Unit tests (47.4%)
    • Component tests (46.7%)
    • Integration tests (45.9%)
    • UI tests (38.5%)
    • Performance and load tests (57%)
    • Security tests (52.6%)
    • User acceptance tests (34.1%)

    We also found the top three focus areas of test coverage for continuous testing were:

    • Integration tests (55.6%)
    • Security tests (48.1%)
    • UI tests (43.7%)

    As a bottom line, businesses must successfully adopt continuous testing to keep their delivery pipelines in sync with development.

    Despite several benefits arising from continuous testing, KMS found a few challenges for organizations that have adopted this methodology. Seventy-eight percent reported that continuous testing would have been easier to adopt with a directive from their executive leadership.

    What’s more, 78% indicated they would have liked more team ownership of the initiative and 86% would have liked better team collaboration.

    So, how do organizations get executive buy-in and rally the team to adopt the practice? By understanding and communicating how continuous testing directly contributes to achieving the two key business goals of increased revenue and operational efficiency.

    Let’s drill down into increased revenue generation. After all, money is what keeps any business in motion. Businesses drive revenue by:

    1. Solving a pain point for customers.
    2. Encouraging users to adopt their solution.
    3. Having the agility to shift and meet changing consumer needs, with speed.

    To achieve operational efficiencies, businesses focus on:

    1. Achieving shorter release cycles.
    2. Receiving feedback and ability to respond with agility.
    3. A more effective team, without increasing headcount.

    With these goals in mind, there are three core business cases for adopting continuous testing:

    Increased Agility and Confidence in Quality

    Agile is the ideal delivery model for all software companies. True agility means organizations can shift focus quickly and respond rapidly to customer feedback or changes in the market. It also gives teams the freedom to explore new opportunities/solutions. Continuous testing enables this agility by supporting a shift-left philosophy that uses test automation in the earlier stages of the development cycle. Shifting left enables a continuous feedback loop that allows teams to respond to defects and establish better team communication.

    By adopting continuous testing, 80% of professionals found fewer defects escaping to production. Reacting to feedback quickly allows companies to give customers the products they want. An organization can increase revenue by delivering market-disrupting features.

    Automation tools also encourage a testing mindset in developers—80.7% of companies adopting continuous testing have found their developers doing more testing. This mindset shift is critical to achieving agility with better collaboration. It makes the quality of the software the responsibility of the entire team, truly aligning with the Agile Manifesto. As a result, product quality and user experience benefit, and happy customers increase revenue.

    Faster Overall Speed

    Keeping up in today’s market requires shorter release cycles. As I mentioned earlier, adopting continuous testing enables faster sprints by eliminating the testing bottleneck at the end of the delivery life cycle. In fact, 83.7% of companies have achieved shorter release cycles by adopting continuous testing.

    Speeding up the software development life cycle pushes products to market faster. Getting features in the hands of customers before your competition gives your company a huge competitive edge. By adopting continuous testing, companies are not slowed down by antiquated testing initiatives. Speed enables them to compete on a global scale and disrupt the market.

    Lower Operational Expenses

    How do you balance speed and cost? Automation. Continuous testing automates routine tests. By using open source tools such as Katalon, teams can automate with minimal extra expense. This not only helps you test faster, but your team can be more productive—84.4% of companies have achieved better test coverage with the same team size and 67.4% were able to test with smaller teams. Either way, you get more done without investing in additional overhead.

    However, automation is not here to replace testers. Automation in pre-production environments gives your resources the bandwidth to work more strategically: 53.3% of companies that have implemented continuous testing don’t test manually in pre-production environments. Seventy-four percent now have the bandwidth for exploratory testing in production. Use your team and resources where they are most effective, doing the work automation can’t. Ultimately, smart use of resources achieves a sought-after balance of speed and cost.

    By exploring the business cases for continuous testing, companies achieve true agility. The methodology seamlessly aligns with fundamental business goals. Enabling continuous delivery, continuous testing will support revenue growth and operational success for your organization.

    — Mush Honda

  • Networking: The DevOps Community Deserves Better

    Networking: The DevOps Community Deserves Better

    Developers of cloud-native applications are at the heart of a process of radical transformation shaking up the business world. Using DevOps and SRE methodologies, modern development teams are bringing a level of agility to the game that is all about freeing enterprises from the shackles of the old, pre-cloud days and letting them take advantage of new opportunities at light speed.

    But the developer community has a problem. The process of developing and delivering cloud-native applications in a DevOps paradigm demands the right connectivity to back it up, and traditional networks aren’t doing the job. Cloud-native developers need cloud-native networking—network solutions that work in the same frictionless and agile way they do—solutions that put the application first and replace traditional manual network configuration with connectivity-as-code.

    To play their part, developers need application-friendly connectivity that is designed for applications composed of microservices and APIs which span many edges, clouds and service meshes. A new software only, cloud-native approach to connectivity is required to address this and other challenges such as security, performance and operational support at scale.

    There are four things developers shouldn’t take for granted in a network solution: agility, security, simplicity and performance.

    Agility

    What application developers need is a cloud-native, agile, on-demand alternative to traditional networking—something that delivers the speed to market that they need, and safeguards their profitability. With a model such as application-specific networking in network-as-a-service models, application development teams can create on-demand connectivity across edge, cloud and service mesh environments to support their apps wherever their apps travel.

    Security

    App developers require zero-trust software defined perimeter security that meets and exceeds even the most stringent compliance standards, and can be controlled as code by their DevOps tools and applications.

    Simplicity

    New networking approaches that puts the application in contol can abstract the developer and DevOps teams from the complexity of differences between underlying networks, clouds or service meshes.

    Cost-Effective Performance

    Application-controlled network-as-a-service models can deliver operational cost reduction over traditional MPLS and VPN solutions, while boosting throughput and performance compared with legacy alternatives.

    Conclusion

    Developers deserve better networking. It’s time for them to say goodbye to the old way of doing things and move on from restrictive legacy solutions with their lack of scalability, absence of agility, poor security and unpredictable overheads.

    — Galeal Zino

  • Transforming the Security Team Into a DevOps Partner

    Transforming the Security Team Into a DevOps Partner

    Securing DevOps environments is an increasingly important concern for chief information security officers (CISOs) and security teams. While developers often recognize security is important, it is not their top priority. More typically, the DevOps team prioritizes delivering new capabilities and features to the business and customers, often as part of a larger digital transformation initiative. And, developers often view security as something that will slow down deployments.

    Security teams usually have limited DevOps knowledge or expertise. Too often the result is that DevOps adoption begins and even takes hold inside an organization before the security team gets involved. Consequently, security vulnerabilities are not always adequately addressed in DevOps environments and can drive unnecessary risk.

    Integrating Security in DevOps

    The priority is for the security team to take the lead in integrating security into the DevOps processes before poor practices become entrenched. But as both teams are often siloed and don’t tend to work collaboratively, how can security teams better engage, energize and collaborate with their DevOps counterparts to strike the right balance? In a nutshell, how can organizations bring their DevOps and security teams into alignment and establish collaboration for stronger overall security?

    There are a few crucial steps to take to achieve true integration of security and DevOps.

    1. Establish the Requisite Skills to Get in the Driver’s Seat. Effective collaboration requires effective communication. While developers write the actual code, it’s important for security teams to gain knowledge about programming languages along with how applications are built, tested and deployed automatically. This will help them have more meaningful discussions and credible conversations. Security professionals can start by learning some of the fundamentals: PowerShell, Python and Rust, as well as how DevOps tools use REST calls and containerization technologies–particularly Docker and Kubernetes.
    2. Make it Easy for Developers to Do the Right Thing. You can’t be the manual cog in their completely automated process. Make it easy for developers to do the right thing by training them in secure coding practices and implementing a self-service model for security capabilities. For example, you could provide security policy as code that can be integrated into the developers’ automated processes.
    3. Establish Effective Ways to Collaborate. Set up formal systems to ensure DevOps practitioners understand security risks and implement good security practices across the organization. Consider how best to deploy security resources into existing or new organizational models and structures. This includes establishing centers of excellence, community leaders, security champions and embedding security team members inside development teams.
    4. Get Developers to Think Like Attackers. Educate DevOps teams on specific attacker tactics, show how sample code modules could expose secrets and provide examples as user stories. For example, “As an attacker, I would scan the organization’s code repositories looking for secrets.” Take the team through a penetration testing exercise or engage a red team to demonstrate how an attacker would compromise a CI/CD pipeline.
    5. Adopt Agile and DevOps Methods. Security should begin utilizing agile and DevOps methods within their own teams, not only to gain a deeper understanding of DevOps methodologies but also to achieve greater efficiency by automating tasks or delivering capabilities in smaller increments more frequently.

    The bottom line is, it is crucial to understand how other enterprises approach secrets management challenges across DevOps and cloud environments. This can help encourage collaboration and help fast-track the security team’s own efforts. Ultimately, this will ensure agility is not just implemented for the sake of innovation, but companies reflect on their processes and prioritize security to make the most of their transformation.

    — Josh Kirkwood

  • 3 Reasons Why DevOps Is More Popular Than Ever

    3 Reasons Why DevOps Is More Popular Than Ever

    How popular is DevOps? More popular than ever, if Google Trends is to be believed. Here’s a look at how the popularity of DevOps has increased over time, and what has driven the change.

    The Spiking Popularity of DevOps

    Here’s what Google Trends tells us about interest over time of the term “DevOps” over the past 15 years:

    And here’s the data for the same term over the past five years:

    As you can see, talk about DevOps began circa 2010 and increased steadily thereafter. But it wasn’t until early 2019 the interest in DevOps sharply increased.

    Granted, Google Trends is a crude, closed-source data source. And interest in DevOps as measured by Google is certainly not a straightforward representation of things such as the economic importance of DevOps or the influence of DevOps within programming communities specifically (as compared to within Google’s user base as a whole).

    Why is DevOps More Popular Than Ever?

    Still, I was surprised to see such a large and sudden spike in interest in DevOps starting early this year. I can’t think of any singular event that explains the trend. But I can think of several longer-term factors that, when added together, probably have been responsible for ushering in a world where more people than ever are talking about DevOps.

    One is the fact that DevOps finally seems to have made its way into mainstream computer science and IT education. Here, I’m speaking a bit anecdotally. I’m not aware of any surveys of how many universities overall include DevOps in their curricula. But I can attest it is at least mentioned in some of the CS and IT courses at the technical university in the U.S. where I teach. To my knowledge, this was not the case just a few years ago.

    What this means is the university is now graduating students who are already familiar with DevOps as they enter the workplace. They are spreading the gospel of DevOps to organizations that have not already heard it, and they are reinforcing it where it is already present.

    Another factor at play, I think, is the market for DevOps tools has matured and consolidated. Even just five years ago, most companies talking seriously about DevOps were startups. Now, many of those startups have become hugely successful independent companies (such as Slack) or have been acquired (such as Wercker or Electric Cloud) by larger organizations.

    To be sure, plenty of other DevOps startups have failed or stalled. But the fact that others have succeeded spectacularly has done much to drive continued interest in DevOps.

    Last but not least, the tooling for DevOps has matured along with the market. Circa 2010, when the conversation about DevOps was getting started, it was much easier to talk about de-siloing your IT organization than it was to break down the silos in practice. At the time, DevOps-friendly collaboration tools had not yet gone mainstream. Release automation suites were also mostly limited to PaaS-style offerings whose features amounted primarily to automating deployments. They lacked the end-to-end integration, testing, building and management features of modern DevOps release tools. And many of the more advanced DevOps release platforms were built by startups, which made adopting them somewhat risky (because you could end up with a platform of a vendor that went out of business suddenly).

    Today, in contrast, there is a litany of mature, feature-rich CI/CD tools to choose from—not to mention communication and collaboration solutions such as Slack and GitHub. It’s very easy to build a DevOps toolset, and you no longer have to rely on new, market-untested solutions to do so. This fact, too, has helped make DevOps more popular than ever.

    How will the popularity of DevOps change from here? My guess is it will continue to rise as the market and DevOps tooling mature even more, and as DevOps continues to make its way into mainstream educational programs.

    — Chris Tozzi

  • Digital Transformation Drives C-Suite Discord

    Digital Transformation Drives C-Suite Discord

    In the sport of rowing, each crew member has to row in synchrony or the boat risks undesired turns and even potential tipping. It takes practice, communication and discipline for each crew member to raise their oar to the appropriate height and apply the appropriate power. Obviously, those crews who work best together are more likely to win.

    When it comes to winning at digital transformation, the same is true for the executive crew or C-suite. However, the drive to  digitally transform enterprises rapidly puts a strain across C-suite relationships.

    That’s the main takeaway from a new report published by the Financial Times Focus and business management software provider Apptio, “Disruption in the C-suite.” The report is based on a survey of 555 senior executives, about half in CxO roles and from Australia, Denmark, France, Germany, Italy, Japan, the Netherlands, Norway, Spain, Sweden, the UK and the U.S.

    The survey found considerable uncertainty regarding the IT department’s ability to be effective. In fact, 51% of respondents said they have concerns about IT’s ability to govern cloud adoption. And, surprisingly, less than one-fifth of companies using agile have defined performance indicators they use to track their results.

    Further, 47% of leaders surveyed agreed digital transformation has blurred work responsibilities throughout the C-suite. And the same number of respondents admitted digital transformation has exacerbated strategic differences among finance and IT leaders. In fact, 71% of finance leaders said the IT function needs greater influencing skills to deliver the change their business requires.

    According to the survey, while the CFO was the least deeply aligned member of the C-suite crew with the CIO, the lack of deep alignment with the CIO’s office and other C-level executives was shown to be disturbingly common. Only 56% of CEOs reported being deeply aligned with the CIO, the survey found.

    There are signs of hope. Eighty-seven percent of respondents in the U.S. said digital transformation has increased collaboration across C-level executives when it came to developing new products and services.

    Still, 63% of those surveyed said the IT function needs greater influencing skills to deliver the change their business requires.

    That lack of influencing skills—and lack of defined metrics to measure progress—has taken its toll. About one-third of CFOs said there is a lack of consensus among CxOs when it comes to how to measure the impact of new technologies.

    It’s interesting, 56% of respondents said they shift their IT strategy continuously as their technology leaders receive input from the business and customers. That’s hopefully advantageous, but with so much digital transformation discord among technology and business leaders within organizations, it’s a coin flip whether that’s good stewardship or blind steering.

    It’s absolutely vital that organizations get their digital transformation efforts right, and to also be able to do so successfully at the necessary speed. As we covered in the recent story, “Digital Transformation Vital for Business Survival,” 78% of organizations believe their company’s primary industry is evolving rapidly and digital transformation is necessary to survive the changes underway.

    Those businesses cited enhanced customer experience and customer relationship management, the ability to maintain competitiveness, enabling new ways of doing business, increased productivity, cost savings, increased revenue generation and enhanced product development.

    Few would doubt the accuracy of that assessment, nor that the entire C-suite crew must be in synchrony, understand each other’s roles and objectives and know where the entire team is heading. Otherwise, the entire effort is likely to veer off course.

    — George V. Hulme

  • AWS Advances DevOps Agenda at Summit Event

    AWS Advances DevOps Agenda at Summit Event

    Amazon Web Services (AWS) has added services to its cloud platform designed to automate the creation of virtual private clouds (VPCs) and made available additional tools to build applications and integrate external data.

    Speaking at the AWS Summit event, CTO Werner Vogels said these latest services are part of an ongoing effort to automate DevOps processes to the point at which developers will need to write only the code for business logic that runs on top of the AWS public cloud.

    One of the latest tools the company is making available in pursuit of that goal is AWS Cloud Development Kit (CDK), a software development framework for defining cloud infrastructure in code as constructs and provisioning it through AWS CloudFormation. AWS CDK currently supports TypeScript, JavaScript and Python with support for C#/.NET and Java available in preview. That capability will eliminate the need to write low-level code using a different tool just to spin up a VPC on AWS, Vogels said.

    AWS CDK also allows organizations to design and compose their own custom components for managing infrastructure alongside their application code.

    The cloud services provider also announced AWS EventBridge, a programmable event bus for integrating data on AWS with data residing in software-as-a-service (SaaS) applications on any platform based on a serverless computing framework, and the general availability of AWS Toolkit for Visual Studio Code, a plug-in for the Microsoft integrated development environment (IDE) that makes it easier to build, debug and deploy code on AWS.

    Finally, the company announced that Amazon CloudWatch Container Insights is now available in preview. This offering provides access to automated dashboards summarizing the performance and health of their Amazon Elastic Container Service (ECS) and Fargate clusters by tasks. Those offerings come on the heels of AWS Fluent Bit, a tool for container logging being made generally available earlier this week.

    Vogels stressed that the way applications are built is now fundamentally different in the age of the cloud. Developers are making greater use of containers and serverless computing frameworks. The challenge with containers is that in the absence of a cloud service provider to manage the environment, the complexity of the underlying middleware and infrastructure conspires to reduce the amount of time developers spend on writing actual application code, he said.

    To address that issue, AWS is investing more in container and Kubernetes services as well as in on-demand serverless computing services such as AWS EventBridge that don’t require organizations to pay for idle processes, Vogels explained.

    In general, Vogels said AWS continues to advocate for the elimination of separate IT operations and cybersecurity teams in favor of a more unified approach leveraging automated services provided by AWS that ensure, for example, the entire continuous integration/continuous deployment (CI/CD) platform is secure. However, while the number of organizations embracing best DevOps and DevSecOps processes continues to increase steadily, it’s much less clear how many of them will standardize those processes on a single cloud platform at a time when reliance on multiple clouds also continues to increase steadily.

    — Mike Vizard

  • What Quality Metrics Matter Most for DevOps?

    What Quality Metrics Matter Most for DevOps?

    The way we develop and deliver software has changed dramatically in the past five years—but the metrics we use to measure quality remain largely the same. Despite seismic shifts in business expectations, development methodologies, system architectures and team structures, most organizations still rely on quality metrics that were designed for a much different era.

    Every other aspect of application delivery has been scrutinized and optimized as we transform our processes for DevOps. Why not put quality metrics under the microscope as well?

    Are metrics such as number of automated tests, test case coverage and pass/fail rate important in the context of DevOps, where the goal is immediate insight into whether a given release candidate has an acceptable level of risk? What other metrics can help us ensure that the steady stream of updates don’t undermine the very user experience we’re working so hard to enhance?

    To provide the DevOps community an objective perspective on what quality metrics are most critical for DevOps success, Tricentis commissioned Forrester to research the topic. The results are published in a new eBook, “Forrester Research on DevOps Quality Metrics that Matter: 75 Common Metrics—Ranked by Industry Experts.”

    The goal was to analyze how DevOps leaders measured and valued 75 quality metrics (selected by Forrester), then identify which metrics matter most for DevOps success. Here’s a look at the process:

    1. Survey 603 global enterprise leaders responsible for their firms’ DevOps strategies.
    2. From that sample, identify the firms with mature and successful DevOps adoptions (157 met Forrester’s criteria for this distinction).
    3. Learn what quality metrics those experts actually measure and how valuable they rate each metric they regularly measure.
    4. Use those findings to rate and rank each metric’s usage (how often experts use the metric) and value (how highly experts value the metric).
    5. Compare the DevOps experts’ quality metric usage versus that of DevOps laggards. If there was a significant discrepancy, the metric is considered a DevOps differentiator.

    The 75 DevOps quality metrics were divided into four categories:

    • Build
    • Functional validation
    • Integration testing
    • End-to-end regression testing

    For each category of quality metrics, we came up with a heat map showing usage versus value rankings. For example, here is the heat map for the Build category metrics.

    We also plotted the data for each metric into a quadrant with four sections:

    • Value Added: Metrics that are used frequently by DevOps experts and consistently rated as valuable by the organizations that measure them.
    • Hidden Gem: Metrics that are not used frequently by DevOps experts but are consistently rated as valuable by the organizations that measure them.
    • Overrated: Metrics that are used frequently by DevOps experts but not rated as valuable by the organizations that measure them.
    • Distraction: Metrics that are not used frequently by DevOps experts and not rated as valuable by the organizations that measure them.

    For example, here is the quadrant for Build category metrics:

    The eBook provides both heat maps and quadrants for all four categories, a quick look at each of the 75 metrics per-category and overall analyses, as well as a few fun lists.

    Here’s a preview:

    Hidden Gems

    The following metrics are not commonly used (even among DevOps experts), but are ranked as extremely valuable by the select teams who actually measure them:

    1. New defects (IT)
    2. Critical defects (FV)
    3. Automated tests prioritized by risk (Build)
    4. Code coverage (Build)
    5. Test cases executed (Build)
    6. Static analysis results (Build)
    7. Variance from baselines of percent of test cases passed (E2E)
    8. Release readiness (E2E)

    Top DevOps Differentiators

    DevOps experts/leaders measure the following metrics significantly more than DevOps laggards measure them:

    1. Automated tests prioritized by risk (Build)
    2. Percent of automated E2E test cases (E2E)
    3. Risk coverage (IT)
    4. Release readiness (FV, IT, E2E)
    5. Test efficiency (FV and IT)
    6. Requirements covered by tests (Build, FV, IT, E2E)
    7. Test case coverage (Build, E2E)
    8. Static analysis results (Build)
    9. Variance from baseline of percent of test cases passed (E2E)
    10. Test effectiveness (FV, IT, E2E)

    Most Used by DevOps Experts

    The following metrics are the most frequently used (overall) by DevOps experts/leaders:

    1. Test case coverage (E2E)
    2. Pass/fail rate (FV)
    3. API pass/fail rate (IT)
    4. Number of tests executed (E2E)
    5. API bug density (IT)
    6. Requirements covered by tests (FV)
    7. Requirements covered by tests (E2E)
    8. Blocked test cases (FV)
    9. Percent of automated E2E test cases (E2E)
    10. Successful code builds (build)

    Most Valued by DevOps Experts

    The following metrics are the most highly valued (overall) by DevOps experts/leaders:

    1. Requirements covered by API tests (IT)
    2. Percent of automated E2E tests (E2E)
    3. Requirements covered by tests (E2E)
    4. Requirements covered by tests (FV)
    5. Count of critical functional defects (FV)
    6. Total number of defects discovered in test (E2E)
    7. Number of test cases executed (E2E)
    8. Pass fail rate (FV)
    9. New API defects found (IT)
    10. Automated tests prioritized by risk (build)

    — Cynthia Dunlop

  • Workflow Automation Poised to Accelerate DevOps

    Workflow Automation Poised to Accelerate DevOps

    Automation is taking the market by storm. Research firm Gartner predicts that by 2020, more than 40% of data science tasks will be automated, and that is just the tip of the iceberg. Businesses are turning to automation to reduce costs, increase productivity and gain a competitive advantage. Add DevOps to the mix and it becomes readily apparent how DevOps teams can benefit by leveraging a little workflow automation. After all, the DevOps process is framed by repeatable workflows, wherein the agile manifesto dictates progress or other frameworks define how change moves through the development and deployment cycles.

    “Most development projects are hindered by numerous manual steps and the lack of defined collaborative communications methodologies, leaving far too much room for error,” said Raj Mehta, CEO of Raj Technologies. “Defining a workflow and bringing automation into the picture could go a long way toward reducing errors.”

    The DevOps community has come to rely on many manual processes and numerous tools to keep the pace of rapid application delivery and change management. Those solutions often have points of failure, where important tasks can slip through the cracks. Even so, many developers are resistant to change and embrace the processes they have already established. Yet, intertwining manual processes with automation and management tools has been demonstrated as rather inefficient, slowing the perception that workflow automation can actually achieve the productivity promises claimed.

    Perhaps the challenge comes from the fact that many DevOps teams require assistance to achieve any type of automation goals. That indicates there may be a lack of qualified professionals to bring forth workflow automation. “You have to crawl before you can run, and that means you must become an expert in designing workflows, before deploying one, or at the very least, turn to an expert,” Mehta noted.

    A workflow is a fundamental process that dictates the steps to achieve a goal. Workflows have been used for centuries by businesses and have become digitized over the last few decades, with numerous workflow tools coming from leading vendors.

    Many technologists may have first encountered the workflow ideology back in the days when Microsoft’s Sharepoint first came on the scene, which offered rudimentary tools for routing content through various steps. Of course, the workflows in use today have become much more complex, requiring designers to not only know how to script actions but also understand the overall goal of those actions.

    That’s a simple truth understood well by Workfront, a Lehi, Utah, based vendor of workflow solutions which is looking to better service various organizations, as well as DevOps professionals, to create workflow automation opportunities. The company’s primary product goes by the name of Workfront as well and uses a platform-based approach for creating workflows that can be integrated across multiple technologies, bringing centralized workflow orchestration to many use cases.

    Tools like Workfront fit well into the automation equation by creating the foundation of workflows. However, most DevOps professionals need more than workflow design to achieve improved automation. Other elements must be considered, such as demand management, resource management, project templates, policies and scripted actions. Efficient workflow tools should also incorporate task lists, collaboration capabilities and reporting.

    Of course, Workfront is only one of many workflow automation companies on the market. Many other vendors are established in the market, with Market News Reports mentioning leaders such as Pegasytems, Tibco Software and Sourcecode Technology Holdings dominating the market.

    HNY Research projects workflow automation market size will grow to $16.58 billion by 2023 from $4.68 billion in 2017, at an estimated CAGR of 23.48%. Key factors such as ease in process with the installation of workflow automation tools, convergence of workflow automation with traditional business processes, focus on streamlining business processes and cost efficiency through workflow automation are driving the workflow automation market.

    “Business leaders must carefully analyze different processes and identify which workflows can automated. Therefore, business leaders should avoid rushing into workflow automation adoption and analyze the various potential use cases and choosing which vendors best fit in their organization,” said Naveen Joshi, founder and CEO of Allerin.

    Many businesses are leveraging workflow solutions on their path to digital transformation and bringing once-manual processes into a world where automation can be applied. While some may argue over the intricacies of digital workflows and how those workflows fit into business process management (BPM), one truth remains evident: The goal is to digitally transform and introduce automation, which in turn indicates robotic process automation (RPA), becomes the next logical step.

    According to Grand View Research, the global RPA market is expected to register a CAGR of 31.1%, from $597.5 million in 2018, driven largely by demand for business process automation via artificial intelligence (AI) and software robots.

    RPA paired with workflow design may prove to bring full digital transformation to DevOps, and potentially grow beyond just a niche in those challenging environments. Workflows, BPM, BPA and RPA are becoming increasingly important to DevOps organizations seeking to lower error rates, boost productivity and improve communications.

    — Frank Ohlhorst