Month: February 2020

Article originally posted on InfoQ. Visit InfoQ

GitHub announced the release into public beta of their Actions API. The Actions API can be used to manage GitHub Actions via a REST API. Endpoints available within the API allow for managing artifacts, secrets, runners, and workflows.

GitHub Actions allow for automating workflows based on repository events such as push, issue creation, or the creation of a new release. These workflows can be created either via a visual editor or by writing YAML code. GitHub released CI/CD for GitHub Actions in August allowing for building and deploying software directly within GitHub and without the need for third-party services.

The workflows API allows for viewing workflows associated with a repository. This includes listing all the workflows or getting a specific workflow. For example, the request:

curl -u username:token  
"https://api.github.com/repos/my-org/hello-world/actions/workflows/72844"

Will return the following details about workflow 72844 within the hello-world repo:

{
  "id": 72844,
  "node_id": "MDg6V29ya2Zsb3cxNjEzMzU=",
  "name": "CI",
  "path": ".github/workflows/blank.yml",
  "state": "active",
  "created_at": "2020-01-08T23:48:37.000-08:00",
  "updated_at": "2020-01-08T23:50:21.000-08:00",
  "url": "https://api.github.com/repos/my-org/hello-world/actions/workflows/72844",
  "html_url": "https://github.com/my-org/hello-world/blob/master/.github/workflows/72844",
  "badge_url": "https://github.com/my-org/hello-world/workflows/CI/badge.svg"
}

Details from a run of a workflow can be accessed through the workflow runs API. A Workflow run within GitHub Actions is an instance of a workflow that runs on the configured event. This API provides access to view runs, review the logs for a run, re-trigger a workflow, and cancel active runs. These endpoints provide access to the status of the runs including the overall outcome and duration. The Workflow jobs API enables access to details about the jobs including log files.

The API route for accessing the workflow run logs provides a redirect URL to download an archive of the log files. This link is accessible to anyone with read access to the repository and expires after one minute. This URL is provided as the location header in the response. As an example, it could be downloaded via one request with CURL by enabling the verbose output to see the header and using -L to permit the redirection to the location value:

curl -v -L -u username:token -o logs.zip /
"https://api.github.com/repos/my-org/my-repo/actions/runs/30209828/logs"

With the artifacts API users are able to download, delete, and retrieve information about workflow artifacts. Artifacts allow for sharing data between jobs in a workflow and also for persisting data after a workflow finishes.

While GitHub Actions run within Docker containers on GitHub’s servers by default, there is also support for self-hosted runners. Self-hosted runners allow for executing workflows on servers hosted within your own environment. The Self-hosted runners API allows for listing the runners within a repository, getting a specific runner, removing a runner, and creating the appropriate tokens for authorizing the runner. With this it is now possible to automate the the creation and clean-up of runners.

To facilitate working with the new API endpoints, GitHub has added additional data to the runner context. Each Actions run now includes a run_id and run_number. These values can be integrated into workflow scripts to more easily interact with the new API endpoints.

The Actions API is available for authenticated users, OAuth Apps, and GitHub Apps. Access tokens will require repo scope on private repositories and public_repo scope on public repositories.

The GitHub Actions API is available to all users who currently have access to GitHub Actions. GitHub Actions is available with most of GitHub’s pricing plans. However Actions is not available for repositories owned by accounts that are using the legacy per-repo plans. While the API is in beta, GitHub will be posting changes to their blog based on developer feedback.

Article originally posted on InfoQ. Visit InfoQ

ZetZ, or ZZ for short, is a Rust-inspired C dialect that is able to formally verify your code by executing it symbolically at compile time in a virtual machine.

ZZ is targeted to software that runs close to hardware but it can be also used to build cross-platform, ANSI-C compliant libraries. Actually, ZZ works as a transpiler to C code, which is then fed into any standard C compiler. In contrast to how many modern languages approach safety, ZZ does not preclude or limit features that are deemed “unsafe”, such as raw pointer access. Rather, it uses static single assignment form (SSA) to prove your code is undefined behaviour-free at compile time in a SMT prover such as yices2 or z3.

The following snippet shows how ZZ code looks like:

using <stdio.h>::{printf}

export fn main() -> int {
    let r = Random{
        num: 42,
    };
    printf("your lucky number: %un", r.gen());
    return 0;
}

struct Random {
    u32 num;
}

fn gen(Random *self) -> u32 {
    return self->num;
}

To prevent any undefined behaviour from leaking into your code, ZZ requires all memory access to be correct. For example, indexing into an array requires you to tell the compiler the accessed index is valid using the where keyword, which allows you to specify a constraint the caller has to satisfy:

fn bla(int * a)
    where len(a) >= 3
{
    a[2];
}

Analogously, the model keyword allows you to specify a constraints on the behaviour of a function:

