devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

  • The Argo Project: Making GitOps Practical

    The Argo Project: Making GitOps Practical

    If you’re a DevOps engineer, chances are you have at least heard the name “Argo,” seen the friendly squid logo, and wondered: What the heck is this tool everyone is talking about? 

    In a nutshell, Argo is a popular open source tool that is making GitOps practical for anyone who uses Kubernetes. But it’s much more than that because, by enabling GitOps, Argo will also make Kubernetes environments more robust, secure and reliable than ever before. 

    Let’s find out why the combination of Argo, GitOps and good DevOps engineers is a recipe for production panacea.

    What is GitOps and Will it Replace DevOps?

    GitOps is a new(er) process and paradigm used by development teams to manage infrastructure and deploy applications. The “Git” in GitOps refers to the popular open source version control system. GitOps uses Git as a single source of information for declarative configuration. Based on this declarative configuration, it works its magic.

    GitOps automatically manages the configuration and deployment of infrastructure using Git pull requests. When development teams make a change to Git configuration, a GitOps agent deployed in the environment automatically reconciles the changes with the live state. Every change to the live environment is captured in the Git repository, so teams have unprecedented visibility and auditability over system changes. Most importantly, it is trivial to roll back to a previous working version in case of fires in production.

    GitOps builds on the developer experience, enabling teams to manage their infrastructure using the same tools and processes they use to develop software, extending those tools to the realm of software deployment and infrastructure management.

    While some have touted GitOps as “DevOps 2.0”, many experts disagree, saying that GitOps is not a better version of DevOps, nor is it something that will replace DevOps altogether. GitOps is a technical practice that can be highly beneficial to DevOps teams. The DevOps engineer will not, as some fear, be replaced by a Git-triggered robot. But GitOps will make her and the developers she supports happier and more productive.

    What is the Argo Project?

    Argo is an open source project hosted by the Cloud Native Computing Foundation (CNCF) for building and managing continuous delivery workflows in Kubernetes, GitOps style. The unique aspect of Argo is that it is Kubernetes-native—designed from the ground up for a modern containerized environment.

    The Argo project consists of four main sub-projects:

    • Argo CD—A GitOps continuous delivery engine with a powerful GUI and CLI.
    • Argo Workflows—A workflow engine that supports workflows and directed acyclic graphs (DAGs) in which each process stage is a container.
    • Argo Rollouts—An advanced Kubernetes deployment engine that supports progressive delivery strategies like canary and blue/green deployments, which are difficult to implement in plain Kubernetes.
    • Argo Events—A Kubernetes event-based dependency management system, which can be used to trigger automated workflows in CI/CD pipelines.

    Requirements for Kubernetes in Production

    Kubernetes is an orchestration platform that can help deploy, scale, and manage containerized applications. It can manage containers and the underlying infrastructure—scheduling containers and managing their workloads. This capability integrates software development and platform management to improve application management and portability. 

    Kubernetes in production can offer many advantages. For example, it makes it possible to release frequent changes to a high-availability application while keeping them online and enables you to move applications from one cluster to another. However, you need to configure Kubernetes correctly to realize its potential.

    Configuring Kubernetes for production involves implementing requirements according to each use case. As a result, what constitutes “production ready” in one Kubernetes project may vary greatly between different use cases. However, there are still minimum requirements that should be applied to most use cases. Here are key requirements for Kubernetes in production:

    • Security—When securing Kubernetes for production, you need to minimize the attack surface. This means locking down the Kubernetes control plane, applications, and their associated data. You need to keep secrets secured, harden nodes, use role-based access control (RBAC), and keep your Kubernetes version up-to-date with the latest security updates.
    • Portability and scalability—You can maximize cluster performance by maintaining portability and scalability. There are many Kubernetes capabilities that can help you achieve this goal, including self-healing nodes and auto scaling the infrastructure.
    • Deployment velocity—Kubernetes makes infrastructure and applications management faster by automating related processes. You can use Kubernetes’ automated features with GitOps to increase deployment velocity across your CI/CD pipelines.
    • Disaster recovery—You can significantly minimize your mean time to recovery (MTTR) by using Kubernetes and GitOps together. GitOps can help you reduce MTTR to minutes and quickly and easily recreate your container infrastructure in case of a complete cluster meltdown. 
    • Persistence—To support stateful production applications you will need to configure Kubernetes persistent volumes, provision storage devices with multiple storage tiers, and ensure they are efficiently utilized.
    • Observability—Observability enables you to gain a high-level view into running services, helping you make informed decisions before deployment to mitigate risk. GitOps can help you continuously monitor Kubernetes deployments, ensuring you can act immediately when issues occur.

    Benefits of Argo Tools for Production Environments

    Argo CD

    Argo CD is a continuous delivery (CD) tool native to Kubernetes. While most CD tools only support push-based deployment, Argo CD works in pull mode, retrieving updated code from a Git repository and deploying it directly to Kubernetes resources. This allows developers to manage infrastructure configuration and application updates in one system.

    Argo CD key features include:

    • Automatically synchronizing application state in a Kubernetes cluster with the current version of declarative configuration in a Git repository (==GitOps).
    • Ability to visualize deployment issues and detect and fix misconfigurations.
    • Convenient web-based GUI and CLI.
    • Role-Based Access Control (RBAC) and single sign-on (SSO), including login via GitHub, LinkedIn, Microsoft, etc.
    • Support for webhooks triggering actions in GitLab, GitHub, and BitBucket.

    How does Argo CD make Kubernetes production ready?

    GitOps can help you achieve a true GitOps workflows in Kubernetes, which provides the following benefits in production environments:

    • Minimize failed deployments and rapidly recover from downtime—Argo CD lets you instantly revert and rollback easily if anything goes wrong in production, reducing recovery time to seconds. 
    • Built-in auditing history—Argo CD ensures that every change to a Kubernetes cluster ia audited in the form of a Git configuration change log. This provides a complete audit trail of who changed what in the cluster, enabling consistent operations and supporting compliance requirements. 
    • Greater visibility on the lifecycle of developed features—Argo CD provides traceability from every change to infrastructure or applications directly to the code commit that caused those changes.
    • Improved security—Argo CD provides strong security guarantees, leveraging strong cryptography to manage changes and verify authorship, and creating a complete separation between CI environments and production systems, eliminating many types of supply chain attacks.

    Argo Rollouts

    Argo Rollouts is a set of Kubernetes controllers and CRDs that provides advanced deployment features such as blue/green and canary deployments, experiments, and progressive delivery in Kubernetes environments. It can integrate with input controllers and service meshes to incrementally transition traffic to new versions during updates. 

    A key capability of Argo Rollouts is that it can query and interpret metrics from many sources to validate that a deployment works properly and perform automatic upgrades or rollbacks.

    How do Argo Rollouts make Kubernetes production ready?

    By default, Kubernetes provides the Deployment object which updates applications using the “rolling update” strategy. In large production environments, rolling updates are considered too risky because there is no control over rollout speed and no way to automatically roll back in case of failure.

    Another limitation is that out of the box, Kubernetes deployments cannot query external metrics, such as real user measurements of performance or engagement, to determine the success of a deployment. 

    Argo Rollouts can address all these challenges and enable full progressive delivery in a Kubernetes environment, without requiring complex configuration.

    Argo Workflows

    Argo Workflows is an open source container-native workflow engine for orchestrating parallel tasks on Kubernetes. Argo workflows are implemented as Kubernetes Custom Resource Definitions (CRDs).

    Key features of Argo Workflows include:

    • Defining workflows where each step in the workflow is a container.
    • Modeling multi-step workflows as sets of actions or DAGs to capture dependencies.
    • Running CI/CD pipelines natively on Kubernetes without configuring complex software development products.

    How do Argo Workflows make Kubernetes production ready?

    Argo Workflows lets you automate production workflows in any Kubernetes environment, whether on-premises, hybrid cloud, or multi-cloud. It eliminates manual processes and ensures automation is represented as declarative configuration, making it consistent, repeatable, easy to rollback, and easy to troubleshoot.

    Argo Events

    Argo Events is a Kubernetes event-based dependency manager that defines multiple dependencies for different event sources (e.g. webhook, S3, schedule, stream, etc.) and Kubernetes objects after event dependencies are successfully resolved. Help the trigger.

    Argo events by themselves are not very useful. To deliver value, you need to integrate with a system that can execute workflow steps. So you can use Argo workflows to set Argo events. This helps orchestrate parallel Kubernetes jobs.

    How do Argo Events make Kubernetes production-ready?

    Argo Events provides several capabilities that enable dependency management in production Kubernetes environment:

    • Manage dependencies for various event sources.
    • Ability to customize business-level constraint logic to resolve event dependencies.
    • Manage everything from simple linear real-time dependencies to complex multi-source batch job dependencies.
    • Compliance with the CloudEvents standard.
    • Ability to manage event sources at runtime.

    Conclusion

    In this article, I covered the basics of GitOps and the Argo project and showed how each of the Argo project’s key modules can help make Kubernetes production-ready with minimal effort from developers and DevOps engineers. The magic of Argo is its simplicity and the way it fits seamlessly into existing Kubernetes workflows. I hope this will encourage you to try it out and see if it can help with your organization’s production issues.

  • FusionAuth Adds Support for ARM-Based Architecture

    FusionAuth Adds Support for ARM-Based Architecture

    Most developers need three things in life: Control, interesting projects and the ability to build on the technology of their choice. Now a new development promises to put all three in developers’ hands—FusionAuth’s announcement of its support for ARM-based architecture.

    FusionAuth solutions offer multi-factor authentication, passwordless authentication and single sign-on, among other features. ARM-based architectures offer simplicity with a lower and cooler energy footprint. Translated into DevSecOps benefits, this means that FusionAuth just made it significantly easier for developers to meet identity and authorization requirements and strengthen their security when building on ARM architecture.

    We talked to Daniel DeGroff, co-CTO at FusionAuth, to find out the details on how this support can benefit DevSecOps.

    The Movement to ARM-based Architecture

    You’ve probably noticed many forward-thinking developers are turning toward ARM-based technologies. Developers can count on interoperability across different implementations and different devices—and ARM processors offer a lower operating temperature and reduced power consumption. They’re also inexpensive to produce, making their price point attractive. This has earned them a place in everything from servers to smartphones to the world’s fastest supercomputer.

    With many developers spotting the potential for higher performance and cost savings, it’s no surprise that vendors like FusionAuth would move to support ARM-based infrastructure, as well. By working with ARM processors, the company can support additional use cases such as IoT and high-performance cloud platforms that are built on ARM-based architectures. DeGroff described it as a pragmatic—and inevitable—move, and said, “If you want to use these new machines, you have to support this architecture in some fashion.”

    “We develop on the Apple MacBook, and all new workstations will use Apple’s custom silicon which is based on the ARM architecture,” he pointed out. “ARM is generally faster and less expensive than an equivalent x86 server platform, and many of the low-power IoT devices will utilize the ARM architecture as well.”

    DevSecOps Benefits: Greater Flexibility, Easier Security

    FusionAuth’s ARM support can make the average security-minded dev’s life easier in several ways. FusionAuth runs on any platform, anywhere; by supporting ARM-based technologies, the company is extending developers’ ability to deploy its authentication and authorization platform how and where they want. “We have to ensure FusionAuth runs where our users want to develop,” DeGroff said.

    In helping developers build on ARM-based architecture, FusionAuth also makes it easier for them to use an API to bring in FusionAuth at the early stages of app or software development. One of the platform’s selling points is that it makes it simpler for developers to solve typical authentication obstacles, like weak password policies or difficulty with privileged access rules, DeGroff said. By supporting ARM-based technologies, FusionAuth aims to help developers successfully meet even tough security requirements through flexible, sophisticated identity authentication and access tools—and do so earlier in their development cycles.

    A Seamless Transition to Smarter Authentication

    If you’re a developer interested in exploring the combination of FusionAuth and ARM technologies, DeGroff said any transition will feel seamless. “There is a great business case for moving workloads to this architecture,” he points out. Developers who want to take advantage of the improved performance and lower costs can begin to migrate workloads to ARM-based platforms now.”

     

  • Google Allies With GitHub to Secure Software Supply Chains

    Google Allies With GitHub to Secure Software Supply Chains

    Google today revealed it has been working with GitHub to create a forgery-proof method for signing source code as part of an ongoing effort to better secure software supply chains.

    Bob Callaway, technology lead for open source software supply chain security at Google, said a prototype of this method, written in the Go programming language, generates non-forgeable provenance using GitHub Actions workflows for isolation and code signing tools for authenticity provided by Sigstore. Projects that make use of GitHub runners to run jobs can now achieve the third level of security as defined by the supply chain levels for software artifacts (SLSA) framework to assure software artifacts are authentic and trustworthy, he said.

    The reusable workflow also protects against possible interference from maintainers who could otherwise try to define the workflow in a way that interferes with the builder. The only way to interact with a reusable workflow is through the input parameters it exposes to the calling workflow, which prevents maintainers from altering information via variables, steps, services and defaults.

    The goal is not only to ensure the provenance of individual software artifacts but also make it possible to identify which build system was employed to create that artifact, said Callaway. In addition to working with GitHub, Callaway added that Google expects to apply this method to securing other build systems that organizations used to construct applications.

    Overall, Callaway said, Google is also working toward embedding security functions with DevOps platforms to ensure the integrity of software supply chains, in addition to educating developers on how to build more secure software.

    To protect against the possibility of one job tampering with artifacts used by another job, Google’s method creates a trusted channel. Job outputs send hashes that are then used to verify the binary received via the untrusted artifact registry. The OpenID Connect (OIDC) protocol, which GitHub just opted to support, is then used to prove the identity of the workflow to an external service, such as Sigstore, by attaching a unique JSON web token (JWT) to each runner. The token contains verifiable information about workflow identity such as the caller repository, commit hash, trigger and the current workflow path and reference.

    That makes it possible for the workflow to prove its identity to the  Fulcio root certificate authority provided by Sigstore. Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner. A record of that signing is kept in Sigstore’s transparency log Rekor. Users can then rely on the signing certificates to verify provenance in a way that is authenticated and non-forgeable. That approach means maintainers don’t need to manage or distribute cryptographic keys for signing, which until now have made it challenging to manage code signing at scale, Callaway noted.

    In the wake of a series of high-profile security breaches involving open source software, Google and others have significantly increased the resources being applied to securing both open source and proprietary software within the context of a set of DevSecOps best practices. It may be a while before the benefits of that effort are pervasively employed by developers, but it’s clear that substantial progress is being made involving everything from the tools developers use to the build systems managed by DevOps teams.

  • Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

    Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: No remedy for banned Facebook users, new ARM-based VMs on Microsoft Azure, and The Great Resignation will still be a Thing for the foreseeable. (more…)

  • Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Legit Security today revealed that it discovered a privilege escalation vulnerability in GitHub repositories that has since been remediated.

    Liav Caspi, Legit Security CTO, said the company worked with GitHub to remediate the issue prior to disclosure. Legit Security researchers reported they found hundreds of GitHub instances rated with over 1,000 stars each that could be subject to the vulnerability.

    Caspi said the company also reached out directly to most of those affected sites, including an instance of GitHub that is used to develop the open source Nginx web server that is employed across hundreds of millions of websites.

    Cybercriminals could exploit a vulnerable build script to modify code or built artifacts that would result in software being shipped with code controlled by some other entity. The vulnerability could also enable access to sensitive secrets, such as keys, that are used to access cloud services or simply create a malicious pull request.

    Legit Security researchers employed a set of risk assessment tools that are part of a larger software-as-a-service (SaaS) platform that enables them to apply security policies across their entire software development life cycle. Earlier this year, the company made available a free Rapid Risk Assessment tool to provide organizations with more insights into their software supply chains. Security research findings, along with other security best practices, are embedded within the policies that can be enforced via the Legit Security platform.

    In the wake of a series of high-profile breaches, there is now more focus on the security of software supply chains than ever. Gartner estimated that 45% of organizations worldwide will have experienced attacks on their software supply chains by 2025, a threefold increase from 2021.

    Despite those concerns, however, the rate at which new applications are being deployed and updated doesn’t appear to be slowing. Organizations are too dependent on software to encourage customers to slow down the development and deployment rate of applications. It will, however, take years for organizations to properly train developers to correctly employ security tools within their application development processes, otherwise known as DevSecOps best practices, to reduce the number of vulnerabilities that now routinely manifest themselves in production environments. The only practical alternative is to embed more tools that automatically discover vulnerabilities in code during the application development process.

    Regardless of the DevSecOps approach, the ultimate goal remains to build more secure applications faster. That can only be achieved if there are more guardrails in place that prevent developers from inadvertently introducing vulnerabilities into an application. The more frequently applications are updated, the more likely it is that a vulnerability will be introduced. Each time those vulnerabilities are discovered after an application is deployed in a production environment, the more expensive they are to remediate. As the volume of vulnerabilities increases, it’s also only a matter of time before the sheer number of security issues that need to be addressed overwhelms both developers and security operations teams alike.

    Application security, of course, has not always received the attention it deserves, but demands for increased application security can no longer be ignored.

  • Dagger: Standardizing CI/CD is the Holy Grail of DevOps

    Dagger: Standardizing CI/CD is the Holy Grail of DevOps

    Continuous integration and continuous delivery (CI/CD) has become a hallmark of quick software release life cycles. Nowadays, many teams support CI/CD pipelines for their software, offering a repeatable pathway to build, test and deploy code. A CI/CD pipeline is necessary to support an iterative, rapid deployment approach—yet, maintaining one is not an easy task.

    Enter Dagger. Dagger is a utility that aims to streamline how developers create and manage their CI/CD pipelines. Dagger, led by founders of Docker, recently unveiled their public beta launch along with a Series A $20 million funding raise led by Redpoint Ventures. While many open source CI/CD projects already exist on the market, Dagger is unique in offering easier configurations, pre-built components and more reusable actions.

    Akin to traditional supply chain management, software supply chain management is an increasingly complex endeavor involving many third-party dependencies. Development teams truly require a set of standard building blocks to piece it all together. For this reason, Solomon Hykes, co-founder and chief executive of Dagger, told SiliconANGLE that “solving this problem is the holy grail of DevOps.”

    Below, we’ll look at the common stressors inherent in creating and managing modern software delivery chains. We’ll also take a peek into the Dagger beta to see what it’s attempting to accomplish.

    Issues Facing CI/CD

    Software development supply chains are growing larger and larger to support a complex network of software architectures. But DevOps engineers, who must automate this chain, are drowning in tool sprawl—and stitching these components together to make custom pipelines can become a big bottleneck.

    Especially as an organization expands its distributed microservices architecture into the cloud, it can be tricky to scale a repeatable CI/CD pipeline across various department and disparate tech stacks. This often results in many bespoke CI/CD pipelines. Even within the same team, nuances between codebases can complicate each CI/CD process and require engineers to rewrite scripts.

    Simultaneously, organizations are under intense pressure to deliver to meet new digital innovation demands. But, until DevOps can make the release process more efficient, software development automation risks introducing more toil than it takes away.

    Diving Into Dagger

    So, how is Dagger alleviating these concerns? Well, Dagger creators described it as a “portable devkit for CI/CD pipelines.” Using Dagger, DevOps engineers can use a standard set of building blocks to assemble their CI/CD pipelines and then run them on their chosen cloud. It’s like a better developer experience for CI/CD pipeline creation.

    So, how does Dagger work under the hood? Dagger is powered by Buildkit, the Dockerfile-agnostic builder toolkit. Developers then use Cue to specify how their code is run in a container and to link up actions. Cue is an open source configuration language developed at Google.

    According to the docs, it takes about five minutes to install Dagger and the necessary dependencies. Dagger also provides boilerplate code to integrate with pre-existing CI environments. In essence, Dagger doesn’t need to replace your CI tool—it adds “a portable development layer on top of it.”

    Then, there are the actions themselves. Dagger supports a growing library of actions that it calls Universe. At the time of writing, the Universe of actions is limited and is being staged in the main Dagger repository. These actions are reusable Cue packages. For example, this package details how to run and deploy the Nginx web server in Cue:

    package nginx

