Adrian Cockcroft has worked across performance engineering, large-scale cloud architecture, microservices, resilience, and sustainability at organizations including Sun Microsystems, Netflix, and AWS. His published work connects technical design with delivery speed, operational responsibility, and system-wide consequences. — Virtual Adrian Revisited as meGPT.

Visual summary of operating lessons from Adrian Cockcroft.

Part 1: Performance and System Health

  1. Performance Management: Manage Performance, or It Will Manage You! — Virtual Adrian Revisited as meGPT.
  2. Diagnosis Automation: If the system runs out of swap space, output: +++OUT OF CHEESE ERROR, PLEASE RELOAD UNIVERSE AND RESTART+++ — Virtual Adrian Revisited as meGPT.
  3. Memory Famine: Watch the page scan rate. If the kernel is scanning for free pages, you have a memory shortage, regardless of reported free RAM. — Virtual Adrian Revisited as meGPT.
  4. Performance Teams as Profit Centers: Treat performance engineering as a profit center: added specialists and tooling can generate returns far beyond their cost. — Justifying a Performance Team.

Part 2: The Evolution of Cloud Architecture

  1. Legacy Constraints: Incremental change may be good theory, but in practice you have to have a big enough stick to hit everybody with to make everything move at once. — Cloud Trends.
  2. Component Selection: Wardley Mapping helps identify the better bits of Lego you should use to build systems rather than reinventing low-level infrastructure. — Cloud Trends.
  3. Undifferentiated Lifting: Hardware provisioning is undifferentiated heavy lifting – replace it with IaaS. — Cloud Trends.
  4. Building Value: Spend your engineering hours only on the code that makes your product unique to your customers. — Cloud Trends.
  5. Leveraging Scale: Go and get your open source from the web scale companies that are investing and have the best people working for them solving distributed system problems. — Cloud Trends.
  6. Cloud Performance Value: Cloud performance improvements can reduce the next month’s bill, unlike data-center tuning that often only delays hardware purchases. — Justifying a Performance Team.

Part 3: Microservices and Decentralization

  1. Definition: A loosely coupled service-oriented architecture with bounded contexts. — InfoQ Microservices and DevOps Interview.
  2. False Microservices: If you have a bunch of small, specialized services but still have to update them together, they're not microservices. — InfoQ Microservices and DevOps Interview.
  3. Loose Coupling: Loosely coupled means that you can update the services independently; updating one service doesn't require changing any other services. — InfoQ Microservices and DevOps Interview.
  4. Emergent Design: We didn't design the architecture top-down; we discovered and formalized the architecture that emerged as engineers built what they needed. — InfoQ Microservices and DevOps Interview.
  5. Monolith Decay: Most monoliths are tangled balls of mud... as you get a large team of developers on a monolithic app, it gets harder and harder to build. — InfoQ Microservices and DevOps Interview.
  6. Business Priorities: Microservices are arguably more about business concerns than about architectural best practices. — InfoQ Microservices and DevOps Interview.
  7. Continuous Delivery: When you look at what it takes to do continuous delivery, you just end up with something that looks like microservices because you have to be able to break things into small chunks. — InfoQ Microservices and DevOps Interview.
  8. API Exclusivity: We don't have configuration, it's all program, it's all API driven. — InfoQ Microservices and DevOps Interview.
  9. Security Zoning: When you break things into microservices, you've got the ability to have some parts of your system be low-security risk and other parts be high-security risk. — InfoQ Microservices and DevOps Interview.
  10. Progression: The natural evolution of architecture goes from monoliths to microservices to functions. — InfoQ Microservices and DevOps Interview.

Part 4: Speed and Open Source Strategy

  1. the Primary Metric: Speed wins. — Fast Delivery at Scale.
  2. Executive Desires: There isn't any executive that wants his company to be slower at product development. — Fast Delivery at Scale.
  3. Synchronization: If you look at how you really speed things up, you have to take the hand-offs out of the process. — Fast Delivery at Scale.
  4. Proprietary vs Open: What's become apparent in the last few years is that the open source products are the most scalable and dependable products. — Fast Delivery at Scale.
  5. Malleability: The open source products were much more malleable. Netflix put people on the project and changed it until it did what we wanted. — Fast Delivery at Scale.
  6. Developer Geography: The best things you can get now are free. And they are built by communities and the best engineers don't work at those enterprise companies. They work for end users. — Fast Delivery at Scale.
  7. Recruitment Strategy: I was actually spending more and more time outbound at Netflix promoting the open source projects... helping people externally creates a virtuous cycle for hiring. — Fast Delivery at Scale.
  8. Ecosystem Strategy: If you need a feature, build it into the open source project so the community maintains it for you. — Fast Delivery at Scale.