fn bla(int a) -> int
    model return == 2 * a
{
    return a * a;           //-- This would fail here
}

To make all of this possible, ZZ includes a number of constraints on C syntax to make it more suitable to formal proving. For example, ZZ enforces east-constness and enables function pointers through function types.

InfoQ has spoken with ZZ creator and maintainer Avid Picciani to learn more about ZZ.

InfoQ: Could you describe your background and your current professional endeavours?

Picciani: My background is in large scale hardware, specifically I worked for Nokia on all of its Linux phones.

Currently, I am the founder of devguard.io. We do cloudless IoT management tools for data sovereignty.

The killer feature that gets developers excited is carrier shell, which allows you to open a remote shell to millions of devices without configuring any network in between. Just with a single ed25519 identity, you can talk to any device behind any physical network, of course peer-to-peer encrypted with us neither seeing nor storing any data.

We shipped about a quarter million devices with Rust on it, but want to expand to lower level embedded stuff that Rust cannot and does not want to target.

InfoQ: Could you tell us how ZZ was born?

Picciani: In order to offer our products for extreme low level hardware (ESP32, an AVR 8 Bit) we needed tools that enable extreme memory efficiency and portability. But coming from the rust language, transitioning back to C felt a little sad. Everyone here really loves Rust and C is full of pitfalls.

At the same time, lots of commercial tools exist for C that we need but are not available in Rust, such as compilers for obscure chips and regulatory approval processes.

ZZ is the result of 6 months of research into what current computer science can do to make programming better. Specifically it is inspired Microsoft research such as F* and Z3. It just transfers it to a more pragmatic language. We use F* at devguard as well, specifically for cryptography. Also Alloy is worth mentioning, which inspired the idea of counter-example based checking.

InfoQ: What are the main benefits ZZ provides and in which scenarios? Can it be considered a general-purpose language or is it more of a niche language?

Picciani: While Rust has a magic bullet for making programming safer (just don’t allow mutable borrow twice), ZZ is really just a layer on top of C. You can do whatever unsafe stuff you want, as long as you also additionally write a formal proof for it. It’s a very different way of programming, more like pair programming with a math professor who is constantly throwing corner cases at you under which your code will break.

Formal proofs can get very very boring and long, and as such ZZ isn’t really a generic programming language. You totally can write a web service in ZZ, and we in fact do, but it will never ever compete with the quick-to-go nature of the likes of NodeJS. That may change when we integrate alloy directly into the state machine generation, at which point you probably might want to try implementing security critical web applications in ZZ.

InfoQ: How do you deem ZZ current status of maturity?

Picciani: Either way, ZZ is very new and the two big ideas–transpiler for C, and symbolic verification–still have to fleshed out in detail. It already works today and I encourage people to try and build stuff with it, but be prepared for major compiler bugs and big language changes. For commercial code I would encourage people to use ZZ sparingly side by side with Rust, specifically ZZ is good for interfacing with C system code.

My company, devguard.io will ship a new product for cloudless automotive telemetry sometime around April which is mostly built in ZZ on top of the Zephyr OS and a Nordic NRF91, so we’re committed to it. The biggest open source code base in ZZ is probably the ZZ branch in devguard carrier. As soon as that is done, I feel like ZZ is ready for production.

To use ZZ, you need to install Rust for bootstrapping and provide a .toml file used by Rust package manager Cargo to compile your code.

Article originally posted on InfoQ. Visit InfoQ

A leader can act as a coach, provide opportunities for ownership, and find out what motivates people to foster high performing teams. It also helps teams if leaders have powerful and meaningful conversations with team members and give vocal feedback face to face to team members.

InfoQ attended Stretch 2020, a leadership and management conference that took place on February 13 and 14 in Budapest, Hungary. InfoQ interviewed several speakers from this conference to explore what leaders can do to foster high-performing teams.

Ivett Ördög, a senior software engineer and creator of lean poker, suggested to start by defining what we actually mean when we talk about high-performing teams:

For me the more important question is what we mean by a high-performing team, and what we mean by “the team”? When a company struggles to deliver value, it’s rarely because the development team couldn’t churn out code faster.

She continued by explaining who should be on the team and what we should expect from high-performing teams:

For a high performing team, the team should include everyone from product to engineering and they should all work towards a single well-defined goal: what is the next small product increment that brings the most value within the next 1 or 2 weeks?

To lead high-performing teams, leadership qualities like being able to coach people and give feedback can make a difference, as Amy Tez, a communications trainer and speaker, explained:

A leader is a coach. That doesn’t mean they have to be nice, but they have to be truthful and constructive and kind so they help people forward – to help the company forward. And give regular constructive insight and coaching and vocal feedback. So that people feel heard and supported towards a common goal. People are still too anxious to talk face to face about whatever elephant is in the room. So problems continue to fester and grow – and before long, people lose motivation and resentment brews. Teams disintegrate and people leave.