import (
    "universe.dagger.io/docker"
)

    And then,

    #Build: {
    output: docker.#Image & _pull.image

    _pull: docker.#Pull
    *{
        flavor: "alpine"
        _pull: source: "index.docker.io/nginx:stable-alpine"
    } | {
        flavor: "debian"
        _pull: source: "index.docker.io/nginx:stable"
    }
}

    Benefits

    CI/CD can certainly benefit from standard building blocks and more fluid wiring between tools. There are several potential benefits from Dagger’s proposition:

    • Unification: Unifying developer and CI environments could avoid headaches.
    • Localization: Dagger enables testing a closed-loop pipeline locally. This helps for debugging.
    • Reusability: Building blocks help avoid rewriting automation scripts repeatedly.
    • Multi-cloud: Easier ability to migrate a pipeline from one cloud to the other, thus avoiding vendor lock-in.
    • Compatability: Dagger can run in any environment compatible with Docker, meaning it’s probably workable with your current toolset.

    Final Thoughts: Lego Blocks For CI/CD

    Docker revolutionized the software industry by easing the process of managing containerized applications. And now, Docker founders Solomon Hykes, Sam Alba, Andrea Luzzardi and others at Dagger are tackling another meaningful problem within today’s complex software ecosystem. Given the success of their previous endeavors, it’s not too difficult to imagine a network of reusable CI configurations emerging with an excitement similar to Docker Hub.

    Of course, Dagger is still in its early stages and there’s much development ahead. It will undoubtedly be an interesting project to follow in the years to come. Dagger is being built as an open source project on GitHub. The company has also opened a Discord channel to engage with the community.

  • Positioning ML Devs and Teams for Success

    Positioning ML Devs and Teams for Success

    Intelligent applications are (by their very nature) complex. While conventional software basically consists of one thing (code), intelligent software involves code, models and data. As previously discussed, three distinct fields—DevOps, MLOps and DataOps—have evolved to govern each of these interconnected disciplines. 

    Moving through the ML life cycle quickly and efficiently requires collaboration between teams in each of the above disciplines. Organizations should strive to make this collaboration as frictionless as possible to position their ML efforts for success. What follows are four places where we believe organizations should focus: 

    • Infrastructure
    • Team structure
    • Tools 
    • Project ownership and KPIs

    Build Dedicated Infrastructure for Each Pillar

    Infrastructure software is not one-size-fits-all across the three pillars of code, model and data. For example, DevOps teams have historically played the infrastructure role in software development, supporting application or product services. Think of regular software engineering teams who are supported by DevOps, producing different kinds of application services. App infrastructure is so baked-in to software development that most of us take it for granted.

    Just as regular software services require DevOps, data and model services require corresponding infrastructure. Data infrastructure is typically concerned with managing tools (such as Airflow installations, Spark clusters and feature stores), building data pipelines and ensuring that data services remain smooth and operational for data consumers. 

    On the other hand, model services are chiefly concerned with creating, running and organizing models in such a way that others can use them efficiently. Since the AI/ML life cycle is incredibly complex, a host of factors need to be considered (e.g., hardware, parallelization libraries, model packaging formats, etc.) to help data scientists and engineers do their jobs efficiently. Robust ML infrastructure along with a dedicated ML infrastructure team goes a long way in helping organizations scale their AI.

    Optimize Team Structure

    Best practices for ML and AI are continuously evolving, and organizations have tried a host of team structures over the years. We have noticed two popular structures for intelligent application development teams emerged in recent years:

    • Pods

    Pod structures involve smaller teams—usually a data scientist, a data engineer and an application software engineer—working together closely to deliver an intelligent feature or product. Due to their tight-knit nature, these teams are positioned to iterate extremely quickly, which often leads to better products and features. However, the closely-knit nature of pods also comes with a downside, as knowledge sharing between pods with different objectives can be difficult.

     

    • Center of Excellence

    In a center of excellence (or COE) structure, all data scientists or data engineers are “pooled” and then assigned to different products or features depending on project requirements and circumstances. In contrast to pods, COE structures tend to share knowledge very easily. However, this arrangement can lead to slower iteration cycles because team members are not dedicated to particular products or features. 

    In our opinion, both pod and COE arrangements can be effective depending on the realities of an organization. Choosing an optimal team structure depends on how the rest of the organization is structured and how reporting relationships are set up. 

    Select Appropriate Tools

    To select the best possible tools for your organization, choose those that foster collaboration and uphold safety across code, model and data teams. 

    The right tools help teams work quickly and efficiently. Teams should be able to discover pertinent information for themselves without having to pull others off of whatever they are working on. For example, a data science team should be able to discover what data access or learn what features exist. Similarly, application teams should be able to discover what models exist, what versions are the latest or how and when to use models. The more that you can make your code, model and data self-serve, the faster teams will be able to build products that are ready to be put into production. 

    Furthermore, proper tools make debugging faster and easier. If you’ve been around ML-enabled features or products for any length of time, you’ve probably been bitten by undeclared dependencies and apps breaking due to upstream changes. In an intelligent app, finding the root of a problem can be extremely difficult because the root cause can exist in any of the three pillars or any combination of the three. Robust tools provide logs and information to help discover what went wrong more easily.

    Finally, governance should play a key role in tool selection, as safety should be a chief concern for ML teams. For example, consider a model that predicts the demographics of a user based on their app usage. While these predictions might be considered acceptable in certain applications, if a model is being used to make financial recommendations or approve credit applications, use of certain demographics may violate various consumer protection laws. Since a software engineer using this model might not be aware of the nuances related to its use, baking in safety checks on model and data use becomes vitally important. 

    Establish Ownership and Determine Appropriate KPIs

    Whether we are working at a company or in an academic lab, our goal always remains the same: build the best product. 

    But “best product” can mean a lot of different things depending on the use case. For example, sometimes teams may be willing to trade a bit of accuracy if a model fails in predictable ways (e.g., in health care applications.) By contrast, an e-commerce recommendation system can optimize for overall model accuracy even if a model isn’t quite as stable. As a result, choosing the appropriate KPIs for model optimization requires careful attention.  

    Similarly, choosing appropriate metrics that make sense for the product and business usually requires a high-level view of a number of factors — user expectations, revenues, user complaints, etc. In our experience, product owners are usually in the best position to make these decisions. KPIs for each of the pillars supporting the intelligent app should be based on key metrics determined by product owners. While these can range, we’ve seen the following KPIs work well:

    • Code — Number of releases, number of bug fixes, number of features that have shipped, mean time to resolution
    • Model — number of model iterations shipped, model quality in production, model performance SLAs 
    • Data — frequency of data refreshes (e.g., every day or every month?), number of data quality issues, speed of access to data

    The key point here is to drive all of these based on the product KPIs and to focus on the agile principle, which is how quickly are you moving and how many deploys are happening. 

    Know what metrics your team is looking to optimize so that you can invest your resources in the right spot. 

  • Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Okta and Sitel under fire over Lapsus$ hack, Greenpeace and others call for bitcoin change, and Europe still hates encryption. (more…)

  • Everything You Need to Know About Cookiecutter

    Everything You Need to Know About Cookiecutter

    Cookiecutter is a templating library for creating project boilerplates in any programming language. When individuals, teams and organizations create projects, they must follow consistent standards so that those projects are easily readable and searchable. Templates accelerate the code writing process, too, since developers are able to spend less time on setup and can get straight to the actual implementation. 

    Cookiecutter is a Python package, easily installable with pip or other package managers. It enables you to create and use templates for microservices and other software projects. It is a command line tool that doesn’t require knowledge of Python to use. Cookiecutter is widely used among software engineers, researchers, data scientists and other technical roles.

    Creating a template is simple and requires updating a cookiecutter.json file. Using a template requires running the cookiecutter command with the appropriate directory to create a new project.

    Here’s an example template for a Python package that the Cookiecutter team maintains. To use the template, install Cookiecutter first and then run the following command in your terminal:

    Cookiecutter https://github.com/audreyfeldroy/cookiecutter-pypackage.git 

    Go through the series of prompts and voila! In just a few moments, you have the skeleton of a completely functional Python package. Swap out the template for something else and you could just as easily spin up a mobile app, a data science notebook, or any other project on your favorite cloud service. There’s an entire community with thousands of templates to choose from.

    Creating custom templates to fit your and your organization’s needs is also simple and powerful. We’ll cover how to do that below.

    Who is Cookiecutter For?

    Cookiecutter is for individuals, teams and companies to standardize their project development process and accelerate new project creation.

    Example use cases include:

    • Learning a new framework: Cookiecutter lowers the barriers to entry for developers unfamiliar with a particular framework. You can find an expert’s template for a framework you’re learning and quickly get started with a configuration that is known to work.
    • Onboarding: Standardization makes collaboration much more manageable. New team members can immediately follow best practices without the risks of copying, pasting and trying to edit just the correct variables.
    • Enforcing standards in an organization: Consistent foldering, file-naming conventions and other patterns enable large teams to maintain an organized codebase.

    Cookiecutter Features

    Templates

    The heart of a template is the cookiecutter.json file, which might look something like this:

    {

      “full_name”: “Alice Cookie”,

      “email”: “foobar@example.com”,

      “project_name”: “Django Boilerplate”,

      “version”: “0.1.0”

    }

    These key-value pairs determine the prompts a developer needs to answer when using a template. The command line interface iterates over the keys, prompting a developer to set the various parameters. If a developer does not specify something, Cookiecutter uses default values.

    A template needs to have files and directories worth copying and reusing, such as the skeleton code for a particular framework. Cookiecutter uses these inputs to modify the template. To connect this boilerplate to the inputs, Cookiecutter uses the Jinja2 templating language. With Jinja2, Cookiecutter identifies all instances of the text {{cookiecutter.variable_name}} and replaces that boilerplate with the actual value of the variable. This works both within files as well as for file and directory names.

    Loops and Conditional Logic

    Jinja2 is very powerful and can do much more than just text substitution. It comes with control structures including for loops and if statements. It even has macros that are analogous to functions in programming languages. Since all of Cookiecutter’s templating uses Jinja2, it can leverage the same control flow features. This opens up enormous possibilities. For example, you could prompt a developer to specify which device types for which they are building an app and have unique behaviors depending on the response.

    Hooks

    Pre/post-generate hooks let you run Python or shell scripts before and/or after generating a project. Inputs from the template prompts are fair game within hooks and work similarly to the way they would elsewhere in the project with Jinja2 syntax. This means you can run a script to validate a developer’s responses to the prompts. Other applications of hooks include cleaning up unwanted files or otherwise using logic that would be complicated by just using Jinja2.

    What Are the Limitations?

    By design, templates are prescriptive with regard to a project’s setup, presenting all kinds of advantages as discussed above. On the other hand, a template might be opinionated in a way that does not align with either an individual developer’s or an organization’s preferences. In that case, it may be worth choosing another template or revising an existing one. Forcing a template in a situation that doesn’t make sense is less-than-ideal.

    What Are Some Alternatives or Extensions?

    Boilerplate for Specific Frameworks

    While Cookiecutter is compatible with almost any framework, some frameworks do have custom boilerplate that is readily available. If you were to start a React app, for example, there is a great boilerplate available to use as a starting point, and other communities often maintain similar ways to get started. Boilerplate is not incompatible with Cookiecutter, and you’ll find templates from popular boilerplate that you can use, too.

    Cruft Keeps Templates Organized

    As with any new process, there is some overhead involved to stay organized with Cookiecutter. When a team starts to manage dozens of templates or more, it’s especially important to keep templates up-to-date. Cruft works alongside Cookiecutter to not only make projects but to update existing ones as a template evolves. Cruft also has template validation capabilities to ensure projects match the latest version of a template.

    Learn More About Cookiecutter

    The Cookiecutter community has lots of resources to help you dig deeper.

  • 8 Skills Cloud Architects Need to Succeed

    8 Skills Cloud Architects Need to Succeed

    For cloud architects, a deep understanding of cloud tools and technologies is only the starting point in terms of skills that need to be mastered. Enjoying a successful career as a cloud architect requires much more, including certain skills that are typically not associated with the tech industry. 

    Architecture and Design

    The cloud architect needs to be an expert on end-to-end system design since their primary responsibility is solving a customer’s problems through the use of technology. The architect’s ability to develop a design that solves a business’s problem is where their true value lies. Because design is architecture, the cloud architect must have expert knowledge of all the current and legacy systems that exist in the network and in the data center and also understand how to migrate them to the cloud, matching them to the proper cloud-based systems.

    Network and Data Center Technologies

    Networking and data center skills are critical for the cloud architect because one of their major responsibilities is designing a plan to take the systems that were on the network and hosted in a data center and migrate them to the cloud. To do this successfully, cloud architects must be experts on networking and data center technologies.

    Digging deeper, they must be experts at routers, load balancers, switches, routing protocols, IP addressing and WAN connections whether those are private line-based, VPN-based or software-defined networking. They must be experts on servers and server virtualization and containers and storage, too: Block storage, object storage and file storage. The cloud architect also needs to be an expert at file-sharing protocols such as Server Message Block for Windows and NFS for Linux. Security, too, is an important skill; they must understand how firewalls, IDS/IPS systems and how VPN concentrators work. The cloud architect needs to have full knowledge of databases, understand how web applications work and understand ERP applications and supply chain applications. Good, strong network and data center knowledge is the foundation for architects who are overseeing the migration of tech from the data center to the cloud.

    Business Acumen

     Cloud architects are digital transformation specialists. They must craft end-to-end business solutions for customers with the goal of improving their businesses. If they do not have a thorough understanding of customers’ business, they cannot effectively engineer solutions that will solve their business problems.

    Business skills include the ability to calculate an ROI model based upon the expected value of an opportunity, to read a financial statement and to read a balance sheet. It includes knowledge and understanding of what the CEO, CFO, CIO and CTO care about and being able to communicate with them in ways they understand. Without an understanding of business, cloud architects limit themselves to simply adding or removing technology, which might make business outcomes better or might make them worse.

    Leadership

    Accomplishing anything great requires a team, which means being a great cloud architect requires leadership skills. When working for a client, a cloud architect typically will need to set a baseline of current systems. Accomplishing that effectively might require a team of 50 cloud engineers working together to evaluate the customer’s systems. Leadership skills allow you to effectively manage that team of engineers.

    And leadership skills go beyond effectively managing people as they work on proofs-of-concept and deployments. Leadership skills empower the architect to make sure teams are motivated, are fully engaged with projects and are contributing to success.

    Sales

    When on the job, a cloud architect is constantly selling. The solutions they designed need to be sold to the customer. The plan to implement the solution needs to be sold to management before the necessary resources can be obtained. When it is time to get people to work with us on a project, we need to sell them on its value. Sales skills are employed in a wide variety of ways. Cloud architects sell to customers, internal stakeholders and to management.

    Presentation

    Cloud architects also need exceptional presentation skills because they will be presenting to customers. Those customers could be technology professionals like engineers; they could be presenting to management and/or to C-level executives. Additionally, cloud architects will be presenting information at executive briefings and at conferences. In general, presentations are part of everyday life for the average cloud architect.

    Communication

    Determining the business requirements for any cloud architecture project requires asking a lot of questions. They’re never just handed a piece of paper by a client that says, “Build this.” Without stellar communication skills, it’s difficult—if not impossible—to determine the business’ requirements, meaning the solutions that are designed could be incorrect.

    Even once the business requirements are well understood, the next step is to take those requirements to a team of technology professionals, which means communicating effectively with tech people as well as business people. Communication skills, which include communicating to customers, teammates and various other stakeholders in the organization, are critical.

    Emotional Intelligence

    Emotional intelligence is a critical skill for those who want to increase their professional value and propel their cloud architect career forward. Emotional intelligence increases the capacity for leadership, understanding and communication. When used regularly in the job, it is the best predictor of career success and typically results in about a $30,000 increase in the average person’s salary. For a cloud architect to have a successful career, building on the skills outlined above is critical.