What Do Developers Really Need (And How Can Ops Help)?

[@DevOpsToolkit]

What do you think developers need? IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), KZbin tends to delete comments that contain links. Please exclude from the links to ensure that your comments are not removed.

[@fastest1321]

I've never seen content this good holy, thank you

[@ezklio4329]

Your content is gold. You are like my personal mentor!

[@ezklio4329]

You are the best source of devops knowledge on the Internet!

[@sumedhrana21]

Very informative and rightly put together all the points.

[@justjase1576]

Nice video with straight to the point info that I found very useful, as I do not yet use all of those recommendations. I will take a look. Thanks Victor. :)

[@gaborbaksa4690]

As a govermental SRE, my wish is a magical tool, which can translate our countless laws and regulations into yaml. :)

[@DudeSkinnyTall]

As banking/fintech industry devops I wish for the same to be implemented in regards to our countless security measures, policies and protocols. As a cherry on top, someone please make all this automagic work in "air-gapped" environments. :)

[@Blizter47]

I don't know for what Government you for. Here is a presentation of someone who something similar in the US, and it seems their tool is open source! kzbin.info/www/bejne/iYW1oYeeiNZ-es0

[@Blizter47]

@@DudeSkinnyTall I working in the same domain, I noticed there might an opportunity for a tool automating compliance related things!

[@gaborbaksa4690]

@@Blizter47 I, actually work for a central bank in the EU, so most of the problems in this excellent video applies here, plus several others, to make our life more miserable. Like language barriers, conflicting federal (EU) and local government interests, very limited (and ageing) workforce and so on. Working with agile-like deadlines and shiny new technologies, like blockchain in a team full of waterfall dinosaurs is a bit bumpy. So, I sent this video to my colleagues, to show them, there can be light at the end of the tunnel. :)

[@SV-tc8cu]

@@DudeSkinnyTall It is possible, you just need a lot of resources/money and smart people. The company I worked for had both and managed to have very high quality setup while enabling aiport level security. However, we never had to worry about 'money' aspect and company pays huge salaries to smart people to lure in the best talent

[@Mauglus]

Thank you, great video :)

[@robpountney601]

Hey Viktor, really great video! Very comprehensive. However, I am still a little unsure about a few things... 1) Allowing developers the ability to create their own cluster could potentially be very expensive, could you use a tool like Crossplane to automate the provisioning of a K8s namespace or even Virtual Cluster instead? 2) Where would developers store the infra & application definitions? Would this be in the same Git repository as the application source code or separate repo? I would think separate as the image version would need to be parameterised and updated whenever a new version is deployed.

[@DevOpsToolkit]

1) yes you can. You can use the Kubernetes provider with crossplane to create those. 2) I tend to keep everything related to an app in the repo of that app and everything specific to an environment (e.g. staging, production, etc.) in separate repos. That would mean that infra for an env is separate from an app just as the collection of Argo CD or Flux manifests that define the applications in that env are also separate and often in the same repo as infra. Think of an env as a single big application that contains many smaller apps stored elsewhere

[@tomasbaranauskas8142]

Thank you, Viktor, for this video. It is so easy to follow and extract useful information from it. Awesome! I've got a question (I am a developer): why running docker on production is a bad idea? I am not challenging this thesis; I genuinely don't know the answer.

[@DevOpsToolkit]

In the past, Docker was not a good idea as a container engine in Kubernetes because it packs much more than what's needed. Kubernetes only needs an engine that manages containers while Docker is also dealing with networking, storage, etc. Those are the things that Kubernetes itself manages so they are an unused overhead in Docker. Docker also packs Swarm which is an orchestrator, just as Kubernetes is an orchestrator. And so on and so forth. The point is that the vast majority of Docker is no needed in Kubernetes. What is needed is a container engine, and for that Docker uses Containerd (it's packed inside Docker). So, it makes much more sense to skip Docker altogether and go directly for Containerd (which is what most Kubernetes distributions are using). Another important point is that Docker is not supported in Kubernetes anymore, at least not directly. In the past, Kubernetes had Docker interactions hard-coded. But, as new container runtimes emerged, it decided to use OCI specification (the runtime part of it) as a way to interact with any engine one might use in Kubernetes servers. All container engines support it, except Docker. To mitigate that issue, Docker, Mirantis, and Rancher created DockerShim that translates requests to OCI into Docker commands. But that's only a workaround to postpone migrations away from Docker. Finally, almost all Kubernetes distributions are now without Docker. So, even if you do want to use Docker inside Kubernetes clusters, you might not be able to.

[@tomasbaranauskas8142]

Huge thanks!

[@SV-tc8cu]

@@DevOpsToolkit Awesome answer, thank you!

[@stanrock8015]

I just figured out this tune at the end. Calum Von Moger a bodybuilder uses same tune. lol

[@DevOpsToolkit]

I had no idea. Video editors picked it for me :)

[@kuzco7061]

I just watched this video and I really liked all the insights but, I have one question. It has been almost 3 years since that video, I can imagine that many many things happened. Does someone have an updated review of the situation? Have Victor's comments been implemented? Really interested in that exchange :).

[@DevOpsToolkit]

To be honest, I don't even remember what I said in that video. I'll need to watch it myself before answering.

[@scottamolinari]