Amber Vandenburg, director of human resources at Paradigm Shift, mentioned the importance of ownership for high-performing teams:

Leaders can foster high performing teams by providing more opportunities for ownership. Opportunities for ownership provide more space for innovation, creativity, experiments, and conversation, rather than complacency. I believe that in every industry and team there are opportunities for ownership in our processes, methods, projects, or roles. It is only when we trust our teams and empower them to take ownership that they can truly perform at their highest level.

Teams consist of individuals who can be motivated in different ways. Jurgen Appelo, CEO at Happy Melly, and Kate Wardin, Sr. engineering manager at Target & founder of Developer First leadership, both explained why understanding such differences matters for leaders:

Jurgen Appelo: Leaders should figure out what motivates people and makes them happy. Engaged and satisfied team members are more productive, more eager to solve problems, and more creative at finding innovative solutions.

Kate Wardin: As leaders, we need to work to understand how each individual on our team derives meaning from their work. This enables us to effectively motivate and inspire team members and the collective team to reach their full potential. I also believe that diverse and inclusive teams are essential to the productivity and happiness of a team

Appelo suggested that leaders should be an example for their teams and take action to increase motivation:

Literally thousands of practices are available to achieve motivation and happiness. It doesn’t matter where you begin. Just do something and lead by example. I started by inviting teams to my home for collaborative cooking, by sharing vacation photos with each other during lunch breaks, and by always being open and honest about what was great and what sucked and needed improvement. When team members see leaders actually lead, they will follow.

In this digital era, communication is being done more and more using chat tools or collaboration environments. Tez reminded us that leaders should also remain in direct contact with their employees:

Leaders need to start having much more powerful and meaningful conversations with everyone in the room. Move away from that computer, stop the incessant digital conversation, and actually talk to people face to face – have meaningful conversations. Ask your employees open questions, find out what’s working and what problems they have – individually and as a team. And attack the problem, never the person.

Article originally posted on InfoQ. Visit InfoQ

Maja Wichrowska and Tae Kim, engineers at Airbnb, explained how Airbnb’s design system evolved its architecture and implementation in response to the business and technical challenges encountered.

Airbnb’s design system is driven by UX and product needs. In 2016, Airbnb Experiences were introduced publicly, and Airbnb applications and sites moved their focus away from just accomodations to the whole end-to-end trip. At the time, the Airbnb codebase was suffering from three technical challenges, enumerated by Wichrowska as fragmentation, complexity and performance.

The fragmentation resulted from engineers using any framework or library they were most familiar with. That meant a mix of JavaScript, CoffeeScript, jQuery, React, CSS, Sass and more. The complexity was driven by the growth of the codebase and the styling needs. Engineers were continually adding CSS files to override existing files. Wichrowska gave the following example of CSS files used to style buttons:

core.scss

.button {
  background: #ff5a5f;
  color: #ffffff
}

custom_page.scss

.button {
  background: #008489;
}

yet_another_custom_page.scss

.button {
  background: #a61d55;
  padding: 1px 1px;
          display: block
}

The root cause behind the additive behaviour is that it was difficult to track whether a CSS selector was still used by some part of the codebase, The problem was particularly acute when it came to positioning and layout. Removing existing selectors or files could result in changing the page appearance in unpredictable ways, and tracking down the culprit selector after the fact could be an arduous task. Keeping the unused CSS led to growing bundle sizes which in turn eventually led to slow page loading, in a way that performance became a key worry.

The fragmentation pain point was addressed by using only React for UI and component concerns. A Design Language System (DLS) was refined. The customization of components was achieved through components’ public interface (props in the case of React). Consistency and predictability were achieved by requiring style customizations to be expressed by props. A button with an alpaca color would for instance require a isAlpaca prop rather than a style or className prop which could be freely customized.

Kim additionally explained that CSS-in-JS, by tightly coupling the component’s CSS to the component’s markup, solved the maintainability issues previously encountered. CSS-in-JS prevented style overrides, enabled theming and allowed shipping only critical CSS through a combination of lazy loading and tree shaking. This helped considerably with complexity and performance issues. As an Airbnb engineer expressed at the time, praising the DLS:

Consistency and reusability with things like responsiveness and reusability all taken care of. DLS is definitely the way forward.

Fast-forward to 2018. As the DLS adoption grew, and the range of Airbnb businesses continued to grow, pain points became more apparent. In 2018, the product portfolio has increased considerably, including new tiers of accommodation with market-specific branding, expanding into business travel, concierge services, peer spaces, and more. Those new products required their own layout, typography, use of images and more.

