Interoperable Clouds and How to Build (or Buy) Them
Download as PPTX, PDF0 likes218 views
This document summarizes a presentation about interoperability between OpenStack and other open source infrastructure projects like Kubernetes. It discusses how the OpenStack Interoperability Working Group defines guidelines for compatibility between different OpenStack distributions. While no distribution will be identical, following these guidelines ensures core capabilities are supported across approved implementations. It encourages selecting technologies based on common interfaces like APIs, Terraform, or Kubernetes rather than any single vendor implementation to avoid lock-in and allow flexibility.
Interoperable Clouds and How to Build (or Buy) Them
- 1. © 2014 VMware Inc. All rights reserved. Interoperable Clouds and How to Build (or Buy) Them What’s up with interop in OpenStack, K8s, and more! Mark T. Voelker Oct. 24, 2017 All Things Open 2017
- 2. Mark T. Voelker (@marktvoelker) • OpenStack Architect @ VMware, Interop Working Group co-chair, Triangle OpenStack Meetup co-founder, OpenStack Foundation Member #54, OpenStack ATC, Ex-Puppet OpenStack core dev • Fact: can be bribed with doughnuts • In copious (hah!) spare time: OpenStack solutions, Big Data, Massively Scalable Data Centers, DevOps, making sawdust with extreme prejudice, raising two great kids with my awesome wife in North Carolina • Sadly, not a real wand-carrying wizard… “A computer nerd….is somebody who uses a computer in order to use a computer.” –Douglas Adams
- 3. 3 You can virtualize network functions with it. You can orchestrate bringing up and maintaining vast distributed systems with it. Or you can just run a few VM’s for your own use on it. It scales big, it scales small. It’s used by huge companies and one-person cloud admin teams. OpenStack is incredibly powerful, flexible, feature-rich software that’s evolved to meet the needs of hundreds of use cases. You can build public offerings with it. You can hook it up to a CI/CD platform. You can run e-commerce apps on it.
- 4. 4 Likewise.
- 5. 5 Actually… doesn’t this describe an awful lot of open source infrastructure projects nowadays? And a lot of these are actually used together, right?
- 6. But this is an OpenStack talk…right? Sorta. (OpenStack is pretty magical…)
- 7. Turns out, OpenStack is often used in conjunction with a lot of other great software…I maintain that: OpenStack is most powerful with it’s friends. (so we’re going to talk about them too!)
- 8. Let’s start with a premise: Times. Have. Changed. In 2010 we’d have been having a very different conversation.
- 9. Back in the day, infrastructure was more static. Vendor A and B had totally different offerings. Choices and alternatives had high barriers to entry, lock in was severe, and changing your infrastructure often meant choosing between very different ways of doing things.
- 10. 10 One great thing about the DevOps movement : It helped us discover the magic of abstraction. Infrastructure…as code! Common API’s for multiple underpinnings.
- 11. 11 We learned to move fast. We got there by finding the Interfaces that worked for us. (there’s more than one right answer!)
- 12. 12 So, let’s say you decide on OpenStack. Great! How many ways can you get OpenStack? Pattern? Well…how many ways can you get Kubernetes? Linux? Storage with an S3 API? 35 distros & appliances 26 public clouds 17 managed offerings
- 13. The number of choices we now have when we choose a technology is great! We get to decide on what’s best for us operationally and they look, act, and feel the same to the user! ….right?
- 14. 14 def list_images(): “”” A function to list images. Because all OpenStack Powered Platforms can do that…somehow.””" if $cloud == ‘vendorA’: # TODO: this also works for vendorX list_images_via_nova_image_api() elif $cloud == ‘vendorB’: # TODO: this also worked for vendorY last week but now, um? list_images_via_glance_v1() elif $cloud == ‘vendorC’: list_images_via_glance_v2() else: # I dunno what cloud this is, but it’s OpenStack Powered! So something must work. # Resort to trial and error since we don’t know. try: list_images_via_nova_image_api() except NopeError: # D’oh, guess that wasn’t it… try: list_images_via_glance_v1() except StillNopeError: # Aww…well third time’s the charm? try: list_images_via_glance_v2() except NopeNopeNopeError: rage_quit() This function could also be called: not_winning()
- 15. 15 Somebody tested these claims of interoperability, right?!? Across versions? Across vendors? Are they actually using the same code?
- 17. 17 First let’s talk about OpenStack’s Interop Working Group. • Board of Directors working group tasked with creating interop guidelines vendors who want to call themselves “OpenStack” (using the trademark and logo) must adhere to. • Interop Guidelines must be approved by the Board, which owns trademarked assets like the name and logo.
- 18. 18 So what’s a Guideline? A list of Capabilities that products must support. A list of Tests products must pass to prove it. A list of Designated Sections of OpenStack code they must use to provide those Capabilities. Acceptably recent versions of the software that are covered.
- 19. 19 • We bake a new Guideline every six months (same as OpenStack’s release cadence). • Each Guideline covers the most recent 3 (well…and a half) releases. • Only the newest two Guidelines can be used to obtain a logo/trademark agreement with the Foundation.
- 20. 20 Some things you won’t find in Interop Guidelines: • Stuff that end users don’t see or can’t use: • Admin-only API’s • RPC API’s • DB Schema • HA Requirements • Stuff that’s intentionally pluggable: • Virt/net/storage drivers • Middlewares • Specific databases • Stuff that doesn’t have tests • Stuff that’s being deprecated (usually…more on that in a minute)
- 21. 21 How do we decide what gets in? Core Criteria.
- 22. 22 What if we get something wrong? Tests can be “flagged” (not required for the duration of the Guideline) in some cases: • Capability fails to meet Criteria (e.g. was scored incorrectly) • Test fails/is skipped due to an accepted bug in the project • Test fails/is skipped due to an accepted bug in the test • Test fails because it requires non- required Capabilities • Test reflects an implementation choice that isn’t widely deployed even though the Capability itself is.
- 23. 23 These programs offer a degree of interoperability: using a core capability? If you see the logo, it’ll work. But how do I know what’s “core” and if I’m using something besides that stuff?
- 24. 24 We really don’t want to end up back here again. Locked in. Hard to move to something else. Project might die because of it. Can’t use the tools I want.
- 25. 25 Start by asking yourself a question: What’s your interface?
- 26. 26 If you said “the API”…are you sure? Are you actually using an abstraction SDK (like jClouds or libcloud)? Are you actually using a multi-cloud orchestrator (like Terraform or Ansible)? Are you deploying workloads to containers on top of the IaaS (e.g. Kubernetes clusters)? If you said “yes” to any of those…you’re probably using a subset of the API under the hood.
- 27. 27 How will you use this cloud? API? Terraform configuration? Ansible playbook? Putting K8s on top? Do those work on your choice of cloud?
- 28. 28 Trailing indicators of adoption are often the easiest way to determine what capabilities we should be worried about. Is this capability abstracted in libcloud? Is this capability used by the Kubernetes provider for OpenStack? Is this API used by CloudFoundry OpenStack CPI? Is this capability supported by Terraform or Ansible? If so, chances are good it meets the other Criteria too.
- 29. 29 And let’s not forget that multi-cloud is a thing now too. Different apps. Different needs. Different models. Desire to split availability. Costs.
- 30. 30 It’s always going to be a balancing act: features, abstraction overhead, freedom from lock-in vs simplicity. But you’ll get there faster if you start with a known-safe starting point.
- 31. 31 So what about special use cases with unique demands? Are they bad? No, but you need to see them for what they are: special. “Given time, every sufficiently good and flexible platform trends toward specialization.” (Consider Linux…in submarines, seatback entertainment units, phones, servers, realtime applications.)
- 32. 32 These clouds may be ”special cases”… But what matters is still how you choose to interact with them. If you need to throw out your tools to work with a cloud…that’s not interoperable.
- 33. 33 OpenStack is working toward vertical programs already!
- 34. 34 Clouds are more fun with friends! Two fastest-growing consumption models I see in the field today: OpenStack + Kubernetes OpenStack for NFV
- 35. 35 Ready to learn more? • 2017.09 Guideline • 2017.01 Guideline • Next Guideline draft • Public RefStack Server • OpenStack Interop Homepage • Core Criteria • Interop WG procedural overview • Lexicon of Interop WG terms • Interop WG wiki & meeting Info • How to submit patches
- 36. 36 Look for interoperable infrastructure. Friends have more fun together. Your users will thank you. Any questions?
- 37. 37 Thank you. Let’s go make some magic. @marktvoelker markvoelker@gmail.com