I've gone through a number of your videos now (one seems to lead to another and thanks so much for them) and I'm getting a better picture of what we need in terms of that "very opinionated platform" I've been speaking about. Thanks to your suggestion in the other video comments, Rancher Desktop seems to be a perfect fit for the local dev environment (might have to sell it though to have devs dump Docker Desktop and I've also installed RD now, instead of using Docker Desktop. It's pretty cool.). So, assuming we are working with 3rd party ISVs who want to develop apps for this platform, we would push them even further "away" from their responsibilities in terms of spec'ing out infra for their app. We wouldn't want that. At least not directly. At any rate, back to the local dev environment. Would it be fathomable to also offer the same kind of infra-via-metadata scenario (I'm thinking like Flux) to the dev locally, where they simply point Flux to a special git repo and Flux can do its magic? Once Flux is done, the dev can start working with a working (yet majorly reduced) version of the platform locally? All the databases and other services and applications are running, which they'd need to do their app dev job with. I think I need to start properly working with Flux to find out. But, seeing some videos and reading their docs, it feels like I'm onto something. Or am I barking up the wrong tree?🤔

[@DevOpsToolkit]

That's a perfectly valid and good approach for all the dependent apps, not necessarily for the app one is working on since that one might need additional things like sync on changes, etc.

[@scottamolinari]

@@DevOpsToolkit Exactly. Only the dependencies for the app being developed would be driven by Flux. The dev's work is not inside the cluster, but rather running on the host machine and would be controlled via git. Though, I'm still not completely certain about the approach of having the dev developing outside of the cluster. 🤔

[@DevOpsToolkit]

If you're developing outside the cluster you'll need something like codezero or teleport to redirect communication towards deps inside the cluster.

[@scottamolinari]

@@DevOpsToolkit And, of course you have a video on the subject. Awesome. 🙂

[@matscloud]

What is your view on serverless? This all sounds great but you need a big engineering team to build and operate all these services, and if you use a managed api gateway with lambdas and an occasional fargate, ops costs go down significantly.

[@DevOpsToolkit]

I think that serverless were very limiting at the start and are often confused with functions as a service (FaaS). Lambda would be an example of FaaS which is a flavor of serverless. It can be (and is) useful but only is specific scenarios. I would place my best on KNative. It is Container as a Service (Casas) flavor of serverless that has less limitations than FaaS. You can run it yourself or, if you prefer a managed version you can go with Google Container Run (GCR). Many of the vendors are adopting it and we are likely going to see it explode in usage.

[@gvoden]

Our developers don't want self-service, they want the Ops team to "do it for them". Build me a cluster, give me a S3 bucket. And by the way I want full access to AWS. How do we change that culture?

[@DevOpsToolkit]

You need to make self-service easier and faster than requesting something from the ops team. Everyone wants things to be easier and faster and as long as requesting something is a better option, people will be requesting.

[@SV-tc8cu]

I think changing a company is way easier than changing a company culture. People are what makes the cultuer, and managers task is to create the healthy and productive culture.Unfortunately being a good manager is not something that you can learn like you can learn a skill. You may learn some techniques but not the traits like leadership and charisama. If managers dont' want to change the culture, it will not happen. Time to leave the company. Life is short.

[@robpountney601]

Thanks

[@DevOpsToolkit]

Thanks a ton, Rob.

[@kadapa-rl6jg]

Why do developers treat devops engineer as a Slave even the manager do the same .

[@DevOpsToolkit]

While that might be the case in some organizations, more often than not that's a sign of malfunctioning companies where each team thinks badly of the other, often as a result of having silos. One of the most important things that DevOps tries to solve is precisely that. The whole point is for devs and ops to work together, as a team.

[@kadapa-rl6jg]

@@DevOpsToolkit Agree but not sure why those Developer and Development experience manager is not understanding..

[@DevOpsToolkit]

I hear you. I had similarr thoughts myself quite a few times in the past. But, over time when I got greater visibility into different organizations and higher levels, I realized that, more often than not, that is the feeling shared across most of the teams. Devs have grievances, ops have grievances, testers have grievances, etc. It's just that it is normal to see issues affecting us and overlook those affecting others. Most of the time, it's a sign of malfunctioning organizations and not specific teams. Now comes the important part... The higher the position, the more responsibility one has and that means that it is a duty of management to notice those issues and realize that their job is not to protect their team but to look at the situation ad a whole and try to fix the whole organization.

[@SV-tc8cu]

Change the employer maybe?

[@DevOpsToolkit]

@@SV-tc8cu That is, without doubt, the best option, when you are in the position to do that. For a while now, the market in the west (US, EU) shows bigger demand than offer for experienced engineers, making it not only easy to switch companies, but also more profitable. However, that is not necessarily true for junior devs or in the eastern market. So, changing jobs is not always easy. It depends where you live and how experienced you are. The problem is that the longer you stay where you shouldn't be, the more complicated it becomes to switch. The excessive demand is mostly focused on emerging tech and if you're stuck with, let's say, DB2 experience, you might be in a very bad position, no matter the number of years you have under your belt.

[@jdubeau007]

That was a long introduction. I got a headache from watching this video.

[@DevOpsToolkit]

Thanks for the comment. That's really valuable. I'll do my best to shorten intros in the future.