Part 5: Chaos Engineering and Resilience

  1. the Core Concept: Chaos Engineering is an experiment to ensure that the impact of failures is mitigated. — Managing Failure Modes in Microservice Architectures.
  2. Failure Assumptions: Failures are going to happen all the time. They do happen all the time. It’s when your mitigation doesn’t work that you have an outage. — Managing Failure Modes in Microservice Architectures.
  3. Preventative Thinking: You can’t legislate against failure; focus on fast detection and response. — Managing Failure Modes in Microservice Architectures.
  4. the Switch Principle: If you're trying to switch between two things, the switch itself needs to be an order of magnitude more reliable than the things it's switching between. — Managing Failure Modes in Microservice Architectures.
  5. Redundancy Risks: Adding redundancy can actually decrease reliability if the failover mechanism is fragile. — Managing Failure Modes in Microservice Architectures.
  6. Testing Pipelines: Move away from annual disaster recovery tests toward continuously tested resilience integrated into the delivery pipeline. — Managing Failure Modes in Microservice Architectures.
  7. Human Chaos: Chaos engineering is not limited to infrastructure or software but can also be applied to humans during Game Days. — Managing Failure Modes in Microservice Architectures.
  8. Breaking Systems: The goal of chaos engineering is not to break things, but to build confidence in how your systems actually work. — Managing Failure Modes in Microservice Architectures.
  9. Root Causes: The last strand that breaks is not the cause of a failure! — Managing Failure Modes in Microservice Architectures.
  10. Recovery Cascades: Work amplification and hysteresis can cause a system to get stuck in a bad state where it won't recover even after the initial trigger is removed. — Managing Failure Modes in Microservice Architectures.

Part 6: Developer Responsibility and NoOps

  1. Operations Redesign: DevOps is a reorg. — InfoQ Microservices and DevOps Interview.
  2. Platform Automation: There is no ops organization involved in running our cloud, no need for the developers to interact with ops people to get things done. — InfoQ Microservices and DevOps Interview.
  3. Terminology: I think that's different to the way most DevOps places run... so it needs its own name, NoOps. — InfoQ Microservices and DevOps Interview.
  4. Production Ownership: You build it, you run it. — InfoQ Microservices and DevOps Interview.
  5. Training Focus: We taught our developers to operate rather than teaching our operators to develop. — InfoQ Microservices and DevOps Interview.
  6. Friction Removal: The goal is to remove the meetings between developers and operations, allowing for extreme speed and agility. — InfoQ Microservices and DevOps Interview.
  7. Developer Gatekeeping: Get out of the way of your developers or lose them to someone who will. — InfoQ Microservices and DevOps Interview.
  8. Observability: Observability is the foundation of resilience; you cannot run a chaos experiment if you cannot see the steady state of your system. — InfoQ Microservices and DevOps Interview.
  9. Self-Service: Instead of filing tickets, developers must use automated tools to deploy code and manage capacity in seconds. — InfoQ Microservices and DevOps Interview.
  10. True Code Reliability: For production code, ‘mostly implemented’ is a failure, not an acceptable intermediate result. — Measuring AI Coding Reliability.
  11. Model Upgrades: Premium frontier models are wasteful for routine work but may determine whether genuinely difficult work ships or must be rewritten. — Measuring AI Coding Reliability.
  12. Human vs Agentic Coding: Experienced engineering managers can direct coding agents and iterate faster than delegating the same work to skilled humans. — Directing AI-Native Development.
  13. Evaluating Developer Tooling: Simple AI coding benchmarks miss engineering reality because they ignore language choice, multi-file architecture, task shape, and reliability over time. — Measuring AI Coding Reliability.

Part 7: Organizational Culture and Trust

  1. Hiring vs Environment: We hired them from you, and got out of their way. — Fast Delivery at Scale.
  2. Default Culture: If you are building a startup, be extremely intentional about the culture... because culture will just happen to you. — Fast Delivery at Scale.
  3. Organizational Design: High trust, low process, no hand-offs. — Fast Delivery at Scale.
  4. Decision Making: Don't move information to authority, move authority to the information. — Fast Delivery at Scale.
  5. Leadership Approach: Inspire them with a purpose, and then get out of their way. — Fast Delivery at Scale.
  6. Availability Theater: Availability Theater is the practice of building complex failover systems that are never actually tested. — Fast Delivery at Scale.
  7. Systemic Outcomes: Organizations must reorganize around outcomes and rebuild their systems using tools that increasingly help build themselves. — Purpose-Driven Agent-Based Developer Management.
  8. Zero-Human Companies: Agent-driven companies may operate without traditional middle management, coordinating teams of agents around business outcomes. — Entering NoMan’s Land.
  9. Organizational Baggage: Existing organizations may struggle to become agent-native because structural baggage creates an opening for companies built from scratch. — Entering NoMan’s Land.
  10. Hiring Performance Engineers: Performance engineers are specialists whom conventional developer-oriented hiring processes can screen out. — Justifying a Performance Team.

Part 8: Serverless and Sustainability

  1. the Serverless Reset: Serverless app development isn't an incremental change, it's a complete reset in terms of the speed and cost and scalability of what can be built. — Cloud Trends.
  2. the True Impact of Cloud: If the way we all architect makes it easier to deploy less total capacity, then we are helping to reduce the carbon footprint of the computing industry. — Measuring Carbon Is Not Enough.
  3. Optimization Fallacies: Optimizing your own workloads by moving them around without reducing total capacity just increases the carbon footprint over-all for the computing industry. — Measuring Carbon Is Not Enough.
  4. Hidden Carbon: Just because the carbon emissions aren't charged to your account, it doesn't make them go away. — Measuring Carbon Is Not Enough.
  5. Efficient Defaults: Minimize your total footprint where possible, and use the spot market price as a guide for when to run workloads. — Measuring Carbon Is Not Enough.
  6. The Cost of Action: Doing things consumes time and energy and has a carbon footprint of its own. — Measuring Carbon Is Not Enough.