Kubernetes

promotion note: We are looking for community submissions for guests we MUST interview. @gabrtv @Thockin @sebgoa definitely we want who else? #signalfromthenoise

@furrier Will send you a note ;)

try to convince @CatalinCirstoiu to talk to you :)

@gabrtv this is a pivot off your other comment

The higher the abstraction you can use, the better off you will be (in general). KNative embraces the idea, while giving you a pretty clean escape hatch between abstractions.

It is not a one vs the other question. k8s is the perfect foundation for systems. Serverless (FaaS if you prefer) on k8s makes perfect sense. Start by working on your dev pipeline, automation, CD. Then choose the abstraction that makes sense for you

of course it isn't a zero-sum game. #k8s has a much easier tie to existing applications and path to modernization. #serverless is powerful for changing the way to build and operate applications. And there are overlap between these options.

google does 90%+ of their core work launching millions of containers a week. They mastered the container management and wrote #Kubernetes. It’s time tested (I believe you question is around reliability).

the problem with functions for developers is that the runtimes can be very restrictive, and dropping down to container abstraction often makes sense. there is no right/wrong answer, it depends on the workload.

@sarbjeetjohal It's important to note that withing Google we have built many frameworks that offer higher levels of abstraction :) Relatively few people use Borg directly.

also important to note that the virtual kubelet enables use of containers with micro-billing and invisible VMs -- two of the key value props of functions. not everyone needs/wants an event-driven programming model -- but if you do, go with functions!

in terms of serverless open source though, I would bet on knative: leverages Istio and uses CRD to bring in the necessary API for function based workloads

you can’t compare container with the content John!

Nodeless (or "less node") Kubernetes as a concept is where we really want to go. Users should not be encumbered by thinking about cluster shapes, as much as possible. Borg has nodes but most users never ever interact with them.

@thockin One of the GKE features I like best is auto-everything. I never worry about node upgrades, repairs, or provisioning in the clusters I run.

"Nodeless" sounds like an upcoming serverless project that both hates on Nodejs as a core mantra.

@sarbjeetjohal agree payload matters but with state things get very interesting

@lcalcote Hahah. I hold no opinion on Node.js.

@thockin lol this app is written in node

Multi-cluster and multi-cloud require a control plane of their own, I agree. Policy is not a cluster-scoped concept.

you can monitor performance and use #multicloud where it makes sense.

microservices, machine learning, IoT, and app modernization are all popular use cases on AKS.

@gabrtv Use cases you have detail about? We need more detail v big picture & real world v petri tray. Would love to hear more. I want to hear about deployment v lab testing etc.

Swiss Rail (selling morning train tickets), Amadeus (scaling travel booking requests), Hilton (digital key for your room on mobile), UPS (managing logistics at the edge), Deutsche Bank / Barclays (internal App-PaaS), BMW (apps in new cars)

Anyone remember Pokemon Go?

@bgracely Yes, this. More of this. Tangibility helpful

@lcooney we're very lucky to host many customers that tell their stories, just do a search on "OpenShift Commons Gathering" on YouTube. the good and the bad.

Multicloud is totally doable, if you are willing to live in the portable space of Kubernetes. I still see too many gaps where people "pop the hood" and break portability. The tooling and UX around multi-cluster, hybrid, and multi-cloud is still nascent.

as long as you package applications which adhere to #k8s standards, you can deploy them anywhere. Having said that, disparities in periphery makes such portability dreams ‘little’ hard to realize. Storage IOPs and Network speeds vary across providers.

agree multicloud is do-able, but things like cluster federation are still a ways off. don't get too clever: use separate clusters, separate CI pipelines, minimize east/west flows, and use proven tech like geo-dns. also k8s won't magically replicate your data tier :)

Multicloud is doable if every cloud has a K8s backplane, all the disparate K8s backplane are interoperable via mesh, there's a graph notation language for specifying high-level business logic, a cross-K8x compiler, end-to-end trust, & common DevOps.

(edited)

i predict this will be a huge driver of k8s usage in the months and years to come -- especially after windows container support GA's in upstream kubernetes.

God damn typos!

yes. we are seeing a lag in older apps re-inventing themselves to be cloud native/k8s compatible

I see customers loving containers for older workloads bc they know the concept of containers; it's been around IT for years

We get a lot of interest in modernization-with-recompilation. Containers allow things like decoupling from OS management. Meshes like Istio enable automagic visibility and network mapping. I think that's exciting stuff.

we see plenty of customers that lift & shift existing applications already on Linux over to containers.

@thockin I think that that comment is not yet understood in the market and it's the the gamechanger imo that is the future bigtime value if done right

@bgracely Would love to hear more about the "lift & shift" as I'm a big believer in it.. just haven't heard that we're there yet. Examples would be awesome.

@furrier @thockin truly. Should developers become comfortable with relying on service meshes, more than visibility and control, there's much potential for aspects of application functionality to be leveraged from service meshes. Gave an example in this book - https://blog.gingerg...

@lcooney Volvo is a nice example of that lift & shift that benefitted from multi-cloud, https://www.youtube....

Perhaps, it's the ability to enable tenants with enough ability to self-service, but sans the ability to bring the cluster down.

(1) dealing with Kubernetes frequent updates, (2) constantly having to wire in all the additional pieces beyond Kubernetes to get it into production (network, storage, Ops tools, CI/CD pipelines, etc.), (3) re-educating people within their organization on the system

@lcalcote Agree - "tenancy" and "isolation" are important to ~everyone, but hard to define - they mean something different to ~everyone, too.

slicing and dicing of k8s clusters (the usage tracking) and budgeting/billing related to that. Sort of SCM of Kubernetes clusters is the hard part. It’s basically a Cloud within #Cloud

Wading through the sprawling set of concepts, tools, extensions, add-ons, proxies, objects, packaging, storage, policy, configuration, networking, and administration options that K8s includes.

@jameskobielus good call out. There are many new constructs and concepts for Kubernetes newcomers to learn.

standing up k8s is easy these days. the challenge has moved to how to empower software teams and business units who will be consuming the platform, with an eye toward security, compliance, and other internal processes.

@sarbjeetjohal Agree on usage. It's something we've been working on some, because we hear it a lot.

there is still a lot of cultural friction in a lot of companies that prevent them from being very agile and leverage containers and k8s. A cultural shift towards "Devops" is needed before you can take full advantage of k8s