DevOPS is the MOST IMPORTANT THING IN THE WHOLE UNIVERSE, followed closely by IoT.
Or so I have read.
Listen to some DevOps evangelists talk, and you would get the impression that IT operations teams exist only to serve the needs of developers. Don't get me wrong, software development is a good competence to have in-house if your organisation depends on custom applications and services to differentiate its business. As an ex- …
Is it a "F-R-A-M-E-W-O-R-K" that ought to be "A-D-O-P-T-E-D" ?
Or is it a "C-H-A-N-G-E-O-F-C-U-L-T-U-R-E" ?
Either way - it doesn't sound "I-N-T-U-I-T-I-V-E" and it'll be hard to convince a generation of programmers that grew up with the 2-click-rule to utilise DevOps as solution to - exactly which problem ?
I think this is one fad that has run its course. If nothing else, the one thing that cloud has brought to the software world is the separation of software from the environment it runs in, and since the the Ops side of DevOps is all about the integration of the platform and software, what you end up with in a cloudy world is a lot of people looking for a new job.
How did this sneak past QC?! This is undermining a solid year of indoctrination, quick pull it before anyone else sees.
Next you're going to be posting that HPE haven't done anything interesting in the past two hours or something actually readable about storage - enough of this craziness!
A House of Cards, just waiting to collapse..
I work for a company who develops its own platforms, the demand level we operate at is small, yet the development team are trying to utilise every buzz-tool you've heard of such as Docker, ElasticSearch,Kubernetes etc so they can scale..
Ironically this take longer to develop, costs significantly more to operate and is more prone to breaking, additionally since the implementations are completely bespoke, its a much higher risk to the company!
" the development team are trying to utilise every buzz-tool you've heard of such as Docker, ElasticSearch,Kubernetes etc so they can scale.."
I fear you are about to discover that they are doing this for reasons other than scale". Unless you mean scale the career ladder at another company where some manager or other has also "heard of" these things and convinced themselves that they absolutely MUST hire someone with experience of them whatever they have to pay.It's a win-win for the developers as they get paid for learning the skills that make them even more money (and why not, that's always good) and they get to screw up or not do things efficiently with their first attempt at using immature tech that probaqbly has substandard documentation, a relatively small online community so you can't get help easily for problems, no real established patterns for optimal efficiency, etc, etc.
So your company gets left with their poor first attempt at a system using all this stuff, which may become an expensive headache if any one of the buzz tools making up the foundations of your systems proves itself to be rubbish, unreliable, or falls out of fashion as quickly as it got hyped up.
Then you have to replace the ones that left with very expensive staff, cos there's so few people around with these skills.Eventually someone says "enough", the whole lot is chucked in the bin and the cycle begins again.
For Decades Developpers have neen ignored by infrastructure vendors because the decision makers buying infrastructure sit in the infrastructure teams. Now with the cloud etc vendors realize they will lose supporters within these teams.
So instead - infrastructure vendors target developpers to become their next fanboys.
E.g. Dear developper, you won't need to speak to your infrastructure admins anymore to setup a development environment. Now you can automate, orchestrate the provisioning of your containerized development environment at the push of a button. Blah blah blah, but you have to buy our storage.
I remember the days when every DBA wanted RAID10 just because thats what the whitepaper recommended. By that time storage technology had long moved on, but the DBA still talked about Full Stripe Writes.
Now with DevOps you'll have Developpers influencing infrastructure decisions, because they just learned about snapshots. And yes - it has to be all flash - and designed from the ground up by millenials that eat avocado.
DevOps is the next 'Agile'. Hacked off with trying to get infrastructure to marry with a 'let's just do it' methodology, devs are now running off with the argument and constructing their own infrastructure in clouds.
Great if you're Metail or all new Jira-sic park, but sucks in your enterprise boundary. Putting children in charge of a traffic system would (and in the case of DevOps, does) create havoc for architecture and stability.
They should all be...etc.
Nice of you to point out what us in Ops have known all along. I'm afraid it will fall on deaf ears, though. Until the executives who constantly fall for the new shiny are made to actually examine business needs and processes and make business decisions based on said.
Our laughable move to cloud here involved migrating off of on prem Exchange to O365. The idea was to free up our operations team to allow us to do more in house projects. Funny thing is, it takes more management of the service than we ever did on premises. True, we aren't maintaining the Exchange infra, but now we have SQL servers, DCs, ADFS, etc, to maintain in the MS cloud to allow authentication just to use the product. And because mail and messaging is business critical, we have to have geographically disparate instances of both. And the cost isn't pretty. Yay cloud.
This article addresses a classic simplistic mischaracterization of DevOps. What is DevOps about? Think about what was needed to set up an apache server circa 2000. Now think about "apt install apache". Or "yum install apache". THAT is what DevOps is supposed to be about -- taking processes and knowledge out of wetware & sticking it into applications (and libraries). It's not that dependency management is not important, it is that it is so important that we don't trust humans to manage it. Same thing with Chef, Puppet, Jenkins... None of these tools are about eliminating OPs. We are a long way from having software decide when to change an OS distribution in prod, or make deep changes in security policies.
What is important to understand, however, is that this is SOFTWARE. Just as noted above, it is not possible to be the very best in operations & the very best in software development. We programmers are going to have to learn a lot about ops in order to provide useful tools, and the operations folks are going to have to admit that they are not programmers in order for DevOps to provide usable tools.
But there are lots of managers that are like the proverbial farmer who when told that if he bought a horse, it would save him half of his work, so he bought two...
Yes, DevOps isn't about replacing Ops. But try telling that to the powers that be. It is sold and seen as a cost cutting measure.
As for devs learning Ops and vice versa, there are very few on both sides who really understand what it takes to do the others job. I have a very high regard for Devs, but when it comes to infra, they are, as a whole, very incompetent. Just like I'm incompetent in Dev. can't have one without the other. I feel that in time, the pendulum will swing away from cloud as execs and accountants realize how it isn't really saving any money.
The real question is: Will there be any qualified operations engineers available or will they all have retired out or have found work elsewhere. It isn't easy to be an ops engineer, takes a lot of experience to get there, and qualified candidates are hard to come by. Let's face it, in today's world, its a dying breed.
It will be interesting to see what management chooses with regards to where tasks are allocated, where and how. On the one hand bigger SMEs have recently invested in more professional environments, sometimes hosted, sometimes on site. But the tech and philosophy are clearly old-style (basically on-premises tech moved to hosted tech as an option).. These will occasionally require ops, devops etc.. to find their way around the spaghetti. And they may have some agile projects.
On the other hand are the companies who have gone (partly) web and cloud. Salesforce, Google-apps, box net etc. With more and more encrypted data-storage they can separate tech (hardware, repair-engineers etc. ) more from software and user-data.
Gut-feeling of many managers will still be to want to have systems (hardware) with some own staff occasionally intervening/operatting and most maintenance outsourced. But I eel that more and more systems will be moving cloudward (Amazon and Azure mainly with some to others like google).
I think thaat although mmany have invested recently in expensive systems and push the market, the main trend will be cloudward with less and less staff touching hardware parts other than their consoles.
Here's an idea. Why not put a skilled developer with a skilled operations engineer and see how you get on? That way, if they work closely together then you get the best of both worlds, and they will learn some of each other's jobs too.
You could even have - say - a team of Developers and another team of Operations people who work together doing the stuff that they're best at? Exchanging ideas and learning from each other. You could then bundle these people into a department that does IT properly, splitting their time between business-led and innovation-driven projects using on-premises and cloud deployments depending on which is most appropriate for the requirement.
Who am I kidding, that'll never take off...
Biting the hand that feeds IT © 1998–2019