Fragmentation reappeared. As the DLS required being updated to include new style-customizing props, every update potentially meant going through a lengthy process of deciding whether the extra prop actually fit into the DLS in the first place and whether it followed the DLS guidelines. When pressed with incoming deadlines, engineers would, rather than resort to the design system’s components, quickly write their own components, defeating the point of the design system in the first place. As a result, Kim witnessed the same component being written over and over because that was the more productive thing to do. This lowered consistency and predictability of components, when it comes to styling, but also accessibility.

Furthermore, as developers added customizing props to components, the component code base grew and featured convoluted, unwieldy logic. Kim mentioned that the button component over time grew from 1 Kb to 33 Kb minified, not including external libraries and with no tree-shaking possible. Kim exclaimed:

This is a big number for a button.

Kim also scrolled through the <button> component codebase, which featured 30+ props in its public interface, each prop having in its configuration complexity. The ability to customize components was thus creating implementation, documentation, usage and maintainability challenges. The complexity and performance pain points, previously solved in 2016, were surfacing anew.

In a subsequent iteration, Airbnb’s design system moved to a monochromatic design, making it easy for instance for different Airbnb businesses to add their own palette and differentiate themselves through the use of color. The design system also adopted a modular architecture (as favored by React) and a base + variant pattern. The base + variant pattern consisted in isolating the core parts of a component that are not subject to change from the parts that are open to customization. This translated in a component file implementing the core behavior, structure and appearance of a component (like accessibility or default styling). The base component could later be extended for customization purposes, for example modifying the appearance of the base component. A customized component however does not allow style overrides, beyond those that it already implements.

The Airbnb <button> core component thus featured callbacks to customize behavior (onClick, onHover props), and structural placeholders for components trailing or following the button’s label (renderLeading, renderTrailing props). A primary button is implemented in a primaryButton.jsx file. A secondary button is implemented in a secondaryButton.jsx file. Both primary and secondary buttons extend the base button, implemented in a baseButton.jsx file.

The chosen approach restores the capability of customizing a component behavior with the full flexibility of the JavaScript language, rather than being constrained to a hard-to-changeprop interface. At the same time, while base components can be freely extended, constraints are imposed on variant components (no overrides), ensuring consistency and predictability. The chosen approach reduces the bundle size as developers only need to import the component which they use, and do not pay a bundle-size tax for features that they do not use.

The full talk is available on ReactConf’s site and contains further code snippets and detailed explanations. React Conf is the official Facebook React event. React Conf was held in 2019 in Henderson, Nevada, on October 24 & 25.

Article originally posted on InfoQ. Visit InfoQ

Michael Shilman, a key Storybook contributor, recently announced the release of Storybook 5.3. The new version of Storybook strives to allow developers to build production design systems faster. Storybook users can now document their components with MDX, have a documentation site automatically generated, and integrate with popular design tools like Sketch, Figma, Adobe XD and more. Storybook 5.3 also now officially supports web components.

Shilman explained in Storybook 5.3’s release note the motivation behind the recent evolution of Storybook:

Storybook began with a simple goal: help developers build UI components and their key states.
(…)
In 2020, it’s not enough to provide great tooling for building and testing components. Today’s modern frontend teams also need to document and package their components into reusable design systems.

Users of the new Storybook can now write stories and docs in MDX. Towards that goal, Storybook 5.2 included the DocsPage tool to auto-generate documentation from existing stories. Storybook 5.3 goes a step further and allows developers to write fully customized documentation. Shilman explained:

MDX enables you to customize Storybook’s auto-generated documentation with your own components, mix & match DocBlocks, and loop in non-technical teammates.

The recently open-sourced ING design system is an example of design system whose documentation relies on Storybook’s documentation features. The displayed documentation for the Tabs component originates from a 20-lea-tabs.stories.mdx .mdx file whose first lines are as follows:

import '../lea-tabs.js';
import '../lea-tab.js';
import '../lea-tab-panel.js';

<Meta title="Intro/Tabs Example" parameters={{ component: 'lea-tabs' }} />

# lea Tabs

> This is not a real implementation!
>
> It is an example of how you can reuse the functionality of Lion to create your own Style System

`lea-tabs` implements tabs view to allow users to quickly move between a small number of equally important views.

<Preview>
  <Story name="default">
    {html`
      <lea-tabs>
        <lea-tab slot="tab">Info</lea-tab>
        <lea-tab-panel slot="panel">
          Info page with lots of information about us.
        </lea-tab-panel>
        <lea-tab slot="tab">Work</lea-tab>
        <lea-tab-panel slot="panel">
          Work page that showcases our work.
        </lea-tab-panel>
      </lea-tabs>
    `}
  </Story>
</Preview>

## How to use

### Installation

(...)

Storybook 5.3’s Storybook Docs currently covers Vue, Angular, Ember, and Web components, with more frameworks planned in the future, as Storybook Docs strives to be a universal tool for UI docs.

