James Higginbotham

API Architect

#GlueCon 2014 Keynote: Automation and DevOps: How to Create a Lights-Out Software Defined Data Center – Joshua McKenty, Piston Cloud Computing

2 minute read

Keynote: Automation and DevOps: How to Create a Lights-Out Software Defined Data Center – Joshua McKenty, Piston Cloud Computing

  • Thinking about SDKs makes us think about consuming APIs that we build
  • The OpenStack APIs were bad not because they didn’t go API First, but rather that they used SDKs to mask the bad API designs
  • Affordances is a term usually used in the design of the physical objects (i.e. message that the object gives on how to use it – door handle to indicate push vs. pull)
  • Jobs designed user experience by the number of quarters required to learn an arcade game. He then set the bar for Mac at one quarter
  • The API isn’t the natural extension of your code, but it is a product
  • The first affordance of the PC era was the Apple computer (Typewriter in front of a television) because it allowed software to be built without being a hardware engineer
    • Before that time, you had to be a hardware engineer to build software as you had to understand what was under the hood
  • The cloud today is similar – we require software developers to know about how the cloud works
  • If you are desiging an API, you should expose the capabilities (e.g. a Duck), not the internal details (e.g. a Duck’s gizzard). No gizzard APIs!
  • This requires the developer’s mental model to be the same as the user’s mental model
  • A REST API isn’t for exposing objects, it is for exposing resources. An object is the developer’s problem, the resource is the user’s problem
  • Write the Duck API first
  • To have a great API, you much fearlessly change the product underneath to match what the API offers (e.g. No Duck APIs for a Water Buffalo implementation)
  • Jobs/Wozniak changed the way the computer worked. No blinking lights that had to be understood
  • If you are addicted to the details of how the infrastructure is setup, you will never focus on the Duck API
  • Current platform-as-a-service offerings are a combination of different animal parts, so we aren’t there yet
  • During innovation, you need composability; as eco-systems mature, there is a natural convergence of function so that a larger audience an use them
  • The Mobility Gap
    • Like making a pizza in the 1500s: flour on the counter, cheese at the cheese shop nearby, tomatoes in the new world months away
    • Time Scale of System Latencies: https://twitter.com/PieCalculus/status/459485747842523136
    • You can’t do cloud computing on the edge (i.e. far away), your mobility gap is huge
    • Therefore you can’t build a Duck API if there is a huge latency to make it work
  • The “Yes, and…” (from improv) is true for IT – mainframes won’t go away (legacy and modern), PaaS and IaaS, automation and humans (high value, high intelligence, automate the rest)
  • This means we will have open and closed systems – not everything will be open source and can’t be (Open source with commercial offerings)
  • OpenStack is “Yes, and…” with commercial offerings
  • CloudFoundry is “Yes, and…”
  • Being stuck in the details causes the Not Invented Here sydrome, creating lots of things that are good at something and bad at others but aren’t focused on “Yes, and…”
  • Challenge: try to make your product that solves their problem and doesn’t expose your internal problems, avoiding details, and providing affordanes

You May Also Enjoy