staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • 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.

  • Apple Outage Outrage | Linux Random Redo | Okta Hacked (or Not)

    Apple Outage Outrage | Linux Random Redo | Okta Hacked (or Not)

    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: Why Apple services were down, Linux gets a huge RNG overhaul, and we wonder if Okta was hacked again. (more…)

  • CSS-Tricks Sells Out | Peloton Spins Out | ARM Axes 1,000

    CSS-Tricks Sells Out | Peloton Spins Out | ARM Axes 1,000

    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: CSS-Tricks gets bought by DigitalOcean, Peloton pedals while its business burns, and Arm lays off up to 15% of staff. (more…)

  • Survey Surfaces Observability Challenges in the Cloud Era

    Survey Surfaces Observability Challenges in the Cloud Era

    A recent cloud observability survey found nearly two-thirds (64%) of respondents reported the adoption of public clouds has made it more difficult to achieve observability. Nearly half of respondents (48%) said they now consider providing real-time insights into application/infrastructure environments to be a top priority.

    The survey polled 357 IT professionals and was conducted by Enterprise Strategy Group (ESG) on behalf of Yotascale, a provider of cost optimization tools for cloud computing environments.

    Yotascale CEO Asim Razzaq said that attaining and maintaining observability becomes more challenging with each new cloud platform adopted. The survey found that 71% of organizations now rely on more than three cloud infrastructure providers.

    A full 84% of survey respondents also noted that tracking costs and cloud cost allocation is burdensome and time-consuming, and 61% admitted they lacked sufficient visibility into which teams own what cloud resources. Nearly a quarter (24%) are considering making changes to their monitoring and observability practices as infrastructure costs rise.

    Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate events with costs as part of an effort to rein in the costs of IT, said Razzaq.

    In the immediate aftermath of the COVID-19 pandemic, the number of workloads being deployed on public clouds increased sharply. In theory, many organizations signed enterprise licenses that reduce cloud costs if they consistently consume a certain level of infrastructure resources. In practice, however, individual developer teams are showing a preference for one cloud platform over another based on the attributes of their workloads. As a result, however, it becomes more challenging to not only consistently observe diverse platforms but also to control costs.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of pre-defined but often conflicting metrics. Observability platforms unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue.

    The rate at which DevOps teams will embrace observability will naturally vary. In 2022, the biggest obstacle might not be the technology as much as it is simply understanding what queries can help DevOps teams better understand the root cause of an IT issue before there is a major disruption. In the long term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify issues that might lead to a disruption long before it actually occurs. Regardless of approach, however, the ability to manage complex IT environments in the months and years ahead will continue to steadily improve.

  • ServiceNow Launches Incident Management Platform Infused with Observability

    ServiceNow Launches Incident Management Platform Infused with Observability

    ServiceNow added an incident management platform based on the Lightstep observability platform it acquired last year to its software-as-a-service (SaaS) portfolio.

    Ben Sigelman, general manager of Lightstep at ServiceNow, said Lightstep Incident Response gives DevOps teams access to observability tools that, via a self-service portal, enable them to determine the root cause of any incident much faster. It combines the ability to orchestrate on-call escalation, alert grouping, incident analysis and remediation with a set of collaboration and incident management tools.

    That approach will make the Lightstep observability platform much more accessible via a cloud service, noted Sigelman. The Lightstep observability platform itself is based on a time-series database capable of processing one trillion events each day.

    Lightstep Incident Response manages an organization’s on-call rotations by synchronizing schedules via a shared calendar, with specific tags that indicate who needs to be looped in based on the nature of the incident and the service that is impacted. Team members are invited to a dedicated channel based on prebuilt collaboration integrations for quick remediation. Over time they can create automated processes that self-triage and self-remediate problems as they reoccur. The platform also integrates with monitoring, observability and collaboration tools such as LogicMonitor, Postman, Slack, Sumo Logic and Zoom.

    Lightstep Incident Response is generally available now in both free and paid versions. Pricing is based on the use of active services being managed rather than by seat license.

    Lightstep Incident Response also natively integrates with the Now Platform that ServiceNow created for IT service management (ITSM). That integration will enable organizations to more easily meld ITSM and DevOps workflows, noted Sigelman.

    Observability platforms aggregate the collection of logs, metrics and traces in a way that makes it possible for DevOps teams to query that data. The goal is to make it easier for DevOps teams to identify anomalies that might disrupt an application environment. Those same tools, however, also allow DevOps teams to identify the root cause of an IT incident much faster. Today many organizations routinely convene “war rooms” that require IT teams to painstakingly identify the root cause of an issue by a process of elimination; this can take days—sometimes even weeks—to complete.

    With more applications becoming instrumented—thanks, in part, to the availability of open source agent software—Sigelman said observability platforms will play a critical role in helping to automate incident management processes. Prior to being acquired by ServiceNow, Lightstep team members played a role in the creation of both the OpenTracing and OpenTelemetry open source projects for collecting traces, metrics and logs. Today, OpenTelemetry is a sandbox-level project being managed under the auspices of the Cloud Native Computing Foundation (CNCF).

    With the deployment of more microservices-based applications, the percentage of applications that are instrumented will soon increase substantially. It’s not feasible to manage these highly distributed applications without some level of instrumentation. The issue now, of course, is determining to what degree to also instrument many of the monolithic applications that are already running in those same environments.

  • 7 Steps to Unleashing Your Citizen Developers

    7 Steps to Unleashing Your Citizen Developers

    As digital transformation accelerates, organizations are searching for ways to enable all their employees—not just IT, development or DevOps teams—to design, build, iterate and launch new processes and applications as per their requirements. This democratizing approach is called citizen development—where business users are empowered to create their own processes and apps with only minimal supervision from IT, ultimately relieving them from IT backlogs. 

    How to Get Started with Citizen Development

    Running a citizen development program doesn’t mean relegating IT to the sidelines. Citizen developers can often be prone to mistakes due to their lack of programming background. Limited skills may also result in creating a faulty app or unknowingly developing one that resembles existing software that serves the same purpose.

    Thus, citizen development calls for a new relational approach that’s founded on transparency, trust and dialogue between IT specialists and non-IT employees. 

    As a business leader, you’re in the best position to initiate such a program. Here are the steps you can take to get you started: 

    1. Identify citizen development potential

    You can issue surveys across departments or meet with division heads to understand who is using forms of shadow IT or already using citizen development tools, what they’re using these for and the number of users of these apps. Your findings can help you assess which departments have the most citizen developer candidates.

    Also, determine your company’s backlog of IT requests and current IT pain points. Knowing the pent-up demand will give you an idea of what issues citizen developers can seek to resolve.

    2. Set clear goals

    Communicate what citizen development aims to accomplish for your organization. Identify the apps you intend to create, the mode of deployment, the role of citizen developers and which departments will benefit.

    3. Get support from IT and fellow business leaders

    Find partners in the IT team and among other managers who can help champion your vision for citizen development. 

    First, approach the potential managers who will be collaborating with you in this cause. Getting their support early can aid you in establishing a more well-rounded vision and avoiding any conflicts down the road. By helping them understand how it will actually boost their department’s workflows instead of delaying internal tasks, you’d be able to muster credibility for your proposal.

    Meanwhile, assure your IT team that there’ll be a clear delineation of responsibilities between citizen developers and IT personnel. Employees will undergo self-directed and group training before being allowed to access a development environment. The software development life cycle will also be documented to make citizen developers aware of the process and necessary requirements for submitting their ideas. Moreover, IT developers will still be in charge of providing documentation, evaluating ideas and offering technical guidance with regular check-ins.

    4. Shortlist low-code/no-code platforms according to your business needs

    It would be best to look for low-code platform providers, schedule demos and invite IT and business unit leaders during dedicated sessions. They can compare feature sets and appraise learning curves with you. 

    5. Lay down a governance plan

    A governance plan ensures that data security best practices are in place and that IT assistance is well-defined in your citizen development program. Such a plan should cover:

    • The evaluation process for admitting projects into the citizen developer backlog or IT backlog
    • Standard compliance and security requirements for any project accepted for citizen development
    • Standard workflow protocols including testing, validation, audit and integration
    • What instances will require IT involvement

    6. Get senior management buy-in

    You’ll need to communicate your intentions with your senior executives and prepare to formally present your citizen development plan. 

    • Establish the rationale behind the plan. Compare internal metrics with industry stats showing the current need for citizen developers. Cite success stories or case studies.
    • Share internal figures pointing to the current IT backlog as well as results of surveys and discussions with employees and fellow managers.
    • Calculate and show your company’s projected one- to five-year ROI for using low-code/no-code platforms for citizen development.
    • Introduce your proposed governance plan and pilot program.

    7. Start training

    The citizen developers should be given time to learn the selected low-code/no-code platform. You can later pick a use case to pilot the tool. Identify your expectations and criteria to measure the success of the project.

  • Why the Built World Needs Standard APIs

    Why the Built World Needs Standard APIs

    Lately, new ESG initiatives have come front-and-center as companies seek to contextualize and limit their business’s impact on the environment. This is especially true for the built world—a term that refers to the human-made environment that provides the setting for human activity, including homes, buildings, zoning, streets, sidewalks, open spaces, transportation options and more—where monitoring energy efficiencies is becoming more commonplace and even required by law. For example, a New York City law now requires buildings of a certain size to post an energy-efficiency score at their entrances. Yet, calculating such a score isn’t that straightforward—there’s a lot of legacy technology in use within most large commercial and residential buildings, and pulling data from these systems is notoriously difficult.

    A building manager may seek greater visibility into these systems to not only determine a building’s energy score, but to program optimizations, inform building security or enact new digitization. But the answer isn’t to hastily rip out and upgrade old hardware—old equipment like AC units and elevators were built to last 50 years or more and could be functioning seamlessly. Instead, this is another area where REST APIs are set to accelerate by uniting legacy integration software and disparate hardware with a standard layer.

    I recently met with Shaun Cooley, CEO and founder of Mapped. According to Cooley, API-driven standards for built environments could open up transparency into hardware component behaviors and the interrelationships between systems within a building. Below, we’ll briefly consider the history of building protocols and look to standards like Brick Schema that aim to unite legacy and modern physical infrastructure. We’ll consider the competitive advantage APIs bring to the built world and how increasing data accessibility could assist operations.

    The State of Physical Building Digital Protocols

    The built world consists of various digital communications standards. Most buildings have many older on-premises protocols for lighting, HVAC, elevators and other systems. For example, many elevators and fire safety systems were installed by systems integrators in the 1970s and adopted connections using Modbus, a communication protocol based on serial connections. BACnet is also commonly used to control HVAC systems and is a step forward from Modbus in that it can more easily connect to IP networks.

    Fast-forward a few decades to the dawn of the cloud; many companies overlaid sensors onto these old systems, explained Cooley. These power-over-ethernet (PoE) or battery-powered systems relay data immediately to the cloud and often speak in proprietary protocols. A single commercial building could easily be juggling a bundle of these various communication protocols, all originating from installations that occurred at different time periods. These nuances mean that you are “constantly dealing with chaos across your portfolio,” Cooley said. There’s so much data, but getting it normalized and usable is very challenging, he said. One must integrate with many sensors and protocols, which he describes as “the dirty plumbing” that no one wants to build.

    There’s bound to be differentiation from building to building, too, which could place a further strain on managing multiple building operations. Without a window into building data, it isn’t easy to know things like the current occupancy of the lobby or how occupancy affects energy consumption. Unless managers can connect the dots between systems, it’s impossible to understand the relationships between components.

    Making a Data Graph for a Building

    For example, take an AC system in a commercial building. Such a unit isn’t as simple as a single-family home’s typical thermostat and furnace. It’s often a mix of a rooftop chilling unit, pipes, pumps and a VAV damper that controls the air. While protocols are good at describing how individual components are performing, the composition of components is really what defines a building’s system and its efficiency, said Cooley.

    According to Cooley, instead of adopting a vertical data schema, buildings require a graph data model to adequately represent hardware interconnections. This is why he’s rallying behind Brick Schema, an open source uniform metadata schema for buildings. Instead of a vertical data schema, Brick Schema is built on a graph data model, which enables more descriptive relationships in a system.

    End Benefits

    Pulling unstructured data from 20 different data lakes into a clean API could allow easier access to new solutions. “We want to make it very simple to build applications for these sorts of environments,” said Cooley. Typically, system integrators must reverse engineer and connect to legacy building hardware, which can become very expensive very quickly, he said. He recommended using a sandbox based on open standards that can easily be rolled out to any building to reduce those hurdles. A more consumable layer with common endpoints could increase developer usability when creating innovative building applications.

    Similar to how Twilio made SMS easy, Cooley said he hopes for a similar proliferation in the built world. Many applications could be built with such an abstraction layer. For example, managers could better understand energy usage to reduce consumption, meet regulations and save money. Or, such an abstraction layer could inform predictive maintenance to create automated alerts before failures occur. There are also plenty of ways to improve occupant experience or intelligently optimize the lighting and temperature in a space.

    “Entirely new business models and concepts emerge that we hadn’t considered previously,” said Cooley. For example, he described a “tailgating app” that uses Brick Schema for a security use case. The app prevents building occupants from letting other people “tailgate” into the building behind them after someone swipes their badge. To do so, the app interfaces with many separate building systems (the elevator system, surveillance system, telepresence systems and other sensors) to ensure the number of people in the building matches the number of occupants that swiped in. A lingua franca helps to connect the disparate hardware involved.

    The Future of Building Automation

    This is by no means the first attempt to standardize building data. For example, the Green Button Initiative provides a standard API through which to download utility use data for electricity, gas and water and share it with solution providers. However, according to Cooley, this information only goes so far. Building owners will require more contextual data on-site.

    For example, perhaps a building’s window glazing is causing specific rooms to overheat in the sunlight. Thermal sensors would spot this condition, but bulk energy consumption readings wouldn’t ascertain the root cause. Access to real-time granular data such as current occupancy count is also necessary for developing on-site applications that better refine exactly how human involvement impacts energy consumption.

    Of course, as building systems become more intelligent, there is the growing possibility of privacy infringement. For example, systems that use facial monitoring and recognition could end up storing personally identifiable information. In that case, you “need to give data owners the control to decide what applications can’t or can’t access PII,” said Cooley.

    While this field has many read-only applications, Cooley predicts future write operations will enable more automation with building hardware. This could allow applying ML/AI to anticipate elevator floor calls. Or, a predictive system could cool a room only when a meeting is scheduled. When such data is readily accessible and available for developers, it presents many innovative opportunities to optimize and interact with the built world.

  • Ukraine Asks for DNS Censorship | Ukraine Snapchat Staff Danger | #BoycottKaspersky?

    Ukraine Asks for DNS Censorship | Ukraine Snapchat Staff Danger | #BoycottKaspersky?

    Welcome to Ukraine Week here at 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: Censoring the Russian internet, Snap fears for hundreds of Ukrainian employees, and Eugene Kaspersky acts like a ****.

    1. ICANN, but IWONT

    First up this week: Ukraine has asked ICANN to drop Russia from the DNS. Andrii Nabok, the Ukrainian representative of ICANN’s Governmental Advisory Committee argues a DNS blockage would “help users seek for reliable information in alternative domain zones, preventing propaganda and disinformation.”

    Given today’s confirmation that Muscovite K12 students had been arrested for laying flowers at the Ukrainian embassy, this goal seems all the more laudable. But frankly, a moment’s thought says it’s a bad idea.

    Analysis: “The net interprets censorship as damage and routes around it”

    John Gilmore was right. Such a move would inevitably fail. And there’s a real risk of undesirable, unintended consequences.

    Kat Bouza and Noah Shachtman: Ukraine Pushes to Unplug Russia From the Internet

    Ukraine’s request to the Internet Corporation for Assigned Names and Numbers (ICANN) seeks to revoke domains issued in Russia and shut down primary Domain Name System (DNS) servers in the country. [It] would send a strong message to a regime pumping out digital propaganda.
    …
    The DNS root zone is a crucial element of the overall functionality of the internet, responsible for handling queries to top-level domains — such as .com, and country-specific domains like Russia’s .ru. Removing Russia’s access to this cluster of servers would prevent Russian internet-service providers from communicating.
    …
    But … the unprecedented request has the potential to do more harm than good. … Representatives for ICANN … declined to comment.


    But the request is pretty naïve, thinks this Anonymous Coward:

    All they would have to do is get the ISPs to add a zone to their DNS that says “ru. IN NS x.x.x.x” and then for all their users, any requests for a .ru domain would be directed to x.x.x.x

    OK, the rest of the world would miss out, but I doubt that they would care.


    Is there a better way? ArmoredDragon breathes fire:

    A better way … is to ask western certificate authorities to revoke all [Russian] certificates. Then ask the major OS and browser vendors to remove any CAs that don’t comply.

    That would really **** with them because there’s nothing [Russia] can do about that. And it would even **** with Russia’s ability to do business with Chinese companies and Chinese customers.

    2. Fear for 300 Ukraine Employees at Snap

    Snap, Inc.—formerly Snapchat—owns the Ukrainian company that created the technology used in the real-time video shenanigans behind “I’m not a cat.” It has hundreds of employees in Kyiv and Odesa.

    Analysis: Solidarity doesn’t Stop Wars, but Sanctions Might

    This very human DevOps story is but a footnote to the wider picture of tech companies acting to echo Western governments’ sanctions. It’ll cause us a little pain, but that’s nothing compared to the suffering felt by Ukrainians. And it’ll be worthwhile if it shortens the war.

    J. Clara Chan: Three hundred Snap employees are from Ukraine

    In a public note, … Snap — the parent company of Snapchat — said … that 300 of Snap’s “most creative and talented team members” are from Ukraine, … the birthplace of Looksery, the augmented reality platform that Snap acquired in 2015. … Snap said it has pledged over $15 million in humanitarian aid to support Ukraine. … The company is also providing emergency assistance to employees who need help safely relocating.
    …
    “We stand in solidarity with our Ukrainian team members and the people of Ukraine. … This is a devastating conflict with far-reaching consequences. … It is a direct threat to many of our team members and their families.
    …
    “Over many years working with our Ukrainian colleagues and friends, we have gotten to know the inventiveness, strength, and resilience of the Ukrainian people. … We will continue to work tirelessly to help our Ukrainian team members and their families, support our Snapchat community, and determine how we can help make positive contributions to the immense humanitarian efforts underway.”


    It’s bang on trend, reports Corinne Reichert:

    Snapchat has followed suit after Facebook, Twitter and YouTube began pausing ads on Friday, saying it has now stopped all advertising running in Russia, Ukraine and Belarus following the Russian invasion of Ukraine. … The Snapchat app remains live in Ukraine, Russia and Belarus, [but] Snap is monitoring the platform for misinformation or other misuse.
    …
    Apple has also halted sales of its products in Russia, as well as online transactions, Apple Pay and some Apple Maps features. Google [is] temporarily disabling some live Google Maps features, adding an SOS alert to Search and blocking Russian state-controlled media. It said Google Pay “may become unavailable.”


    But don’t hang up on Dade “+++ATH” Hayes: [ask your parents]

    In terms of any financial sacrifice from the foregone advertising opportunities, it isn’t clear that all that much is at stake for Snap. … While the company’s stance on the Russia-Ukraine situation clear and emphatic, it is also an easier one for for Snap to take than for many of its tech rivals.

    3. Yevgeny Valentinovich ‘Eugene’ Kaspersky has Chosen the Side of the Oppressor

    The figurehead eponym of AO Kaspersky Lab is being publicly shamed for comments he made about the war in Ukraine. In stark contrast to Snap’s statement, he is accused of overt neutrality, minimizing the war’s severity—and even of shoehorning in some marketing.

    Analysis: #BoycottKaspersky

    Desmond Tutu was right. But, while it’s tempting to “cancel” Eugene, dial down the emotion and think instead about your security posture. If you use Kaspersky products internally, what risks are you exposing your organization to? How might the Russian government exert pressure on the company to compromise your network?

    James Coker: Eugene Kaspersky’s Statement Provokes Controversy

    Cybersecurity industry veteran Eugene Kaspersky has provoked a strong reaction from leading figures in the sector. … Kaspersky, CEO of the Russian-headquartered IT security vendor of the same name, broke his silence on the conflict:
    …
    “We welcome the start of negotiations to resolve the current situation in Ukraine and hope that they will lead to a cessation of hostilities and a compromise. We believe that peaceful dialogue is the only possible instrument for resolving conflicts. War isn’t good for anyone. … The main thing we can do in this situation is provide uninterrupted functioning of our products and services.”
    …
    His description of the conflict as a “situation” and apparent attempt to advertise his firm led to a number of furious responses. … Following Kaspersky’s tweet, the hashtag #BoycottKaspersky appeared.


    With a balanced view, it’s Nick Farrell:

    Kaspersky sits on the fence … in Russia it is not a good idea to have a view. [But] whoever is advising Kaspersky on PR might need to have a rethink.
    …
    After all a compromise is [not] always possible when one side is firing missiles into residential areas. If he applied the same premise with ransomware, he would be suggesting, … “It is better that you talk to the people who are holding your servers hostage.” … How much is Kaspersky, the company, influenced by the Russian government?


    Does your shop use Kaspersky? Nick Lange cuts to the chase:

    I would like to remind all readers that, in case of war, … software with access to companies and the capacity to be updated worldwide in matter of hours at the same time is a high class target to get forced to cooperate by a autocratic government.

    The Moral of the Story: If an elephant has its foot on the tail of a mouse and you say that you are neutral, the mouse will not appreciate your neutrality.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Brandon Morales (via Unsplash; leveled and cropped)