- Buzz: An Extensible Programming Language for Self-Organizing Heterogeneous Robot Swarms (arXiv) — Swarm-based primitives allow for the dynamic management of robot teams, and for sharing information globally across the swarm. Self-organization stems from the completely decentralized mechanisms upon which the Buzz run-time platform is based. The language can be extended to add new primitives (thus supporting heterogeneous robot swarms), and its run-time platform is designed to be laid on top of other frameworks, such as Robot Operating System.
- Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network (PDF) — Our datacenter networks run at dozens of sites across the planet, scaling in capacity by 100x over 10 years to more than 1Pbps of bisection bandwidth. Wow, their Wi-Fi must be AMAZING!
- Nokia’s VR Ambitions Could Restore Its Tech Lustre (Bloomberg) — the VR ecosystem map is super-interesting.
- Visualising GoogleNet Classes — fascinating to see squirrel monkeys and basset hounds emerge from nothing. It’s so tempting to say, “this is what the machine sees in its mind when it thinks of basset hounds,” even though Boring Brain says, “that’s bollocks and you know it!”
Designing, building, and operating services from the perspective of customer goals helps improve quality.
We often tend to think about “usability” as applying to a separate layer of digital service from functionality or operability. We treat it as a characteristic of an interface which intermediates between the user and an application’s utility. Operational concerns such as performance, resilience, or security are even further removed. This approach gets reflected in siloed design-development-operations practices. From the perspective of service quality, though, I think it may be more constructive to view usability as a characteristic of service as a whole.
What is service, anyway? In the language of service-dominant logic, it’s something that helps a customer accomplish a job-to-be-done. From that perspective, usability refers to the customer’s ability to ‘use’ the service to accomplish their goals. Everything that contributes to, or compromises, that ability, impacts usability.
Why you should stop managing infrastructure and start really programming it.
Immutable infrastructure (II) provides stability, efficiency, and fidelity to your applications through automation and the use of successful patterns from programming. No rigorous or standardized definition of immutable infrastructure exists yet, but the basic idea is that you create and operate your infrastructure using the programming concept of immutability: once you instantiate something, you never change it. Instead, you replace it with another instance to make changes or ensure proper behavior.
Chad Fowler coined the term “immutable infrastructure” in a 2013 blog post, “Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components,” but others have spoken about similar ideas. Martin Fowler described phoenix servers in 2012. Greg Orzell, James Carr, Kief Morris, and Ben Butler-Cole, to name a few, have contributed significant thought and work as well.
II requires full automation of your runtime environment. This is only possible in compute environments that have an API over all aspects of configuration and monitoring. Therefore, II can be fully realized only in true cloud environments. It is possible to realize some benefits of II with partial implementations, but the true benefits of efficiency and resiliency are realized with thorough implementation.