While operational and analytical data gets rigorous treatment in terms of the pillars of good architecture such as purview, privacy, security, governance, encryption at rest and in transit, aging, tiering and such others, DevOps tasks comprising Extract-Transform-Load, backup/restore and such others, is often brushed aside but never eliminated for the convenience they provide. This is inclusive of the vast vector stores that have now become central to building contextual copilots in many scenarios.

One of the tools to empower access of data for purposes other than transactional or analytics is the ability to connect to it with a client native to the store where the data resides. Even if the store is in the cloud, data plane access is usually independent of the control plane command-line interfaces. This calls for a creating a custom image that can be used on any compute to spin up a container with ability to access the vectors. For example, this Dockerfile installs clients:

FROM python:3.13-latest-dev

USER root

RUN apt-get update && \

    apt-get install -y ksh \

    ldap-utils \

    mysql-client \

    vim \

    wget \

    curl \

    libdbd-mysql-perl \

    libcurl4-openssl-dev \

    rsync \

    libev4 \

    tzdata \

    jq \

    pigz \

    python3-minimal \

    python3-pip && \

    apt-get clean && \

    rm -rf /var/lib/apt/lists/* && \

    pip3 install s3cmd

RUN apk add --no-cache mariadb mariadb-client

RUN pip install azure-storage-blob requests

RUN pip install requests

WORKDIR /app

COPY custom_installs.py .

RUN mysqldump --version

RUN mysql --version

ENTRYPOINT ["python", "custom_installs.py"]

 This is a summary of the book titled “Technology for Good: How Nonprofit Leaders Are Using Software and Data to Solve Our Most Pressing Social Problems” written by Jim Fruchterman and published by MIT Press, 2025. This book piques my interest because bad ideas need to be abandoned fast and both startups and non-profits struggle with that until it becomes critical. In this book, the author explores why high-growth, profit-driven start-ups can and nonprofit technology ventures cannot. While the popular imagination tends to focus on for-profit start-ups capable of viral success and massive wealth creation, Fruchterman argues that nonprofit tech start-ups play an equally important role in shaping the future, particularly when it comes to addressing entrenched social problems. Drawing on his experience as a social entrepreneur, he offers a practical guide to building social enterprises, noting that while nonprofit and for-profit start-ups face similar challenges in developing ideas and raising capital, nonprofits benefit from a crucial advantage. Because they are not beholden to investors seeking financial returns, nonprofit founders have greater freedom to prioritize impact over profit.

Nonprofit organizations are chronically behind the technology curve. Tight budgets and donor expectations often leave charities and public agencies relying on outdated hardware and software, sometimes lagging a decade or more behind current standards. Although technology is essential to modern organizational effectiveness, donors frequently view technology spending as overhead rather than as a core part of the mission. Fruchterman challenges this mindset and emphasizes that the most effective way for nonprofits to modernize is often by adapting widely used, standard platforms rather than attempting to build custom solutions from scratch. Tools such as Microsoft Office or Slack can meet many needs, and large technology companies frequently offer discounted pricing to nonprofits, often coordinated through organizations like TechSoup Global. While custom software development is sometimes necessary, it is usually more cost-effective to purchase existing solutions, provided the organization has enough technical expertise to manage vendor relationships and protect its interests. In rare cases, nonprofits even form specifically to create technology that the commercial market has failed to address.

Fruchterman is particularly critical of the nonprofit sector’s tendency to incubate ill-fated technological innovations. Unlike the for-profit world, where start-ups are encouraged to test ideas quickly, gather feedback, and abandon bad concepts early, nonprofit leaders often cling to flawed ideas for too long. One common mistake is the assumption that every organization needs a mobile app simply because apps are ubiquitous in everyday life. In reality, most users do not want more apps, and many nonprofit apps fail to gain traction. The author also cautions against rushing into experimental or heavily hyped technologies. Blockchain, for example, attracted significant attention after the success of Bitcoin, leading many donors and nonprofits to assume it could be easily repurposed for social good. In practice, blockchain initiatives have often failed to deliver meaningful benefits, as illustrated by costly implementations that outweighed their promised savings. Fruchterman urges social leaders to remain skeptical and clear-eyed, especially when technologies are promoted by those more focused on ideology than sound technical design.

Despite these pitfalls, the book makes a strong case that thoughtfully deployed technology can dramatically increase the social sector’s impact. While for-profit companies often aim to eliminate human interaction through automation, nonprofits tend to emphasize person-to-person relationships. Fruchterman argues that technology should not replace human connection in the social sector, but rather support it, particularly by improving efficiency for frontline workers. When those closest to the people being served can work more effectively, the organization’s overall impact is amplified. He also highlights the potential of delivering well-designed tools directly to communities themselves.

One illustrative example is Medic, a social organization that builds tools specifically for community health workers. By replacing paper forms with digital data and linking frontline workers to local health systems, Medic created an app that succeeded precisely because it was narrowly targeted and deeply practical. Although most nonprofit apps add little value, Medic’s tool stands out because it was designed for a clearly defined audience and addressed real operational needs. The result was improved outcomes in areas such as maternal health, disease treatment, and vaccination tracking.

Fruchterman also challenges conventional nonprofit strategic planning. He argues that long-term strategic plans are often too rigid to survive in a rapidly changing world, a lesson underscored by the COVID-19 pandemic, which rendered many carefully crafted plans irrelevant almost overnight. Instead of producing static documents, nonprofits should adopt a more agile approach to strategy that remains grounded in mission while allowing for rapid adaptation. This means focusing on the organization’s core objectives—the “what”—rather than locking into specific tactics—the “how.” By collecting real-time data and learning continuously from results, nonprofits can test assumptions, adjust programs, and respond more effectively to changing conditions.

The book devotes significant attention to artificial intelligence, emphasizing both its promise and its limitations. Fruchterman stresses that AI systems are only as good as the data used to train them, and that bias is an unavoidable risk when datasets are incomplete or unrepresentative. Because many AI tools are developed primarily in English and rely on mainstream data sources, they often overlook the poor and underserved populations that nonprofits aim to support. The author illustrates this problem with examples of biased facial recognition systems that perform poorly on women and people of color due to skewed training data. Such cases underscore the importance of diverse development teams and careful scrutiny when deploying AI in social contexts.

Another key distinction Fruchterman draws is between the goals of nonprofit and for-profit start-ups. While commercial tech ventures are often driven by the promise of wealth, nonprofit start-ups exist to serve people who cannot pay for services. As a result, financial success is defined not by profits but by impact and sustainability. Although the motivations differ, the basic phases of launching a start-up are similar, beginning with exploration and user research, followed by development, growth, and eventual maturity. Throughout these stages, nonprofit founders must be disciplined about testing ideas, releasing imperfect products, and learning from feedback.

Funding and talent emerge as persistent challenges for nonprofit tech start-ups. Fruchterman estimates that early-stage funding typically ranges from modest six-figure sums to around a million dollars for more ambitious projects, with founders often contributing unpaid labor in the beginning. Philanthropic foundations, fellowship programs, accelerators, government agencies, and corporate social good initiatives all play important roles in supporting these ventures. Unlike for-profit start-ups, nonprofits aim simply to break even while maximizing the number of people they help. Although nonprofits cannot compete with the salaries offered by commercial tech firms, they can attract professionals motivated by purpose rather than profit, particularly when expectations around compensation are addressed transparently from the outset.

Fruchterman argues that social entrepreneurs should prioritize empowering communities and individuals rather than imposing top-down solutions. Access to healthcare, education, capital, and inclusion can transform lives, and technology can be a powerful enabler when used responsibly. He encourages nonprofit leaders to embrace data collection and cloud-based tools while remaining transparent about how data is used and firmly committed to protecting it from exploitation. The book closes with a call to use AI and other emerging technologies for good, capturing efficiency gains without surrendering human judgment or ethical responsibility. Fruchterman has a long career in social entrepreneurship and open-source development that gives authenticity to his message that when technology is guided by mission, humility and respect for the people it serves, it can become a powerful force for positive social change.

 While operational and analytical data gets rigorous treatment in terms of the pillars of good architecture such as purview, privacy, security, governance, encryption at rest and in transit, aging, tiering and such others, DevOps tasks comprising Extract-Transform-Load, backup/restore and such others, is often brushed aside but never eliminated for the convenience they provide. This is inclusive of the vast vector stores that have now become central to building contextual copilots in many scenarios.

One of the tools to empower access of data for purposes other than transactional or analytics is the ability to connect to it with a client native to the store where the data resides. Even if the store is in the cloud, data plane access is usually independent of the control plane command-line interfaces. This calls for a creating a custom image that can be used on any compute to spin up a container with ability to access the vectors. For example, this Dockerfile installs clients:

FROM python:3.13-latest-dev

USER root

RUN apt-get update && \

    apt-get install -y ksh \

    ldap-utils \

    mysql-client \

    vim \

    wget \

    curl \

    libdbd-mysql-perl \

    libcurl4-openssl-dev \

    rsync \

    libev4 \

    tzdata \

    jq \

    pigz \

    python3-minimal \

    python3-pip && \

    apt-get clean && \

    rm -rf /var/lib/apt/lists/* && \

    pip3 install s3cmd

RUN apk add --no-cache mariadb mariadb-client

RUN pip install azure-storage-blob requests

RUN pip install requests

WORKDIR /app

COPY custom_installs.py .

RUN mysqldump --version

RUN mysql --version

ENTRYPOINT ["python", "custom_installs.py"]

 

This is a summary of the book titled “How the Future Works: Leading Flexible Teams To Do The Best Work of Their Lives” written by Brian Elliott, Sheela Subramanian and Helen Kupp and published by Wiley, 2022. In this book, the authors examine one of the most profound transformations in modern business: the rapid and irreversible shift toward flexible work. Written in the aftermath of the COVID-19 pandemic, the book argues that what began as an emergency response has evolved into a durable and preferable way of working—one that challenges long-held assumptions about productivity, leadership, and the role of the traditional office.

Before the pandemic, flexible work arrangements were rare and often reserved for elite performers. Most organizations relied on physical offices, fixed schedules, and direct supervision as the foundation of productivity. Many leaders believed that innovation depended on employees sharing the same space, learning through proximity, and being visibly present. The idea of managing a distributed workforce seemed risky, if not impossible. Yet when offices abruptly closed in 2019, companies had no choice but to test those assumptions at scale.

What followed surprised many executives. Productivity did not collapse; in many cases, it increased. Employees reported greater autonomy, improved focus, and stronger work–life balance. Creativity and innovation continued, and in some organizations even flourished. As the authors note, flexibility turned into a powerful advantage in recruiting and retaining talent, particularly in a highly competitive labor market. The authors conclude that a full return to rigid, office-centered work is both unlikely and undesirable.

Central to the book’s argument is the idea that traditional measures of productivity were flawed long before remote work became common. Managers once relied on visible activity—attendance, desk time, and “management by walking around”—as proxies for performance. These methods fail in distributed environments and, more importantly, never truly measured the quality or impact of work in the first place. Seeing employees at their desks does not reveal whether they are engaged, effective, or producing meaningful outcomes.

To help organizations adapt, the authors outline seven interrelated steps for retrofitting companies for the future of work. The first is to operate according to a clear and shared set of principles. Because flexibility introduces complexity and uncertainty, principles act as a compass for decision-making. Rather than imposing uniform rules, leaders should prioritize team-level autonomy, recognize that different functions require different approaches, and adopt a digital-first mindset that treats remote participation as the default rather than the exception.

Principles alone, however, are not enough. Organizations must also establish behavioral guidelines that translate values into everyday practices. These “guardrails” ensure fairness and prevent the emergence of “faux flexibility,” where policies appear progressive but still constrain employee autonomy. Examples such as Slack’s “one dials in, all dial in” rule demonstrate how simple norms can reinforce inclusion and equity across hybrid teams.

A defining theme of the book is collaboration rather than control. The authors caution against top-down mandates and instead encourage leaders to co-create flexible work policies with employees. Teams that are already working effectively should be studied and learned from, and flexibility should be formalized through team-level agreements that clarify expectations around schedules, communication, accountability, and relationships. This participatory approach builds trust and ensures that flexibility works for both individuals and the organization.

Because no universal blueprint exists, experimentation is essential. Leaders must accept uncertainty, support pilot programs, and view trial and error not as failure but as learning. Over time, patterns emerge that reveal what truly supports performance and well-being. The authors emphasize that there is no perfect data point or benchmark—only continuous improvement guided by experience and feedback.

The book also challenges the belief that culture depends on physical proximity. While companies once invested heavily in office campuses, the authors argue that connection and belonging can be cultivated virtually—and sometimes more inclusively than before. Research cited in the book links flexibility to stronger feelings of belonging, higher job satisfaction, and improved well-being, undermining the assumption that creativity depends on shared physical space.

Leadership, however, must evolve. The shift to flexible work has exposed weaknesses in managers who rely on control rather than trust. The authors advocate developing managers as coaches—leaders who communicate clearly, show empathy, and focus on outcomes instead of activity. Training initiatives like Slack’s “Base Camp” illustrate how organizations can intentionally build these capabilities.

The authors contrast two management paths: the “doom loop” of constant surveillance and the “boom loop” of trust and accountability. Excessive monitoring erodes morale, increases anxiety, and drives attrition, while goal-based management fosters engagement and performance. Tools such as the RACI matrix help organizations track progress without resorting to intrusive oversight, reinforcing the principle that results—not hours—matter most.

Flexibility is not a temporary accommodation but a defining feature of modern work. Employees want and need it, and organizations that embrace it thoughtfully gain a lasting competitive advantage. While flexibility is not a cure-all, the authors argue it is a decisive step toward healthier, more resilient, and more human workplaces when implemented with intention and trust.

#codingexercise:CodingExercise-02-12-2026

 In continuation of previous posts of exemplary video analysis stacks on AWS, we focus on Azure today. The most explicit lineage of “well architected” drone and video analytics on Azure starts with Live Video Analytics on IoT Edge and evolves into more general edge to cloud platforms like Edge Video Services. Live Video Analytics (LVA) was introduced as a hybrid platform that captures, records, and analyzes live video at the edge, then publishes both video and analytics to Azure services. It is deliberately pluggable: we wire in our own models—Cognitive Services containers, custom models trained in Azure Machine Learning, or open source ML—without having to build the media pipeline ourself. Operational excellence is baked into that design: the media graph abstraction gives us declarative topologies and instances, so we can version, deploy, and monitor pipelines as code, while IoT Hub and the Azure IoT SDKs provide a consistent control plane for configuration, health, and updates across fleets of edge devices. (LVA)

Reliability and performance efficiency in LVA come from pushing the latency sensitive work—frame capture, initial inference, event generation—onto IoT Edge devices, while using cloud services like Event Hubs, Time Series Insights, and other analytics backends for aggregation and visualization. The edge module runs on Linux x86 64 hardware and can be combined with Stream Analytics on IoT Edge to react to analytics events in real time, for example raising alerts when certain objects are detected above a probability threshold. That split honors the reliability pillar by isolating local decision making from cloud connectivity, and it improves performance efficiency by avoiding round trips to the cloud for every frame. At the same time, Azure Monitor and Application Insights provide the observability layer—metrics, logs, and traces across IoT Hub, edge modules, and downstream services—so operators can detect regressions, tune graph topologies, and automate remediation in line with the operational excellence pillar.

Edge Video Services (EVS) takes those ideas and generalizes them into a reference architecture for high density video analytics across a two or three layer edge hierarchy. In EVS, an IoT Edge device on premises ingests camera feeds and runs an EVS client container that fans frames out to specialized video ML containers such as NVIDIA Triton Inference Server, Microsoft Rocket, or Intel OpenVINO Model Server. A network edge tier—typically AKS running in Azure public MEC—provides heavier compute with GPUs and low latency connectivity back to the on prem edge. This cascaded pipeline is a direct expression of the performance efficiency and cost optimization pillars: lightweight filtering and pre processing happen close to the cameras, while more expensive models and multi stream correlation are centralized on shared GPU clusters, avoiding over provisioning at either layer. Reliability is addressed through Kubernetes based orchestration, multi node clusters at the network edge, and the ability to re route workloads across the hierarchy if a node fails. (EVS)

From a sustainability and cost perspective, both LVA and EVS lean heavily on managed services and right sized compute. In LVA style deployments, only the necessary analytics results and selected clips are shipped to the cloud, with raw video often retained locally or in tiered storage, reducing bandwidth and storage overhead. EVS goes further by explicitly partitioning workloads so that GPU intensive inference runs on shared AKS clusters in MEC locations, improving utilization and reducing the number of always on, underused GPU nodes. This aligns with Azure’s sustainability guidance: use managed services where possible, aggressively manage data lifecycles, and concentrate specialized hardware in shared, high utilization pools rather than scattering it across many small sites.

When we compare these drone and video centric stacks to more generic ingestion and analytics patterns on Azure, the performance story is less about raw maximum throughput and more about how that throughput is shaped. Event Hubs and IoT Hub are documented to handle millions of events per second across partitions, and AKS hosted Kafka or custom gRPC ingestion services can be scaled horizontally to similar levels; those patterns are typically used for logs, telemetry, and clickstreams where each event is small and homogeneous. In LVA and EVS, the “events” are derived from high bandwidth video streams, so the architectures focus on early reduction—frame sampling, on edge inference, event extraction—before feeding Event Hubs, Time Series Insights, or downstream databases. In practice, that means we inherit the same proven ingestion envelopes and scaling knobs as other well architected Azure stacks, but wrapped in domain specific primitives: media graphs, edge hierarchies, GPU aware scheduling, and hybrid edge cloud control planes that are tuned for drone and camera workloads rather than generic telemetry.

 In the previous post, the Well-Architected pillars are woven directly into the way the stack ingests, analyzes, and serves video from large fleets of IoT devices. At the operational excellence layer, the architecture leans on API Gateway, Lambda, and Step Functions as the control plane for all asynchronous workflows. These services provide end to end tracing of requests as they move through ingestion, indexing, search, and alerting, so operators can see exactly where latency or failures occur and then automate remediation. The result is an operations model where deployments, rollbacks, and workflow changes are expressed as code, and observability is built into the fabric of the system rather than bolted on later. AWS

Reliability and performance efficiency are largely delivered through serverless and on demand primitives. Lambda functions form the core processing tier, inheriting multi AZ redundancy, automatic scaling, and built in fault tolerance, so the video analytics pipeline can absorb bursty workloads—such as many cameras or drones triggering events at once—without explicit capacity planning. Kinesis Video Streams, Kinesis Data Streams, and DynamoDB are configured in on demand modes, allowing ingest and metadata operations to scale with traffic while avoiding the idle capacity that plagues fixed size clusters. This mirrors the broader AWS streaming reference architectures, where Kinesis Data Streams is positioned to handle “hundreds of gigabytes of data per second from hundreds of thousands of sources,” with features like enhanced fan out providing each consumer up to (2,\text{MB/s}) per shard for low latency fan out at scale. AWS aws.amazon.com

Cost optimization and sustainability in the video analysis guidance are treated as first class design constraints rather than afterthoughts. Data retention is explicitly tiered: 90 days for Kinesis Video Streams, 7 days for Kinesis Data Streams, and 30 days for OpenSearch Service, with hot to warm transitions after 30 minutes. That lifecycle design keeps only the most valuable slices of video and metadata in high cost, low latency storage, while older data is either aged out or moved to cheaper tiers. Combined with Lambda’s pay per use model and the shared, managed infrastructure of Kinesis, OpenSearch Service, and S3, the architecture minimizes always on resources and therefore both spend and energy footprint. This aligns directly with the Well Architected sustainability pillar, which emphasizes managed services, automatic scaling, and aggressive data lifecycle policies to reduce the total resources required for a workload. AWS Protera Technologies

When we compare this video analysis stack to other well architected ingestion and analytics patterns on AWS—such as the generic streaming data analytics reference architectures built around Kinesis Data Streams, Amazon MSK, and Managed Service for Apache Flink—the main difference is not in raw throughput but in workload specialization. The streaming reference designs show that Kinesis Data Streams can scale from a few MB/s per shard up to hundreds of MB/s per stream, while MSK clusters can be sized to ingest on the order of (200,\text{MB/s}) and read (400,\text{MB/s}) with appropriate broker classes and partitioning. pages.awscloud.com AWS Documentation Those architectures are optimized for generic event streams—logs, clickstreams, IoT telemetry—where we often trade richer per event processing for extreme fan in and fan out. The video analysis guidance, by contrast, wraps those same primitives in a domain specific pattern: Kinesis Video Streams for media ingest, OpenSearch for indexed search over events and clips, and Lambda driven workflows tuned for video centric operations like clip extraction, event correlation, and fleet wide search. In practice, that means we inherit the same proven performance envelope and scaling characteristics as the broader streaming patterns, but expressed through a solution that is already aligned with the operational excellence, reliability, cost, and sustainability expectations of a production grade video analytics service.

 AWS and DVSA:

A number of efforts in both industry and academia have attempted to build drone‑video analytics pipelines on AWS, and while none mirror the full spatial‑temporal, agentic‑reasoning architecture of your platform, several come close in spirit. One of the most visible industry examples is Amazon’s own reference implementation for real‑time drone‑video ingestion and object detection. This solution uses Amazon Kinesis Video Streams for live ingestion, a streaming proxy on EC2 to convert RTMP feeds, and an automated frame‑extraction workflow that stores images in S3 before invoking Lambda functions for analysis. The Lambda layer then applies Amazon Rekognition—either with built‑in detectors or custom Rekognition Custom Labels models—to identify objects of interest and trigger alerts through SNS. The entire system is packaged as a CDK deployment, emphasizing reproducibility and infrastructure‑as‑code, and demonstrates how AWS primitives can be orchestrated into a functional, cloud‑native drone‑video analytics pipeline. Github

AWS has also published a broader architectural pattern under the banner of “Video Analysis as a Service,” which generalizes these ideas for fleets of IoT video devices, including drones. This guidance describes a scalable, multi‑tenant architecture that supports real‑time event processing, centralized dashboards, and advanced search across large video corpora. It highlights the use of API Gateway, Lambda, and Step Functions for operational observability, IAM‑scoped permissions for secure access control, and AWS IoT Core Credential Provider for rotating temporary credentials at the edge. Although not drone‑specific, the architecture is clearly designed to support drone‑like workloads where video streams must be ingested, indexed, analyzed, and queried at scale. AWS

Together, these efforts illustrate how AWS has historically approached drone‑video analytics: by leaning heavily on managed ingestion (Kinesis Video Streams), serverless processing (Lambda), and turnkey vision APIs (Rekognition). They provide a useful contrast to your own platform, which treats drone video as a continuous spatial‑temporal signal and integrates vision‑LLMs, agentic retrieval, and benchmarking frameworks. The AWS examples show the industry’s earlier emphasis on event‑driven object detection rather than the richer semantic, temporal, and reasoning‑oriented analytics your system is now pushing forward.

References: CodingChallenge-02-10-2026.docx