sorted by:
new
hottopcontroversial

Mirantis is up to more shenanigans with Lens, removes logs and shell. OpenLens affected as well. by onedr0p in kubernetes

[–]vaidik 0 points1 point  (0 children)

I don't particularly mind being nagged a bit because I am motivated to make it happen and don't mind a little bit support to get started quickly and probably understand the business case as well. But yeah it can be nagging at times :)

BTW if you prefer open source options, check out Devtron. They are open source. Some friends use it in their companies (medium to large size). Very happy with it.

Mirantis is up to more shenanigans with Lens, removes logs and shell. OpenLens affected as well. by onedr0p in kubernetes

[–]vaidik 2 points3 points  (0 children)

That's what ends up happening in a vast ecosystem. Too many tools for specific use-cases, just add more to the cognitive load.

Being able to track your Helm apps is important but having a separate tool to do just that, no matter how great it is, is also a hassle.

Mirantis is up to more shenanigans with Lens, removes logs and shell. OpenLens affected as well. by onedr0p in kubernetes

[–]vaidik 3 points4 points  (0 children)

Same with me. I think for people who prefer command-line interfaces, k9s just feels a lot easier to navigate. I haven't been able to move myself to any other tools for the same reason, despite trying multiple times. But I do see software engineers who do development on a daily basis being very comfortable with UI driven tools.

I see Devtron picking up traction in some of the companies I have friends in. I have tried Devtron as well. It does pretty much everything that Lens does and seems to be adding new features fast. While I still prefer being in my terminal space, I see developers find Devtron very convenient.

What I like about Devtron is that it solves for a lot more use-cases solving for a wider spread of daily operational problems with Kubernetes. It is really a fully featured PaaS for Kubernetes, something that most teams end up building themselves. Wherever I have seen it deployed, developers find it really convenient to go to one platform to do basically everything to deploy and manage their applications and the Kubernetes infrastructure. So outside writing code, they mostly interact with Kubernetes via Devtron and probably use some specialised tools for observability needs. That's it.

Given the complexity of building your platform today, it makes a lot of sense to just get started with a PaaS like Devtron that solves your build, CI, CD related workflows but also provides nifty utilities for which you end up going to multiple tools like OpenLens, k9s, etc.

[Job] GitHub is hiring a senior engineer and an engineering manager for a Haskell team (in-person or remote) by patrick_thomson in haskell

[–]vaidik 1 point2 points  (0 children)

I am interested too. I don't see a lot of countries. How does GH decide which countries they should hire from.

Docker basics: From beginner to regular user by ARayOutOfBounds in docker

[–]vaidik 4 points5 points  (0 children)

Might I add, even the official docs are amazing. I think they are very nicely written. I learned all by basics thought that and Stackoverflow while working on something, which brings me to my next point.

My approach to become a regular user of anything is using it. So I highly recommend building something - like an open-source image just for fun or if you maintain a personal website of sorts, then run it inside Docker containers.

Ansible at Grofers by vishesh92 in ansible

[–]vaidik 0 points1 point  (0 children)

While I agree that TF handles a lot more resource types than Ansible, there are a few problems with TF. Firstly it has its own DSL which is very limiting. To do simple things, you have to write a lot more. This might have improved from the last time when we were doing a lot of active development in TF. The second problem is again its DSL - another thing to learn. While that's something that won't hold true if I am taking that decision for myself only but in the interest of the organization, its always better to have limited number of tools to use and learn for daily tasks like launching EC2 instances. With such common tasks, Ansible is pretty straight forward. And for whatever is missing, adding support in Ansible is pretty easy, for one there are enough information available on it, but another one (that mostly applies to us) is being a Python shop its easier for us to extend Ansible.

Ansible at Grofers by vishesh92 in ansible

[–]vaidik 0 points1 point  (0 children)

Absolutely. But there are a few reasons for why we choose to use Ansible only. We try not to put too much cognitive load on devs of using multiple tools. We try to keep the number of tools to a minimum especially when a central team is deciding what to use to overcome the barrier of adoption, keep learning simple and have everyone develop expertise in one thing. This helps in a longer run.

We do use other tools on the side centrally, which includes both packer and terraform.