Earlier quoted context omitted.
What does "DevOps is dead" mean?
That devs will no longer do ops.
DevOps is more like System Administrators doing the work of Software Engineers for half of the money.
Why Kubernetes Is the New Application Server
131–140 of 208 posts
Re: Why Kubernetes Is the New Application Server
#132Earlier quoted context omitted.
I can spin up a Kubernetes cluster in seconds using AWS, Azure or GCP. And with helm installing new applications is a pretty trivial affair. I am not disagreeing that it’s complex and a lot of buzzwords but every day the situation is getting better and better.
Easy peasy. Now try troubleshooting it.
On the cloud providers it is fully managed so nothing really to troubleshoot from the core platform perspective. The applications e.g. ingress will likely do but that's the same as if you were running on bare metal without Kubernetes.
And again the monitoring and auditing on Kubernetes is significantly better than trying to roll your own. There is detailed logs and metrics up and down the stack.
Re: Why Kubernetes Is the New Application Server
#133Earlier quoted context omitted.
Instrumentation on Kubernetes is pretty incredible albeit complex. You have host, container, application and ingress level metrics. But via the mesh networking eg LinkerD detailed metrics of how containers are talking to each other. All of which roll into a single metrics server (Prometheus) and dashboard (Grafana).
Most of the instrumentation I have found myself losing have been at the application levels. And to be clear, most of them are still somewhere, but not nearly as well polished as in services we have not on containers. (I'm also primarily talking about a bunch of internal practices at my current job.)
I can't speak to how you build your apps.
But application level metrics for example on the JVM behaves exactly the same whether it's in a container or not. You can still pull JMX metrics.
Re: Why Kubernetes Is the New Application Server
#134I feel a bit alone here. The most obvious benefit of kubernetes is that It's an API . There is definitely a tooling angle, but the core disruption that kubernetes brings to the picture is, it allows to model infrastructure as an API. Take the standard cloud application stack: Every app needs an artifact (disk image), a running service, an instance template, a group of VMs running using those templates, networking and…
That’s not a benefit to me. Is it reproducible? Keeping desired state under version control is valuable.
The state is defined in yaml manifests file which are trivial to store in Git and create templates with in Ansible.
Re: Why Kubernetes Is the New Application Server
#135Earlier quoted context omitted.
wait, is that what devops means to you? That devs are doing ops?
That is the predominant definition, so yes I would assume just that. It’s more or less a logical following of infrastructure as code, because it’s the developers who write and push those files.
I don't take Wikipedia as sacrilege, but I don't see anywhere where it says developers do ops: https://en.wikipedia.org/wiki/DevOps
Re: Why Kubernetes Is the New Application Server
#136Earlier quoted context omitted.
Seems he's essentially just predicting an increase in the division of labor between product development and infrastructure work going forward.
That's interesting, sounds like the world 5 years ago and before -- outside of the Netflix/Google/Facebook monoliths. Sounds like the landscape made systems so complicated via ease of automation that they don't know what's happening under the hood anymore. That's good news for consultants like myself. Sincerely, DevOps guy formerly known as SysEngineer formerly known as SysAdmin for 15+ years.
If you know Ansible/Puppet/Chef K8s platform doesn't require a complicated mess of scripts to manage.
Sincerly,
Platform Engineer former DevOps guy, former SysEngineer, former SysAdmin for the past 24 years.
Re: Why Kubernetes Is the New Application Server
#137Earlier quoted context omitted.
Most of the instrumentation I have found myself losing have been at the application levels. And to be clear, most of them are still somewhere, but not nearly as well polished as in services we have not on containers. (I'm also primarily talking about a bunch of internal practices at my current job.)
I can't speak to how you build your apps. But application level metrics for example on the JVM behaves exactly the same whether it's in a container or not. You can still pull JMX metrics.
Agreed, most of this is in the "how you build your apps."
Setting up all of the special networking tricks to get to the bloody JVM in a container can be annoying. Especially because I guarantee those weren't setup until they were needed.
But yeah, most of my complaint is with folks that dropped the old way of making applications because they wanted to use the new tooling. Completely missing all of the "hidden" use cases the existing applications were made with.
Re: Why Kubernetes Is the New Application Server
#138Earlier quoted context omitted.
You probably never heard or used - Linux VServer. Available from the later version of the 2.4 kernel. https://en.wikipedia.org/wiki/Linux-VServer
> 2008 FreeBSD jails date from 2000 Solaris zones date from 2004 https://us-east.manta.joyent.com/bcantrill/public/ppwl-cantr... https://us-east.manta.joyent.com/bcantrill/public/ppwl-cantr...
[deleted]
Re: Why Kubernetes Is the New Application Server
#139Earlier quoted context omitted.
I'm a former OpenShift (Red Hat's distribution of Kubernetes) consultant and currently I work at Red Hat in a different position and I have to disagree on the "won't work at all without an army of consultants". While it's true that some of our customers have an army of consultants, the vast majority of our customers don't use consulting at all or that only use it very infrequently. If you don't want a lot of customiz…
This is the same process that was done with J2EE and Application Servers, it starts out with a _simple_ standard to have a Java application served with a standard API, and then it grows out of control. You are already seeing it with Itsio and Helm being layered on top. Today you might be able to get the stock Kubernetes up without much assistance, but give it a few years as "features" get added on.
I'm not seeing that and I'm pretty sure we won't. it's extremely hard to get new features in the core of kubernetes and in fact it's moving to a micro services architecture.
Neither helm or istio are part of the core.
Re: Why Kubernetes Is the New Application Server
#140Earlier quoted context omitted.
For example, OpenShift (Kubernetes + stuff also from Red Hat) exposes this pattern like both heroku and cloud foundry by A) focusing on having standard base images controlled by ops B) encouraging combining source code / built artifacts as a layer on those base images C) giving controls to ops so that the only images users could build or run must be built with A/B above. In that mode containers are less wasteful beca…
Don't most virtualized hosts already solve the "less wasteful" point? I get that hypervisors and friends aren't bulletproof, either; but I have fewer ways to shoot yourself with those than I have with containers. More, you have to worry about the container host anyway, so you haven't removed the need to maintain a host. You've just added to it the need to maintain the rest of the container infrastructure as well as y…
Agree, virtual hosts are ubiquitous. But I don’t know that anyone loves their virtual machines the same way they love the smaller, faster, and simpler alternatives (unikernels included).
This is a somewhat pessimistic viewpoint, but lowest common denominator solutions tend to acquire the most network effects. A VM requires more touch points to manage for the person who has to set up a machine - despite ten years of solid progress, they still tend to be pretty annoying to configure and build and manage. The platform as a service approach (whether lambda, nodejs on cloudflare, various functions as a service approaches, heroku, cloud foundry, or dokku) on the other hand take away a lot more hassle by abstracting pain points out, but get accused of being too rigid. Both extremes benefit specific use cases, but have disadvantages in general purpose use.
Containers sit in the ugly, dirty, practical middle. They can do both (VMs are just processes). So the network effects they accrue just like Linux did of being “good for everything, not great” help mitigate some of the disadvantages.
The public cloud providers change this calculus a bit by offering these things as a service, but internally they are just managing the container runtimes for you.
I’m obviously biased, but I tend to see containers as “good enough” to build other abstractions on top, with specific areas where VMs and heavy PaaS abstractions clearly win.