Storybook 5.3 also shipped with new ways to connect Storybook with external design tools through an ecosystem of addons. Shilman praised the extension of the current ecosystem of addons:

First, InVision built Storybook support into Design System Manager. Now, there’s an addon for every major design tool, including Sketch, Figma, Abstract, and Adobe XD.

Storybook 5.3 now officially supports web components through the new @storybook/web-components package. The latter package strives to provide isolated component development and documentation for all web components projects, and follows the Open-WC recommendations.

The learnstorybook.com website serves as extensive documentation for the design-system-related features of Storybook. The site includes specific parts dealing with design systems workflow, documentation and distribution, in addition to the traditional section on isolated component testing. Documentation for the new @storybook/web-components package is available in the GitHub repository.

Storybook is used by front-end development teams at Airbnb, Lyft, Slack, Twitter, and more companies. It is used to build design systems like Shopify Polaris, IBM Carbon, Salesforce Lightning and more. Storybook supports popular frameworks like React, Vue, Svelte, Ember, Angular, React Native and more. Storybook also supports web components and vanilla HTML. Storybook is localized in 5 languages.

Storybook is available under the MIT open-source license. Contributions are welcome via the Storybook GitHub project and should follow Storybook’s contribution guidelines and code of conduct.

Article originally posted on InfoQ. Visit InfoQ

OpsRamp, a SaaS platform for hybrid infrastructure discovery, monitoring, management and automation has launched OpsQ Recommend Mode, a capability for incident remediation. OpsQ Recommend Mode provides predictive analytics to digital operations teams with the goal of reducing mean-time-to-resolution (MTTR).

OpsQ is OpsRamp’s event management, alert correlation, and remediation engine. New AIOps capabilities help teams ingest, analyse and extract insights for event and incident management. The OpsQ Bot works with the new Recommend Mode with auto-suggested actions alongside alert escalation policies. Other new artificial intelligence for IT operations (AIOps) capabilities in the release include visualisation of alert similarity patterns and new alert stats widgets to provide transparency into machine learning-driven decisions.

The alert seasonality patterns feature in OpsQ can learn which environment alerts recur at a predictable frequency (a seasonality pattern) and automatically suppress them. Teams can visualise seasonality patterns that OpsQ has learned which helps them understand the auto-suppress decisions that OpsQ makes and trace recurring alert patterns to underlying activity. The new Alert Stats widget shows the total number of raw events, correlated alerts, inference alerts, auto-ticketed alerts, and auto-suppressed alerts handled by the OpsQ event management engine. This widget shows how OpsRamp OpsQ reduces event volume at each stage so that IT teams can build confidence in machine learning-based techniques for alert optimisation.

The release drives full-stack visibility for multi-cloud workloads with nineteen new cloud monitoring integrations (added to the existing one hundred and twenty) including: AWS Transit Gateway, AppSync, CloudSearch, and DocumentDB, Azure Application Insights, Traffic Manager, Virtual Network, Route Table, Virtual Machine Scale Sets, SQL Elastic Pool, and Service Bus, GCP  Cloud BigTable, Cloud Composer, Cloud Filestore, Firebase, Cloud Memorystore for Redis, Cloud Run, Cloud TPU and Cloud Tasks. In addition to AWS cloud topology maps, OpsRamp now offers topology discovery and mapping for Azure and GCP. Teams can apply cloud topology maps to analyse the impact of changes in their multi-cloud environments. Cloud topology is also applied in OpsQ’s event correlation engine to increase the accuracy of machine learning models.

OpsRamp offers agentless discovery for Linux and VMware compute, network, and storage resources, and the new release introduces agentless discovery and monitoring for Windows compute resources. OpsRamp’s enhanced synthetic monitoring provides insights and analysis for troubleshooting multi-step transactions. Application owners can break down each synthetic transaction and gain visibility into the performance of each step in a web transaction. InfoQ spoke with Michael Fisher, product manager at OpsRamp, about the new release.

InfoQ: What are some examples of typical seasonality patterns teams experience?

Fisher: Seasonality patterns are frequently rooted in human routines. These routines are generally expressed in daily, weekly, monthly or yearly patterns. For our customers, the most common patterns generally express a daily or weekly pattern. For example, they might see high spikes in network traffic when their end users login to the network in the morning, or  increased disk read/writes when they are performing their weekly backup jobs on their virtual machines. OpsRamp has the ability to learn these seasonal patterns and suppress alerts that occur seasonally, thus reducing false-positive alerts and alert fatigue.

InfoQ: How does OpsRamp provide insights to Kubernetes, containers and microservices?

