Re: Having read the article
You dont need to read much of the article to find out what DevOps is all about. The third sentence contains a concise description ...... "magic enterprise fairy dust".
To everyone with DevOps in their job title (and a quick LinkedIn search turned up 45,597 of you just in my network): folks, you're doing it wrong. To every employer looking to fill positions like "DevOps engineer" (and there are plenty): you, too, are miserably misguided. As it turns out, DevOps isn't "a job title, a software …
Good article, seriously. However, half of this is mildly amusing -- you decide which half
That mindset involves a collaborative approach whereby operations folks trust product developers to deploy code, and product developers neither understand nor trust the way operations needs code deployed.
To remove System Administrators and have Developers take over and be responsible for the security and integrity of the System that they use for development.
Since DevOps became a "Thing" System Security has increased, data theft has been reduced to almost zero and no one has accidentally left anything open and available to the public on the "Cloud".
No, I am not being sarcastic. If I have negative thoughts about popular trends and catch phrases in IT then I will be deemed negative and bring "negativity" down on the whole workplace, and that is worse than setting my desk on fire. So I am very optimistic about DevOps.
You can't buy or hire a mindset
Oh, that is good, for surely such would be a fraudulent sale.
Do any who would not be bothered to comment here, doubt all prime and any sub-prime mindsets are malleable, and can be easily manipulated and better beta micro/macro managed to server a cause with altogether quite different charted directions and which would be fully in the wish and command and control of A.N.Others?
When I hear DevOps, Agile, etc. I wonder if the shills have ever worked on a real system. To be a good developer, tester, system admin, etc. takes a specific set of skills that do not overlap that much with the others. Expecting someone to good at all is a fool's errand.
My teams role involves design, estimation, testing & development environment config and running support, recoveries, production config and implementation support, and system configuration. We have continued to develop a lot of semi or fully automated process to make it easier, quicker and better quality. We understand support each other out of necessity to reduce the stress, 'try' to keep people off our backs, with bureaucracy doing it's best to hinder at every stage. We have to evolve, you can't keep still because nothing and nobody else does.
Now with all this back-ground you might think it would qualify us somewhat to contribute to ideas and discussions (even peripherally) around 'DevOps' given that it seems to roughly fit how it is described? Well you'd be wrong it seems. Since the Agileisters and DevOps mania has invaded we've been sharp elbowed and talked over or totally dismissed. Not because we did anything wrong or failed to deliver within the tight parameters we work within. It seems more that it's because we don't speak their smug condescending 'inclusive' (except us) language which they endlessly foist upon us. We don't tremble like breathlessly excited children and wet ourselves every time a new Agile or DevOps 'bible' book hits the shelf, or some LeanAgileScrumDevOps 'guru' gives yet another presentation.
Now, all the chancers are jumping in, being given massive budgets to buy off the shelf solutions for processes we had to painfully develop ourselves because there was 'no budget, we're cost cutting'' whenever we asked. You realise there is an entirely parallel operation evolving that is the favoured one, while the yours is left to whither. You see endless rounds of conferences you're not invited too, and nauseating self promotion from the talking heads and their sycophantic side-kicks. You see wild often unfounded optimism all around, like protesters in front of the tanks in Tianamen Square.
The chancers, despite these canned solutions manage to often make a mess of it because of lack of experience, and the fact they never ask for advice at the early stages where deep knowledge helps embedding of standards that will set you up right for all that follows. Oh no, they want all the glory for themselves. 'I have my new 4x4 and I know how to mount a kerb thank you very much, I'm the expert here'. 'Mind the people and bollards though' you say as they accelerate on. Regularly you find they're on your shoulder all friendly for a 'minute' (which often becomes a considerable amount of effort), wanting you to help when they're floundering, even if you're working your bollocks off to support stuff that is actually working. ('Yes you're busy with that old stuff, but MY stuff is so much more important'). There will be no mention of your contribution to fixing it. Ever. But if you don't help, you'll marked down as 'negative', 'not supportive' and even further side-lined, if that is possible.
Eventually the parasite will consume the host, and find they have rely upon themselves, suffering the consequences of whatever they created, good or bad. In later years the ones that actually stay will become disillusioned as they're no longer the bright young things getting all the attention because the 'next best thing' will appear. They will then be at my paragraph two above. .
Of course the more 'Agile' parasites will have fled the ailing host well before this. They always do.They leave well sated, looking up at the maggots scrotum as they pass to a new host and start again.
My experiences echoes yours. I asked in an earlier comment what DevOps means, and I mean it as a serious question, not snark. Every answer I've gotten confuses me, because they are either descriptions of the same end goals as good engineering shops have always had, or are descriptions of general workflows that are the same as good engineering shops have always had, or are descriptions of specific tools and specific methodologies.
So, naturally, I think "DevOps" must mean specific tools and methodologies as those are the only things that are different from traditional practice. But this article is saying no, that's not right, it's a mindset (which is no different than the mindset good engineering shops have always had).
So I don't know what DevOps means, unless it means nothing more than "good engineering practices", in which case it's a meaningless marketing phrase.
as predicted, our king parasite has recently exited its host, squeezing out below the maggots scrotum, dribbling the same narcotic trail to it's new host.
What a fucking surprise. Much easier to suck on a new, full blooded living specimen than a half coagulated rotten carcass. I'd say good luck, to the new host. Keep a few bags of blood in the freezer.
You might sense a tinge of negativity here. Well WTF. Still endeavoring to deliver, and evolve, but the zombies are at the door.
Now THAT made me laugh. Because SCRUM or Kanban weren't good enough. We must combine them! Please tell me it was a joke?
What really gets my goat here in the comments are the developers looking down their noses at ops guys (like myself) as if what we do isn't just as important or necessary as the code that gets written. If I had a dollar for every developer who was as clueless about systems integration as I am about programming in C++, I'd be retired. You can't have one without the other no matter how you slice it. Put it in AWS or Azure, sure. but there are still highly skilled technicians keeping things going on the back end so that your code has a place to live.
As to the fellow who mentioned VMs towards the top. The reason VMs are around is because the hardware that we use today is so undersubscribed that it made sense to abstract it out. It isn't because of the laundry list of ignorance you mentioned.
A DevOps team fills the unquantified void between normal Software Engineers and remotely managed cloud services. It's process management with some pseudo-technical work. It means that a DevOps team can claim they need a "Cloud DBA" then hire somebody who can read SQL, write up some policies, and mis-quote Stack Overflow. They can command junior Engineers to define new API wrappers for public standardized tools and then say they're API architects protecting internal standards. They can re-configure cloud SCM tools then claim they're in charge of the code quality process. There's no limit to how big a DevOps team can grow if there's no definition of what it should do.
Back in the 80s a small group of us handled development and system management. We had to do it all because at that time we were the only people in the business who knew this strange Unix and RDBMS stuff. The tools needed were part of the OS and RDBMS packages. Because we handled it as a whole we knew not to write something we couldn't support and providing support kept us in touch with what the business needed written.
We didn't have a special name for it. It was just what we did.
Now, not only is everything old new again, it also has to have a special name, lots of tools and courses and all the rest of it.
Not to slight "DevOps" but it's another method, style or approach (possibly perfectly valid) that comes under the general heading "once and future doing it wrong." DO possibly especially stands out as something that would have been considered extra screamingly incorrect not so long ago. Will its stock sink so low as to regain the name "chaos?"
Most of this churning and reflux is really about perfecting human nature. Good luck!
I'm the problem? Sure. I'm the guy that gets glared at for suggesting that there is a better way to work than manually provisioning Linux boxes, saying that it will take effort, new procedures, education, and may incur some cost in the short term.
Mentions of snake oil, and a some of it is; It takes a shift in the way more than just the technology part of a company is prepared to work, and selling that upstairs is hard.
It's definitely about relationships, no doubt. For the last couple of decades there has been a relentless push to create 'silos' which has destroyed many generalists that could understand the bigger picture and would have good networks in business and technology to understand and support the aspirations of both. I was quite heavily involved in Storage, System programming, CICS, DB2, Security, Disaster Recovery, scheduling, Operations and working with Developers in design and testing who were happy to share the business requirements to understand what technology could offer. Most of those applications are still key to the business and are very functional and solid platforms. As each area became more silo'd this sort of relationship gradually broke down because each became some ladder climbers little fiefdom. It's really dysfunctional, and kills any dynamism around making changes or innovating because the isolation means not understanding each other or even worse being pitted against each in a blame culture. This has put the whole industry into a kind of hiatus in a lot of ways, and these 'new' developments seem to be just a way to build connected teams again. That is a good thing, I'm fully for that and it holds a lot of promise. But when the 'team' is split over large geographical areas of different cultures it really is pushing shit uphill with a toothpick. Then throw in all the Outsourcing companies with their own agenda's, the Cloud providers, the internal politics. It's a pretty toxic mix really and needs some very clever and charismatic leaders to make it work, even partially. A good place to start is trust, and that is a very rare commodity, especially when people are not being given a straight story and living with precarious job security. It's a real 'long run' proposition, 5 to 10 years depending on the organisation, and there'll be a shit load of carnage on the way. Whether a Phoenix arises out of this or some overweight chicken with three feet, no beak and carrying a shed load of anti-biotic resistant bacteria emerges I don't know.
If you look at the DevOps jobs on the various recruitment sites, they do seem to be operations plus git. So we have infrastructure as code which can be versioned. And maybe DevOps is development techniques applied to operations.
But, like the author, I thought DevOps was supposed to remove silos and encourage development and operations to work together. And no one seems to look after development tools now and work with developers; that has been taken on by operations and sysadmins. Which is a mistake because the culture is different. Operations is more cautious, quite rightly - this is production with the possibility of reputational loss. Development can be more experimental in things.
So, I do wonder if DevOps is actually DevOps in 90% of the roles advertised.
Biting the hand that feeds IT © 1998–2019