#GlueCon 2014 Keynote: Automation and DevOps: How to Create a Lights-Out Software Defined Data Center – Joshua McKenty, Piston Cloud Computing
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
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