Fisher: OpsRamp has a variety of different mechanisms to provide insight into Kubernetes environments. Native Kubernetes instrumentation allows teams to gain insight into the overall health of the cluster down to the individual container runtimes. This monitoring visibility is coupled with our Kubernetes Topology, which maps the cluster to the nodes, to the containers. This topological context is fed into our machine learning models to enhance correlation and alert deduplication, which aids Site Reliability Engineers (SREs) when troubleshooting Kubernetes related events.

InfoQ: How does OpsRamp handle security related incidents?

Fisher: OpsRamp provides the capability to monitor common firewall, or security centric hardware, for its overall health and performance. On top of this, OpsRamp has a generic web-hook API framework which can be leveraged to ingest security events from various vendors, which are fed through OpsRamp’s correlation models for further analysis.

InfoQ: Does OpsRamp have any features that help teams perform blameless retrospectives post incident?

Fisher: OpsRamp’s native help desk, dashboarding and reporting allow teams to track the lifecycle of an incident as it moves from incident creation, to incident resolution.

InfoQ: If a team has a “we build it, we own it&” mentality, how might this change the way in which OpsRamp is used?

Fisher: As an extensible platform, teams that seek to build their own custom monitoring, or integrations, are encouraged to do so. The strength in the OpsRamp platform is not only what we provide out of the box, but what we enable teams to do with the tools that we provide.

InfoQ: Can teams extract business metrics relating to web based customer journeys from the tool?

Fisher: OpsRamp provides various different synthetic offerings, from monitoring the round trip time (RTT) between an SMTP server and OpsRamp’s globally located data-centres, to creating a synthetic transaction modelling a user’s flow within your application. These various synthetic options provide businesses with visibility into their critical applications whilst helping them stay ahead outages that may affect their end users’ experience.

InfoQ: What is a machine learning model?

Fisher: For OpsRamp, a machine learning model represents OpsRamp’s ability to ingest data and then interpret it using various different features, such as topology relationships, resource attributes, time, etc. OpsRamp has several different models, each with a different intended purpose and degree of automation. For example, OpsRamp’s new recommend mode provides businesses with the ability to stay informed of the machine learning model’s action (“analyst in the loop”) and be the final decision maker if, for example, an alert should be suppressed or turned into an incident. Recommend provides an opinion on how to handle alerts, but leaves it to the operator to “push-the-button”, providing a blend of automated response and operator control.

InfoQ: How does OpsRamp perform topology discovery and visualisation?

Fisher: OpsRamp’s topology discovery spans from L2 – L7. At the bottom of the stack, OpsRamp leverages various discovery protocols (such as CDP, LLDP, OSPF etc) to map the relationships between infrastructure components. Moving up the stack, OpsRamp is also able to model business applications, public cloud services and Kubernetes workloads. In addition to the ability to visualise these services, OpsRamp’s machine learning models are able to train from the discovered relationship data to more accurately correlate and deduplicate alerts, which can reduct alert fatigue and MTTR for operators.

Learn more about the OpsRamp Winter 2020 release here.

Article originally posted on InfoQ. Visit InfoQ

PyTorch, Facebook’s open-source deep-learning framework, announced the release of version 1.4. This release, which will be the last version to support Python 2, includes improvements to distributed training and mobile inference and introduces support for Java.

This release follows the recent announcements and presentations at the 2019 Conference on Neural Information Processing Systems (NeurIPS) in December. For training large models, the release includes a distributed framework to support model-parallel training across multiple GPUs. Improvements to PyTorch Mobile allow developers to customize their build scripts, which can greatly reduce the storage required by models. Building on the Android interface for PyTorch Mobile, the release includes experimental Java bindings for using TorchScript models to perform inference. PyTorch also supports Python and C++; this release will be the last that supports Python 2 and C++ 11. According to the release notes:

The release contains over 1,500 commits and a significant amount of effort in areas spanning existing areas like JIT, ONNX, Distributed, Performance and Eager Frontend Improvements and improvements to experimental areas like mobile and quantization.

Recent trends in deep-learning research, particularly in natural-language processing (NLP), have produced larger and more complex models such as RoBERTa, with hundreds of millions of parameters. These models are too large to fit within the memory of a single GPU, but a technique called model-parallel training allows different subsets of the parameters of the model to be handled by different GPUs. Previous versions of PyTorch have supported single-machine model parallel, which requires that all the GPUs used for training be hosted in the same machine. By contrast, PyTorch 1.4 introduces a distributed remote procedure call (RPC) system which supports model-parallel training across many machines.

After a model is trained, it must be deployed and used for inference or prediction. Because many applications are deployed on mobile devices with limited compute, memory, and storage resources, the large models often cannot be deployed as-is. PyTorch 1.3 introduced PyTorch Mobile and TorchScript, which aimed to shorten end-to-end development cycle time by supporting the same APIs across different platforms, eliminating the need to export models to a mobile framework such as Caffe2. The 1.4 release allows developers to customize their build packages to only include the PyTorch operators needed by their models. The PyTorch team reports that customized packages can be “40% to 50% smaller than the prebuilt PyTorch mobile library.” With the new Java bindings, developers can invoke TorchScript models directly from Java code; previous versions only supported Python and C++. The Java bindings are only available on Linux.

