Kubernetes

thanks John and all the other participants. Good fun. See you all at KubeCon!

@gabrtv thanks for your time we really appreciate it and hope we can keep the open community chat an upstream vibe

Thank you all for the dialogue. See you at #kubecon! @furrier, @stu, @Thockin @gabrtv @Dee_Marketing @sarbjeetjohal @lcooney

There's an interesting reflection in here that I've found to split #devops into those that don't understand K8s and consider it risky to use as an app's foundation and those that understand that K8s (and surrounding immutable, Infra as Code concepts) actually DERISK deployments

K8s takes #DevOps to the next level by ensuring that CI/CD tools and repositories can manage microservices that can be pushed to the broadest cross-platform cloud-to-edge application platforms. It's the orchestration pipeline for all that.

I don't think any technology takes #DevOps to any level. In regards to K8, I think its adoption drives home the core principles of DevOps to continuously learn, collab more, and practice systems thinking

#devops is a practice that focuses on the business problem first. Focus on that, if #k8s can help you great, but it is not necessary. Culture and Automation of your software lifecycle are first pre-requisites. #k8s can boost your efforts and give you an additional gear.

@madgreek65 great point #devops is the next level;

it accelerates CD part or of #DevOps. Rest of the DeOps pieces remain pretty much untouched. BTW a side effect is that it forces you to think more in #Microservices terms which is good for DevOps paradigm.

offering K8s as a developer "service" is easier than offering static VM on demand or via help desk "ticket and wait".

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....