> You’ve got a DevOps team.
Yeap. Largest red flag there is.
DevOps is broken
271–280 of 363 posts
Re: DevOps is broken
#272This is one of those things that just drives people out of tech and leaves the ones still in it super frustrated. So many buzzwords and PR non-sense from non-tech mgmt.
Re: DevOps is broken
#273Hard disagree but Mandy Rice-Davies applies. Some interpretation of DevOps may be BS, e.g. >> Need a database? File a ticket with DevOps. That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022. Counter points as to why DevOps is not BS: Today there's just an acceptance that you version your code in VCS, it wasn't always that way. "Hey, this doesn't look rig…
>> Need a database? File a ticket with DevOps. > That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022. Serious question, as I think this has been part of my thought process in the challenges of platform engineering: what does it mean to automatically provision a database? I can think of lots of different examples that are insufficient in one way or anothe…
If we’re talking in the context of an organisation which has or is considering having a devops team and / or a platform team, like in the article then yeah i agree you’re not going to be apt installing a db.
There will be some mandated platform choices so that the org has a fighting chance of managing complexity and knowledge/skills within the db platform team.
I’d expect you’ll have to specify in a web form or maybe an api call that you need a document db / oltp / olap and you want it in region A and of size medium and you want an indefinite expiry date on this lease. I wouldn’t expect to have much more freedom than that, e.g. backups, point in time restore options etc will all be standardised. I’d expect to be immediately given an appropriate pre-built instance that had been provisioned and kept warm waiting for the next request of a db of these specs.
That allows the developer minimal friction but also allows the db platform team to say we provision a postgres for document db use cases not a mongodb because it simplifies platform ownership (and we just mail a link to some docs explaining how to use a postgres as a document db to the user account that requested the instance).
Re: DevOps is broken
#274I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
Are you hiring? I was hired as an infrastructure engineer and I'm currently writing typescript for the frontend of an internal product.
Re: DevOps is broken
#275Earlier quoted context omitted.
this devops is also a dumping ground for anything else not happening on a developers computer which they should control but wont because "That is devops job" mostly this happens alot with node projects for some reason..
"anything else not happening on a developers computer which they should control but wont" Ok, I've seen this, but IME (24y in industry, the last 6 as a consultant) in the vast majority of cases, it's more like "things devs should control but CAN'T [bc CICD etc are silo'd and owned jealously by an overburdened ops team unable or unwilling to facilitate self-service]".
Some of the 'jealousy' may also come from bad experiences.
It only takes a few instances of people royally messing stuff up in production for their deployment rights to be stripped away – and other groups catch the fallout too, as new "procedures" get implemented.
Re: DevOps is broken
#276I don't understand why we can't take more ownership of our work. Even if you are not immediately and directly compensated for every inch that you go above and beyond, you are still in a position to make yourself irreplaceable in terms the business cannot ignore. Think about the long play. You join a startup with a broken, hot-potato-style "devops" process. Instead of saying "not my problem" all day, you can take some…
We can't take more ownership of our work because we do not in fact own it, and the business will never let you actually own it. All I've gotten from trying hard is burnout and sickness. At this point I can say the only reason I work for others is because I need money to live.
> and the business will never let you actually own it.
This is not true in many startup environments. You'd have a hell of a time getting me to work on a new project without some sort of equity arrangement.
Re: DevOps is broken
#277I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
This is the answer.
I am interviewing right now and my previous experience includes devops roles and SRE roles, so I get contacted for both by recruiters. After hearing about the responsibilities and examples for these roles I can only come to the conclusion that titles are a waste of time. Even the "level" of a title of Staff, Principal, Lead, etc are a waste of time. Just call the job what it is and if you can't decide on what it is at least to an 80% level, maybe you're asking too much for that job?
Re: DevOps is broken
#278Earlier quoted context omitted.
I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and…
Alan Kay said that “Everyone who is serious about software should make their own hardware.” How can you be a good developer if you don’t understand the architectural limitations and choices? When I design a backend system, I need to think about how the front end developers are going to interact with it. My data storage characteristics and scaling. I need to know am I designing anything that’s hard to deploy. How will…
I don’t think you’re disagreeing with me. Developers should know what their code runs on. They shouldn’t have to add managing that to an already full schedule of work. That’s the difference.
Re: DevOps is broken
#279Earlier quoted context omitted.
> Data sovereignty per microservice > An important rule for microservices architecture is that each microservice must own its domain data and logic . Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. https://learn.microsoft.com/en-us/dotnet/architecture/micros...
The big issue I've seen is that takes a lot of work, so people cut corners. The problem is of course when you cut corners with microservices and rely on a shared database for instance, suddenly you're dealing with 40% of the costs of a microservices and 0% of the benefits.
Shared database can be a reasonable microservice boundary, especially when using database-as-queue or database-as-mucroservice. In the former, services a, b and c can insert and query but only D can update, i.e. any service can creat a work-order but only D can mark it completed. I. The latter, nobody can read or write and all access to tables is done through stored procedures.
I don't recommend either, and it's still a code smell, but with clear definitions they can work.
Re: DevOps is broken
#280> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.
I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and…
[deleted]