141–150 of 208 posts
Earlier quoted context omitted.
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
Earlier quoted context omitted.
That devs will no longer do ops.
It's more like experienced devs doing ops in support of devs. As with most terms like this ymmv.
I 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.
We could probably bootstrap our entire product from scratch in a couple of hours if it disappeared off the face of earth.
“Infrastucture as a config” is a very powerful concept. I’d say that’s what the big power of k8s is.
It is hard not to build this impression of containers. Worse, it seems that the docker image format is massive compared to what most war files were like. This is annoying not just in terms of raw bytes to move around, but in taking stock of what is getting moved around. My team originally pitched how docker solved much of the dependency upgrade management by having layers for each major set of dependencies. That igno…
the linux world is slowly (and badly) recreating technology that has existed in FreeBSD and Solaris/Illumos for decades.
Earlier quoted context omitted.
They are the shit tech that will be abandoned with the next fad. They are a huge boondoggle, solely for the immature leads who have not been coding for decades and know better. This industry is filled with stupid fucks that don't know tech history.
It's not that. The tech is not a solution for everyone's problems to begin with. It's a purely commercial tech made in an attempt to compete with Amazon and sell you stuff. It's very lock-iny, expensive to leave and is crippled on purpose, to make you buy services from Google. Barrier of entry for competition is high too, so it will be pricey.
Earlier quoted context omitted.
Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations) But more broadly, Kubernetes in the hands of most developers that are doing non-platform level work is a step backwards and will be disastrous. It's far too low level, it's like, hey this Python…
>Your broader point is correct but I think you're mischaracterizing Devops You are right. What I should have said is that using DevOps as an excuse to make application developers do complex infrastructure design, automation and maintainance as a side-job is an unsustainable practice.
I 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…
Before: Write HCL then run `terraform apply` After: Write YAML then run `kubectl apply` ;-)
https://www.terraform.io/docs/providers/kubernetes/index.htm...
I would say Kubernetes is becoming the new Application Server, but not for anything listed in the article. Kubernetes is more and more being sold to "enterprise" as a solution for running services much like Application servers were, and much like application servers the standard Kubernetes deployment is becoming a tangled mess of buzzwords and dreams, which work great in a demo, but won't work at all without an army…
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…
Are you asserting that any modern production environment that takes less than 2 months to set up is bound to cause problems? Or the whole company/startup/project?
If the former, I'd say there are many tech startups who would disagree, or at the very least, point out that it doesn't matter because they'd cease to exist during those 2 months without an MVP in production.
Earlier quoted context omitted.
Another prediction in 5 to 10 years infrastructure will be so streamlined, so that developers won't need to think it at all. I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise.
"I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise." As someone trying to be primarily a dev who keeps getting roped into doing ops stuff for deploying my stuff, my experience is the exact opposite, and in particular putting Kubernetes on the…
Those "all kinds of reasons" aren't necessarily valid, though, because it's not actually possible to go back to that caricature of the past that you describe.
The reason it's not possible is that some things actually have gotten simpler, at least from a user's perspective.
Automatic bad-block relocation has been standard for effectively forever. Even line-speed hardware RAID has been affordable for so long that it's not even a question. Hardware, in general, is routinely villified as being a nightmare, when the reality is that it's boringly reliable and, more importantly, has predictable enough failure rates that there are simple, standard engineering solutions around the failures (often already baked in).
That "inflection point" may well just end up being peeling away all the abstraction layers to discover that simplicity underneath works just fine, since we don't live in the 20th century any more.
At least 50% of the neckbeard kvetching about containers is because they don't want to let go of their lovingly hand-crafted servers and mountains of bash scripts and config management crap that they've built over the past 20 years. edit: btw, I'm one of those (former) neckbeards...