Although rival deep-learning framework TensorFlow ranks as the leading choice for commercial applications, PyTorch has the lead in the research community. At the 2019 NeurIPS conference in December, PyTorch was used in 70% of the papers presented which cited a framework. Recently, both Preferred Networks, Inc (PFN) and research consortium OpenAI annouced moves to PyTorch. OpenAI claimed that “switching to PyTorch decreased our iteration time on research ideas in generative modeling from weeks to days.” In a discussion thread about the announcement, a user on Hacker News noted:

At work, we switched over from TensorFlow to PyTorch when 1.0 was released, both for R&D and production… and our productivity and happiness with PyTorch noticeably, significantly improved.

The PyTorch source code and release notes for version 1.4 are available on GitHub.
 

Article originally posted on InfoQ. Visit InfoQ

The United States Department of Justice has identified and charged four members of the Chinese military with hacking Equifax to steal private data on over 145 million individuals. The information theft had previously been suspected of being a state actor, as the information has not been located for sale on the dark web.

China has since denied responsibility over the attack through foreign ministry spokesperson Geng Shuang, “The Chinese government, military and relevant personnel never engage in cyber theft of trade secrets.”

A crucial distinction for developers and architects is that attribution often does not matter. Once an application is hacked and data is stolen, that data is gone, and the organization that was hacked is financially responsible for any clean-up. The primary areas of focus for software are on detection, knowing when/where security issues or CVEs are, and prevention, to protect and/or patch those security issues.

The hacking quartet had allegedly previously compromised Equifax through their failure to identify and patch a known vulnerability in the Apache Struts library. By failing to update the library in the running application, hackers were able to access the system and move laterally across other environments and ultimately exfiltrate the information. The Apache Software Foundation issued an official statement about the availability of their security patch combined with the failure to utilize the fix, the included recommendations for other organizations who do not wish to be hacked:

• Understand which supporting frameworks and libraries are used in your software products and in which versions. Keep track of security announcements affecting these products and versions.
• Establish a process to quickly roll out a security fix release of your software product once supporting frameworks or libraries needs to be updated for security reasons. Best is to think in terms of hours or a few days, not weeks or months. Most breaches we become aware of are caused by failure to update software components that are known to be vulnerable for months or even years.

Two sets of tools exist that help development teams identify where these types of vulnerabilities exist in their code. By using both tools, Software Composition Analysis, and Runtime Application Self Protection, development teams can more quickly identify flaws and roll out updates to minimize the window of exposure for vulnerabilities. The four members of China’s military leveraged their heist in the window when the vulnerability became known:

• CVE-2017-5638 was publicly disclosed on March 10, 2017.
• The breach occurred in May, approximately three months after public disclosure.
• Equifax discovered the breach towards the end of July.
• Official statements were released by Equifax and Apache in September.

If the application using the insecure library had been patched following the vulnerability disclosure, this attack would not have worked and determined hackers would have required more effort to locate a different vulnerable path.

Software Composition Analysis (SCA) is a technique that helps teams track where different libraries are used and where CVEs are located. As new vulnerabilities are discovered, these systems will leverage this information to pinpoint which applications need to update which libraries in order to avoid exploitation. Development teams can then update the application’s libraries and roll a patched version into production, typically through CI/CD controls.

The other technique, Runtime Application Self Protection (RASP), offers a mitigating control for organizations that maintain a defense or cannot upgrade the software in a timely manner. Unlike traditional Web Application Firewall (WAF) defenses that are unaware of what they defend, RASP works inside the application to defend APIs with context of what it is defending. Whereas many techniques can bypass WAFs, attacks such as the deserialization work of CVE-2017-5638 are not typically caught by WAFs. Deserialization attacks work by exploiting the object hierarchy and making the runtime execute arbitrary code as part of deserializing the object. While the particular payload used in Equifax is undisclosed, many attackers use tools such as ysoserial or ysoserial.net, as well as GadgetProbe to execute arbitrary commands against Java and .NET applications that deserialize user input. Rather than relying on layer 7 network signatures of an unknown class hierarchy, RASP uses techniques such as instrumentation to monitor inside APIs as data is being deserialized, trapping sensitive methods at the method entry point before the body executes.

Although charges have been filed, it is unclear what the result will be as China does not have an extradition treaty with the United States.

Article originally posted on InfoQ. Visit InfoQ

Subscribe on:

Apple Podcasts Google Podcasts Soundcloud Spotify Overcast RSS Feed

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Article originally posted on InfoQ. Visit InfoQ

