Why Kubernetes for developers? Velocity

Ryan Jarvinen makes a very good point in his talk that Kubernetes is often pitched at operations and developers may have harder time seeing the benefits it might bring. So that is the focus on his very interesting talk.

Q: Why Kubernetes?
A: Development Velocity

https://www.youtube.com/watch?v=_W6O_pfA00s

Summary and highlights - and plenty of commentary from me that's not included in the talk itself:

• Kube doesn't really have a specific term to offer to the question "So what is an app here?"
• Much of the terminology is centered around subjects that are more architecture and ops related than what a traditional developer working at the level of lines of code and classes is used to considering: load balancing, high availability, standardized terminology & packaging, scaling automation, delivery automation
• Of course I personally think that these all should be part of every developer's considerations. I'm a strong proponent of the full-stack mentality, devops and the most radical form NoOps - I see a future where separate development and ops organizations are combined - the need for that separation simply won't serve any purpose anymore. This is already happening in some companies
• With NoOps there will still be need for centralized platform and tooling administration. In SAFe (scaled agile) terminology this is often known as the Systems team
• Convincing the team with minimal onboarding:
• Getting started is easy (assuming the platform, reference models and some samples are in place)
• Share what you know, be very explicit about and document data flows at low level (read-only, write-only folder, database, integrations)
• Everyone will have local Kube installation. 
• Minikube is recommended in the talk but K3S is a more modern and lighter-weight alternative and even better options are cooking
• Typical container adoption path:
• Docker
• Volumes, PVs
• Minikube
• K8S modeling and scalability via spec files, pods and other abstractions
• Charts, OpenShift templates, or hand-rolled manifest / spec templating
• Monocular, kubeapps, ServiceCatalog
• PaaS?
• Draft - easy way to get started. A tool for developers to create cloud-native applications on Kubernetes
• https://draft.sh/
• Initial impression on a bit of googling is that this is essentially some kind of simple automated lift & shift packaging?
• Charts - packaging format for Helm, essentially a Kube package management system
• Question for myself and for later: what is the role of these in a high-quality enterprise environment? External public repos to get pre-packaged software components sounds like security and compliance nightmare - and would require extremely good practices inside the Kube cluster RBAC-wise.
• Probably somewhat analogous to the traditional Maven dependency approach of internally hosting package repo with pre-approved (or with reactive stance with lightweight-enough process) packages.
• Telepresence - make externally hosted services appear as if they were part of the local cluster (quite important for local development)
• Another approach to this is using service mesh. All service communication happens via the mesh so it would be conceivable that you could be running individual pod in isolation and virtually connect it as part of a shared dev cluster (the service's "local" database included) that's externally hosted. This idea was pitched in a discussion a while ago and I haven't seen it used anywhere yet
• Anyway these two approaches seem similar at high functional level but very likely many devils in the details
• Minishift - OpenShift variant of Minikube
• By default more secure multi-tenant enable Kube environment
• Good practice: you shouldn't be running containers as root in production so why do it in dev? A good security best practice to go rootless containers by default
• Learning resource link collection:
• Kubernetes.io Tutorials: https://kubernetes.io/docs/tutorials
• Katacoda: https://katacoda.com/courses/kubernetes
• RyanJ's K8S-workshops: http://bit.ly/k8s-workshops
• Interactive learning for OpenShift: http://learn.openshift.com
• On roles: for architects: figure out who owns manifest creation, maintenance and distribution
• Current self-note: this should be shared responsibility in the same way that each team owns their own stuff
• But how will the common policy enforcement function considering that it's very often suggested that companies go with shared clusters with namespace-per-team
• Likely answer is Open policy agent but I haven't drilled down to details on this yet
• Agree on RBAC, config and secrets management, secret rotation policies, monitoring etc. with security & compliance teams

Quote pick - this just resonated with me "The future is already here - it's just not very evenly distributed." (W. Gibson)

• Consider for example how people use the internet. Some do actually use it as an amazing resource for learning almost anything - and mostly for free! And then the impression I get from mass usage is of social media flamewars and cat videos. This creates an ever-widening skills and understanding gap which reflects to not only development but a variety of societal aspects, politics etc. But I'll not get too much off-track on this, topic for another time, for another blog.

The talk itself didn't actually directly provide background for the answer of why Kube improves development velocity so here's my take on it (based on yet light experience with Kube - this is very much still the beginning of the personal journey):

• Kubernetes with service mesh takes care of many of the non-functional requirements that would otherwise have to be manually considered in the service implementation e.g. high availability, functional failover, health and readiness checks, multiple instance message routing, service discovery, etc.
• While you'd think companies would have good reference models to provide these recurring cross-cutting concerns etc. this is rarely the case in my experience
• Reduces exit costs and effort in case a specific cloud platform becomes too pricy and we want to move applications on another platform
• Also the same development experience translates much better between different cloud and on-prem platforms when all have the shared Kubernetes layer - and this is not a low level platform but provides plenty of tooling at the level where developers actually work at
• Also makes it easier to rotate between different teams within a company for variety
• And also provides relevant experience on interesting tech and improves developers' motivation by letting them develop with modern tooling
• Brings cloud native development approach's benefits to on-premise hosted environments as well
• Together with the platform-agnosticism enables development teams to create truly agile devops pipelines
• Promotes good and secure development practices by highly emphasizing segregated, stateless services, enabling lightweight tooling for creating, maintaining and monitoring microservice architectures where it's truly possible to separate different concerns into separate services without creating a manual maintenance hell for your company

In short Kubernetes is the tool that finally enables actual microservice architectures to be created without burying yourself in maintenance overhead from manually administering the large web of tiny services where complexity has been simply moved from code level to the architectural level.