All Cloud Native Everything
At VMworld 2017 we announced our joint venture with Pivotal, PKS to deliver Kubernetes to the enterprise, fully integrated with the VMware platform. This announcement solidifies that Kubernetes is a HUGE part of VMware's identity moving forward. For those of you completely unfamiliar with Kubernetes, the most popular container scheduling and orchestration platform by far, I suggest you study up. It's going to be a big deal moving forward!
<img src=”/images/2017-10-08-kubernetes-vio/pks.jpg#center” alt="Pivotal Container Service” style="width 700px”;>
PKS is still being developed for primetime and in the meantime, we had a different Kubernetes release GA. VMware Integrated OpenStack Kubernetes,or VIOK for short. When I first heard about this I thought “I'm a huge OpenStack hater. I don't want to deal with OpenStack just to get Kubernetes up and running” but I was pleasantly surprised! One of the major benefits of the VIOK offering is that users don't have to use native OpenStack at all! It's running in the backgroud, in a series of containers, but ultimately that integration is just there to tie into your existing VMware environment. You can deploy your K8s clusters independently of OpenStack from an easy to consume user interface!
<img src=”/images/2017-10-08-kubernetes-vio/viok.JPG#center” alt="VIOK” style="width 700px”;>
Another incredible callout is the integrations between VIOK and our NSX platform; allowing users to receive an external URL to hit their services without having to build an Ingress Controller themselves. It's pretty cool for someone getting started. Long term I don't see ingress controller's going away, as they are the “right” way to go - but I appreciate the integrations nonetheless!
<img src=”/images/2017-10-08-kubernetes-vio/nsxlb-viok.JPG#center” alt="NSX Integration” style="width 700px”;>
Function as a Service
With all of the work with Amazon Echo and API Integration, I'm constantly looking for more efficient ways to leverage API's to pull data out. I started off running API calls natively on my desktop with the “Alexa Server” running. This wasn't scalable, so I built “Gideon” and threw it into a container that handled both Alexa's “logic” as well as handled running python driven API calls over REST.
This was cool; but I didn't like the idea that I was still basically running a server. THERE HAS TO BE A BETTER WAY! I had been exposed to “Serverless” previously (yes, I'm aware serverless just means running on someone elses hardware - but there is A LOT more to serverless than that…); but when I found a series of tools to get my python code running in lambda easy (Zappa); I was thrilled. I started reengineering on my on-premises container into a simple API gateway. I was happier with this approach - but it still felt odd. I was running a lightweight container 24/7 just to act as an easy API gateway.
And then I discovered Function as a Service, specifically OpenFaaS.
<img src=”/images/2017-10-08-kubernetes-vio/faas-netes.jpg#center” alt="FaaS Netes” style="width 700px”;>
Alex Ellis has done an incredible job building up the OpenFaaS community and has gotten a ton of notoriety in the Docker space. The project has eclipsed 6,000 stars on github and isn't showing any signs of slowing down. OpenFaaS deploys on Docker Swarm or Kubernetes and provides a gateway to load functions (which run on-demand, in containers) and return their values via a browser or curl. It'll automatically scale based on load. It supports a number of languages; but most notably for me - Python and NodeJS. Containers are managed and when load reduces - extra ones are destroyed.
<img src=”/images/2017-10-08-kubernetes-vio/kubernetes-dashboard-faas.JPG#center” alt="K8s Dashboard” style="width 700px”;>
This was the holy grail of solutions for me. I love the modular approach of treating each call as an individual function - and wiring them up to their own container. It lets me add new functions without potentially impacting existing code. It also enables some pretty incredible scaling options when partnered with Kubernetes.
<img src=”/images/2017-10-08-kubernetes-vio/openfaas-portal.JPG#center” alt="OpenFaaS portal” style="width 700px”;>
On top of the native functions, Alex has built a pretty awesome monitoring interface in using Prometheus to monitor and track container utilization. It's an incredible platform, absolutely worth checking out!
So What's This Speed Round?
I had this fun idea for the vBrownBag community. With the current scheduled programming being knee deep in API's, I thought this was a great opportunity to jump in and do something fun and different.
On 10/10 I'll be participating in an off schedule vBrownBag “speed-round”. vBrownBags are an hour typically; so we're going to see how much I can cram into one!
I will be taking an empty vSphere Integrated OpenStack Kubernetes cluster, and deploying OpenFaaS on it. In it's normal state, it deploys to single node, behind a port. Traditional Docker configuration. From there, I will set the replicas to a higher number - and show the cluster automatically expand to more nodes. Thats cool - but really just gives us 4 different IPs to hit for a service; so we'll be changing it to a LoadBalancer and watching as VIOK deploys an NSX LoadBalancer for the cluster. From there, we will deploy the OpenFaaS functions, and demonstrate hitting on premises API's with the platform. I'll then hit it with some load, and show how OpenFaaS scales to support the load.
If I haven't completely destroyed my environment by then…I'll be opening up the API externally, and let all the people participating in the webinar smash the API with load too. The goal is to crash it!
What Are Participants Going to Get Out Of This?
Really it's about exposing the concepts of Function as a Service and API consuption. On-Premises function as a service is something that doesn't get a lot of attention in the enterprise, although it is starting; people with keen ears may have heard this mentioned during the VMworld 2017 opening keynote. I see the FAAS concept as something that really builds the case for containers in the enterprise, and being someone who's very tied to compliance requirements (my market is State and Local Governments), there are reasons why some stuff will never make it into the public cloud. With FAAS - the idea of building complex functions to return data or perform actions via a simple URL call has the potential of drastically changing and simplifying existing workloads.
I hope you can make it; be sure to check out the vBrownBag community here, and tune in on 10/10 at 5:30pm Pacific Time to have some fun!