John Hughes, co-designer of Haskell and Quickcheck, recently discussed property-based testing at Lambda Days 2020. Hughes presented in his talk five different strategies for coming up with properties and compared their effectiveness. Metamorphic and model-based properties reportedly show high effectiveness.

Hughes first discussed a common problem faced by developers using property-based testing (PBT) to test pure functions. With example-based testing, the expected output of the function under test can be computed ahead of time and compared to the actual output of the function. Property-based testing, however, typically generates semi-randomly a large number of test sequences. Computing the expected outputs of the function under test for a large set of values that are not known ahead of time is not easier than implementing the function in the first place. This challenge is called the test oracle problem and is described by Prof. Tsong Yueh Chen as follows:

The oracle problem refers to situations where it is extremely difficult, or impossible, to verify the test result of a given test case

Developers may end up replicating the original code in the tests, and as such introducing the same bugs in the testing code than in the tested code.

To solve this conundrum, Hughes recommended identifying and checking properties of the output of the function under test. One such property for the reverse function, which takes a list and returns the list in reverse, is:

reverse (reverse xs) === xs

The challenges now turn to finding a good-enough set of properties which allows developers to either find bugs, or ensure the correctness of the function implementation. Hughes demonstrated that using only one property was often not enough by giving the following erroneous `reverse` implementation:

reverse xs = xs

Hughes thus proceeded to give 5 systematic ways of generating properties and analyzed their effectiveness. The first method consists in identifying invariants of the function under test. To illustrate that method, Hughes considered a binary search tree (BST) data structure, endowed with the operations find, insert, delete, union. Such data structure has the property that the insertion of a key/value pair in a valid tree results in a valid tree. The same applies to the other deletion and union operations. A tree itself is considered valid if it adheres to the contracts of the binary search tree (in particular those referring to the ordering of keys).

The second method consists of finding a postcondition verified by the output of the function under test. For instance, Hughes gave the following post-condition for the BST’s find operation:

After calling insert, we should be able to find the key inserted, and any other keys present beforehand.

The third method relies on metamorphic properties. Metamorphic properties relate the outputs produced by the system under test when fed related inputs. Hughes gave the following metamorphic property for the BST’s insert operation:

insert k v (insert k' v' t)
===
insert k' v' (insert k v t)

The previous property simply means that the resulting tree from inserting two key/value pairs does not depend on the order of the insertions. Metamorphic testing is an active research area. A thorough examination of the technique can be found in Prof. Tsong Yueh Chen’s Metamorphic testing: A review of challenges and opportunities paper.

The fourth method is based on what Hughes termed inductive properties. Scott Wlaschin, senior software architect, explained in one of his talk on PBT:

These kinds of properties are based on structural induction – that is, if a large thing can be broken into smaller parts, and some property is true for these smaller parts, then you can often prove that the property is true for a large thing as well.
(…)
Induction properties are often naturally applicable to recursive structures such as lists and trees.

Hughes gave the following inductive property for the BST:

union nil t ==== t
union (insert k v t) t'
=~= 
insert k v (union t t')

In other words, a union operation on a tree can be related to a union operation on a smaller tree. By induction on the size of the tree, it can be shown that the only function satisfying those properties is the correct union operation of the BST. Inductive properties are often themselves metamorphic properties with the peculiarity that they form a complete specification, being linked to inductive proofs.

The fifth method relies on model-based properties. This implies the existence of a model of the system under test. In the BST’s case, a simple model is the list of key values stored in the tree, as obtained by traversing the tree data structure. Operations on the system under test translate into operations on the model. Checking properties of the data structures translate into checking properties on the model, with the idea that the latter checking is significantly simpler or easier to perform reliably.

To assess the effectiveness of the identified properties, Hughes introduced bugs in every operation of a correct BST implementation and counted the bugs found by each property generation method:

The model-based properties reach 100% effectiveness and are the closest thing to having an oracle for the system under test. The model acts as a simplified version of the system under test for which an oracle is available. Metamorphic properties are also very effective in finding bugs. This is in line with results stemming from different industries. As related in Metamorphic Testing: A Review of Challenges and Opportunities, a major feat of metamorphic testing is finding 100+ new bugs in two popular C compilers (GCC and LLVM).

Hughes appropriately concluded in the paper associated with his talk:

These results suggest that, if time is limited, then writing model-based properties may offer the best return on investment, in combination with validity properties to ensure we don’t encounter confusing failures caused by invalid data. In situations where the model is complex (and thus expensive) to define, or where the model resembles the implementation so closely that the same bugs are likely in each, then metamorphic properties offer an effective alternative, at the cost of writing many more properties.

The full video recorded at Lambda Days 2020 is available online. Lambda Days is a developer conference focusing on functional programming methods and techniques. Lambda Days 2020 was held on the 13th and 14th of February 2020 in Kraków, Poland.