Question for my fellow devs:

Do you feel like you are spending too much time on maintaining ur devops/infrastructure rather than focusing on the actual product?

Do you think your company would be willing to spend a bit of money to outsource scaling problems to someone else and just focus on the product?

Ik we got lots of fancy new CI platforms like Circle CI GH actions etc but like I personally feel like I’m doing certain infrastructure tasks twice when I look at the two different codebases I work on.

Yes, having a devops team is something that can benefit everyone really.

Yes, devops is a pain in the ass and requires a team to deal with it.

Except when the team quits over time, and the company decides that the dev teams can just absorb that role. Which brings us back to where we were before we had a devops team.

Gone full circle on this.

@C0D4 do you think if there was a self-serve framework where you could move your logic and db schema to and then it itself would take care of sharding and scaling maintaining api end points and whatnot would you consider switching to it or does it feel too opinionated already?

@darrenrahnemoon if it was a new project, sure setting up on a new service would probably work out just fine, drop and run and away you go.

The thing that doesn't work with ease is migrating an existing project. If I could just drop and run and make some minor changes with config in the codebase to point to new services then all would be good. But that's never going to happen especially once you start diving into a particular cloud and utilise non cloud centric tooling.

This is why devops is a bitch, each cloud has its own way of doing things and offer there own version of said features (for better or worse)

If we all lived in a K8s world and just dropped containers everywhere then maybe your IaaS could work out.

My experience is actually that having devops in the teams results in faster deploy times.

When separated, problem facing the dev ops will most likely always get lower priority.

We also have maintenance in the teams for the same reason, tasks tend to be fixed or automated faster that way :)

Of cause, this might not work with large projects and many teams, but for 2-4 teams it seems to work very well.

Sometimes it's hard to separate scaling from functionality, eg switching to aws lambda from a monolith requires extensive code changes. But I also wouldn't want devops out of house, coz if you can't go talk to the person you need to change something that's a problem. Unless you fully bundle product, and external party handles integration (a situation I've been in)

These days with devops solutions like Azure/Github it almost feels like the lines are getting blurred.

Thankfully I dropped almost all actual system administrator tasks when I left my old job, only time I need to log into a real server is if a deployment failed or to diagnose performance issues.

If it's a "true"dev-ops team, yes....

By true I mean that you cannot just move developer A from column "developer" to "DevOps" and be done with it.

(Sadly, seen this many times with epic shitry results)

Hire people who specialized in the field.