Most Organizations Are Not Fully Embracing DevOps (betanews.com) 301
An anonymous reader shares a report: Although many businesses have begun moving to DevOps-style processes, eight out of 10 respondents to a new survey say they still have separate teams for managing infrastructure/operations and development. The study by managed cloud specialist 2nd Watch of more than 1,000 IT professionals indicates that a majority of companies have yet to fully commit to the DevOps process. 78 percent of respondents say that separate teams are still managing infrastructure/operations and application development. Some organizations surveyed are using infrastructure-as-code tools, automation or even CI/CD pipelines, but those techniques alone do not define DevOps.
Marketing and operations not embracing MarkOps (Score:5, Insightful)
Equivalent of saying marketing and business operations need to embrace each other as one. Yes there should be synergy and commonality, however they are different fundamental areas of expertise. Dev Ops should favor cooperation and collaboration not one person to do it all.
Re: (Score:3)
In the old days devops was one person because they were simply a sort of translator between the development team and the BOFH, an almost-developer who understands system administration well enough to figure out what technologies are allowed that will meet the needs of the team, and what configuration changes can<->should be made.
Re:Marketing and operations not embracing MarkOps (Score:4, Insightful)
im gonna throw it out there and say devops was just a philosophy of applying development paradigms, e.g. source control to infrastructure, producing the code as infrastructure movement and paving the way for easier continuous integration with the ability to auto-build complete systems from scratch on demand
devops was never about merging the systems and development teams, ever
And this is a "problem" because ... (Score:5, Insightful)
Re:And this is a "problem" because ... (Score:5, Insightful)
Well, not the developer per se, but the DevOps guy should have a process to promote it automagically from development to qa to production.
If they do their job right, it shouldn't take more effort than pressing the "promote" button in their build and deploy tool of choice. For course, it never actually WORKS that way, but that's how the vendors tell me it should work.
Re: (Score:2)
Re:And this is a "problem" because ... (Score:5, Insightful)
Re: (Score:2)
The process and having multiple environments is much more important than everything else. Making it easier to do so should just be a time saver after that.
Re: (Score:3)
If you don't have a one-button promote, then you probably don't have a one-button rollback either.
The one-button promote isn't the goal in itself, it's a side-effect of having a tightly managed configuration. You want a well defined process? When you find yourself capable of automating it, then you have it.
Re: (Score:2)
Re: (Score:2)
For course, it never actually WORKS that way
Of course it works that way.
but that's how the vendors tell me it should work
Which vendor? Since when do you need a vendor? Typical deploy chains are all open source.
Re:And this is a "problem" because ... (Score:5, Funny)
I guess that you don't have "That guy" working in your organization ,who makes a poorly documented code or script change that breaks the build or deploy process the day before he goes on vacation.
I thought that every organization had one of those people working for them. I think that our "guy" is named Bill. Fuck you, Bill!
Re: (Score:2)
You can not make undocumented code changes.
First of all: to put a code change "life" (regardless if for developers only, or for 'prelife' machines or 'test' machines or the 'production' machines) you have to commit it to a source code control system. And that is only possible if you give the ticket number from the issue tracker in the commit comment (of course you usually could give a fake one in so far that it only needs to refer to an existing ticket, or open ticket or ticket in state 'progress').
Then dep
Re: (Score:2)
"When a vendor tucks up. The company ends up getting discounts."
Not always. I've seen more than a few cases where the vendors have talked senior mgmt into an even more expensive solution and longer term contract.
Re: (Score:2)
When you fuck up. They just fire you.
The funny thing is that is typically both the cheaper and in the long term, better option for the company
We automate the requirement for peer review (Score:5, Interesting)
> Automagically usually means no peer review
We used the setting in GitHub to automatically require peer review before a change can be merged. That's the only reason we now have peer review consistently. It was spotty until we made it an automatic requirement.
Actually reduce people. That's why it's needed (Score:3)
Handling outage on production caused by code defect:
2 support people @ 0.5 hour
2 ops people @ 1 hour
1 developer @ 1 hour
1 mid-manager @ 0.5 hour
1 exec @ 0.5 hour (to keep asking what's going on)
Total: 5 man hours during the incident.
The after incident review is roughly the same, including preparation time.
Grand total: 10 man hours
Peer review: 1 developer @ 0.25 hours
Where I'm from, 0.25 is less than 10.
Peer review is one of the best ways of "gaining speed and reduce people needed".
Re: (Score:2)
No, in DevOps there is no distinction between developers and QA. It's as insane as it sounds.
Er No, Normally the developer will write unit tests, integration tests etc, A QA might write a bunch of other tests and get them automated into the pipeline and then the QA's will be able to focus on the really weird stuff (from a dev's point of view) that a regular user would have normally discovered at some point.
The Idea is to get the testing done as early in the process as possible true, but there is still a good difference between dev & QA
Re: (Score:2)
Or your QA end up spending all their time tinkering with the existing corpus of regression tests to keep them passing as new features or other changes that break tests are added to the product, or even just investigating whether the failures are regressions or a valid change.
Re:And this is a "problem" because ... (Score:4, Interesting)
> No, in DevOps there is no distinction between developers and QA. It's as insane as it sounds.
devops is just the systems team applying development paradigms to their jobs, moving from platforms like PXE/FAI etc to cfengine/puppet/chef with source control then all the tools that paradigm enables
recruiters might have turned it in to a single role for understaffed, underbudgeted companies to underhire with but just because they call an apple a tomato doesnt mean it is one
Re:And this is a "problem" because ... (Score:5, Insightful)
I'm not really sure what the summary/article is on about. It says:
"Although many businesses have begun moving to DevOps-style processes, eight out of 10 respondents to a new survey say they still have separate teams for managing infrastructure/operations and development."
But DevOps processes doesn't preclude dev and ops being separate teams, it just means that they should work together and use the countless bits of DevOps tooling out there to help support things like CI. It just about smoothing the path from dev to ops and automating it as much as possible.
If the suggestion is that to to DevOps "properly" which seems to be the implication of the summary then it does indeed suggest that what they're saying is that there should be crossover between developers and ops.
I work for a well regulated financial services organisation and that frankly just wouldn't fly. It's all fun and games if you're running shit that doesn't matter but for us, good luck explaining to the FCA that the reason you leaked a whole bunch of sensitive personal financial data was because Bob the dev configured the hardware firewall himself via Octopus incorrectly, or Jim the ops guy just did a small update that involved temporarily storing an admin password in a plaintext string internally in some application which got subsequently output in a memory dump on error on the public internet.
There are ample good reasons why DevOps does not and should not inherently mean merging the two departments, and frankly those suggesting otherwise should get the fuck out the industry in case someone accidentally employs them to work on something that matter and we end up with yet another complete fuckup of a software project.
It's sufficient to simply build bridges between and increase efficiency of the work dev and ops do together. Anything more than that is frankly nothing more than utter retardation. Let professionals do what they're professionals at - you wouldn't get the fucking cleaner to do their own payroll, so why the fuck would you get ops to do their own dev or vice versa?
Re: (Score:2)
Would you agree that the Ops guys will do a better job if they better understood what Developers were delivering? Would you agree that the Developers would write better code if they had the input and advice from experienced Ops engineers?
Re: (Score:3)
Even if both the answers are yes, it still does not mean individuals should be both developing applications and managing the infrastructure. Even in separate teams Ops and Dev can (and do in many organisations) communicate very well.
Re: (Score:3)
Yes I would.
But I'd also agree that dev and ops guys will do a better job if they understand any budget restrictions finance are under, if they understand any efforts HR are making to improve self development and staff happiness, the strategic direction the CEO wants to take the company in, the legal requirements enforced upon the company that legal regulate, and issues sales people are facing in the field, and the challenges the corporate security team face with people doing things that unwittingly cause a
Re: And this is a "problem" because ... (Score:3)
Re: (Score:2)
And like a butterfly, it should be trapped in a net and pinned to a board.
Re:And this is a "problem" because ... (Score:4, Informative)
... a developer should be modifying production code?
Sarbanes-Oxley says you need two people to do a production push. One is dev, one is ops. The cooperation is called dev/ops. Whooda thunkit?
Re: (Score:3)
God SOX is PITA, understandably so, but still a PITA.
My old job conformed to SOX, because they had to. publicly traded yada yada.
everything was about controllership. to promote something to Prod it took a weekly group meeting, and when I left they did monthly moves, weekly and emergencies. It was becoming bogged down by meetings and schedules. Still didn't stop them from having critical systems issues, or stop me from getting daily calls at 4am.. It really affects productivity. Users ask for prod ch
Re: (Score:2)
Re: (Score:3)
That's some accounting/board/financials regulation. Where did you find the text related to operational roles outside of financials?
I don't: my company deals directly in money, so financials are inseparable from what gets pushed. If you're doing software that doesn't involve money, you aren't required to use the two-person rule. You may wish to in any case, just as good practice, the same as doing PRs with reviewers is good practice.
So... (Score:3)
Why do they HAVE to commit to DevOps methodology?
Re: (Score:2)
Agreed. Some parts of DevOps work well for many companies, not every line-item is a sure-fit everywhere.
Re: (Score:2)
DevOps - essentially the practice of forcing your coders to also be sysadmins - works well for a situation where you have a staff of people where everyone can do a little of both but nobody can do either job completely competently.
Re: (Score:2)
In the company I work for, we devs are very capable, but ops are extremely CYA (Cover Your Ass). They don't want to touch ANYTHING. And that means running servers from 2009 in production.
Oh and they lost the complete SVN server one day. No RAID, and no backups.
But somehow, if prod breaks, it's the dev's fault for "not writing good code".
Re: (Score:2)
Because it is the stupid "hype de jour". DevOps does not work and cannot work, except when you have the rare situation where you actually have people that are good at both aspects and you manage to prevent them from being terminally boring by it, i.e. basically never.
Re: (Score:2)
I worked often together with DevOps and also worked as DevOp myself.
If competent people work, it works.
Incompetent people can cause havoc in any situation.
(And yes, it is superbly boring if you need another CI server and the "server guys" can not provide one ... hence, you set up your won, and suddenly you are a DevOp, oops. It is so easy. Where the hate for new adequate approaches come from is beyond me. Perhaps you don't like the term ... then coin your own one)
Re: (Score:2)
This is what usually happens at our site. Ops doesn't provide us with test VMs as required ("just use the dev VM", which is already down to its knees), but they want full docs on how software should be installed.
Gee. I have no idea what you're using to spawn services, dear ops. You haven't event told me what Windows version you're going to use. Because yeah, ops. You pull out a dirty old Win2008 VM because "licenses take time to get".
Re: (Score:2)
I don't usually respond to AC, but you seem like a decent AC.
I document everything. I even leave READMEs in projects for newbie devs on how to run a node.js with environment variables, and set SVN filters to keep them from commiting their credentials into the repo. Well, now that I am in charge of the new Node.js project and no longer in .NET.
But, you see. Company policy forbids devs from installing software. Company policy also doesn't allow us to use virtualization (because we are a windows shop and manag
Re: (Score:2)
Good DevOps requires people to be good at Dev and Ops. That's still exceedingly rare. Ops is the easier of the two, but not THAT much easier.
Re: (Score:2)
Of course. This is not a competition. Just pointing out that no team is perfect. We have incompetent people in my team as well. But there is a lot of elitism from ops people in this post. And between devs and ops, it's always ops that has the "if it works don't break it".
Re: (Score:2)
Find a better place to work, man!
Re: (Score:2)
No MSDN subscription. Management says we're a company with a software development area, we're not a software development company. So change is rather hard to implement.
As for docker, it's not really an option for now. I've pushed for it though (we actually have a nasty in-house service orchestrator that could be easily replaced with docker). Ops prefers monolithic native windows services. Easier for them to monitor.
Re: (Score:2)
Or you write an Ansible play book ...
Re: (Score:3)
I am a developer. I have no business talking to a superior of another area.
I can only talk to my superior. He can then talk to that person. I may or may not be allowed in the meeting.
This is how stupid my company is.
Re: (Score:2)
You're getting it the wrong way. We devs have to work with whatever ops has for us. We don't get to decide.
Re: (Score:2)
It seems painfully obvious to me; if you're suffering under a BOFH already, asking them to increase cooperation is not going to be productive from the development perspective, because the developers see themselves as the purpose of the whole shebang. Of course they're not going to adopt methodologies that require specific software support, that software will never make the list.
That's what real devops is all about though; translating that divide to language acceptable on both sides, and maybe telling the de
Re: (Score:3)
Re: (Score:2)
So how's your Blockchain coming along?
Good. (Score:5, Informative)
I've literally never seen DevOps implemented in a way that's actually beneficial.
It's consistently just a way for bad management to cut budgets by getting devs to do ops work badly, or ops to do dev work badly.
Even where that's not the case, it usually just ends up being a way for ops to fob their work off onto dev whilst not giving them the tools to actually do it like giving them the admin access they need to install/configure something wasting everyone's time.
I've even seen agile work and be beneficial more times than I've ever seen devops to be a beneficial thing. Like agile, it's just another fucking cult of nonsense most of the time.
Devs and Ops already have way too much to learn, that's why they're specialists in their fields. If you get devs having to learn how to manage networks and servers it just means that's a whole bunch less framework they're able to learn away from being able to do full stack. Similarly ops have way too much to learn in terms of software and hardware configuration to be able to learn to program properly. If both fields were simple jobs with fuck all to learn then maybe there'd be benefit to it, but forcing each other to learn more than they already have to in their respective fields is a guaranteed path to failure.
Re: (Score:2)
Re: (Score:2)
I've seen it work at large scale in exactly one place.
In order for dev/ops to work well, a lot of things have to be done correctly. Most of it is culture and design of the organizations and communications channels; social engineering in terms of how the groups are set up and their incentives. Failure to do this is generally why dev/ops fails or doesn't perform.
Re: (Score:2)
It's consistently just a way for bad management to cut budgets by getting devs to do ops work badly, or ops to do dev work badly.
DevOps is not Ops, it is administration and configuration.
A guy who i snot able to administer a linux box, set up a CI system on it AND can not develop, I never would hire.
Of course you have to know both (and many other things) to be a competent "software engineer". The question is, what will be your main work, but if you call to "support" because you have a problem with swap spac
Re: (Score:2)
Just because I'm *competent* in probably a few hundred things related to software engineering/software development, does not make me incompetent :D
The rest of your comment, I simply did not get:
Unfortunately, people like you are not the only ones wasting organizations' money.
Why would I waste money?
Most projects which grow in budget and take too much time and too much resources are that way because they are ill conceived. ... what is ill conceive and what has that to do with my demand tha
I don't understand
Re:Good. (Score:5, Interesting)
One of the problems with DevOps is that the term has completely become an overloaded marketing Buzzword that has little to do with the original intent. I wrote a long article about DevOps [linkedin.com] last year explaining that it does not mean a new team or role, but rather a culture between the Dev and Ops groups to work more closely together. The 'toss over the fence' model that is traditional with Waterfall is not working well when doing 'Agile'. Agile itself is often a pure excuse to justify 'anything goes without planning'.
Re: (Score:2)
As someone who very very foolishly sat on his laurels and let my mediocre knowledge wane even more over the past 5 years, I appreciate your reply.
The apparent expectations of system administrators, general support people appears to be going along the path of "if you don't know some kind of scripting, you're worthless". I continue to see things which seem to imply I need to be a goddamn programmer in order to get a job.
I envy programmers, they're clever people, it takes a hell of a lot of work. I've been
Re: Good-The Cloud (Score:2)
Yup. At many companies "devops" means ops/sysadmin without hardware. The old school ops guys might rack up a new server. The devops equivalent is writing some HCL and letting Terraform spin up cloud resources.
I'm the architect on our DevOps team... (Score:5, Interesting)
and this story is correct in that we haven't completely embraced DevOps. Our dev and DevOps teams use Agile so there's a ridiculous two week minimum delay for any fix since you have to add the JIRA issue to a new sprint before you can fix it. Agile doesn't work well with things that must be fixed for customers. Even worse is since most of our developers are on four scrum teams, they have four stand-ups per day where they need to talk about what they've accomplished and what they commit to doing before the next stand-up. Actually getting work done has suffered since you need to do something superficial each day for four times each day.
Re: (Score:2)
DevOps are not on a scrum team and are not bound to sprints.
They handle tickets as they come.
You probably do Scrum wrong, Agile wrong, and have no clue what a DevOps does.
Not 'You' but your organization.
Re: (Score:2)
You shouldn't need more than 1 standup a day.
And if there's extremely high priority work that can't wait for the normal cadence, then it should be a simple matter of the Product Owner deciding an equivalent amount of unstarted work to push out of the sprint to replace it. The point is to make the person responsible for the decision holds the responsibility for that decision.
Otherwise you end up in the classic model of "we asked for a million things at once and it's the developers' fault for not delivering"
Re: (Score:2)
Our dev and DevOps teams use Agile so there's a ridiculous two week minimum delay for any fix since you have to add the JIRA issue to a new sprint before you can fix it.
Wow, Agile is making you not agile. Good thing you are following the agile manifesto by putting people before processes [agilemanifesto.org].
Re: (Score:2)
There have been occasions where I spent more time creating the ticket with it's description, acceptance criteria, and detailed steps than actually doing the work.
Re: (Score:2)
And that's a surprise, why? Figuring out exactly what to do should take longer than doing it. Spending lots of time doing the wrong thing because you didn't put in the time making sure that you have a complete and accurate description of what to do and how to verify that you really have done the correct thing is a dumb waste of time.
Re: (Score:2)
That's not "Agile", that's Scrum - also within Scrum there are ways of providing hotfixes without terminating the sprint, and without waiting 2 weeks. Sounds like your Scrum Master needs some education. The Agile Manifesto literally contains "Responding to change over following a plan."
Furthermore if you have lots of issues, you may wan
Re: (Score:2)
Your story highlights the problem with 'devops' and 'agile' and countless other buzzwordy programmes companies implement. Even looking down the comments here, half of slashdot doesn't understand and doesn't agree on what 'devops' actually is. We've all worked somewhere that said "oh yeah, we do agile, we do devops" and that's the example most people seem to accept as being "the correct one". Yours looks like a horrible misintepretation of what 'agile' tries to accomplish.
For me, I'd say 'devops' is more abo
Re: (Score:2)
Four times a day!? That's obscene.
The industry doesn't consider that bad. Agile requires at least one stand-up per day per team you're on.
Re: (Score:2)
Agile requires at least one stand-up per day per team you're on.
No it does not.
There are dozens if not hundreds of agile methods, that have no daily stand up.
And if you can not cope with a 10 minutes daily stand up, you are probably an antisocial asshole with whom no one really likes to work anyway.
Re: (Score:2)
Bullshit, but true.
I work in a large company and the corporate culture can't wrap their brains around this. I'm on two scrums (two retrospectives, two sprint planning meetings etc.), even 100% allocated to the two sprints, and even more bizzare, we have the same scrummaster on both and she doesn't raise an eyebrow that I'm in both meetings.
Some people are in three.
Previously I worked in a startup. Agile was ok for me, great for the devs. As a specialist on a team of 1, sitting in a scrum of other specia
Re: (Score:2)
Why do you say four times a day is obscene? If you're on four scrum teams then that is what Agile requires. Even worse are the multiple Agile ceremonies that they require you to attend per team per sprint that take many hours each.
Re:I'm the architect on our DevOps team... (Score:4, Insightful)
If you're on 4 scrum teams, then that's entirely stupid and undermines scrum. The teams shouldn't organized to be project-based, the teams should be organized to form a tight well-functioning, and most importantly, PRODUCTIVE group.
One of the biggest values of scrum and sprints is to reduce the amount of work in-flight at once so that each thing can be completed in a shorter timeline. If everyone is on everything, then you're wasting everyone's time on context switching.
Re: I'm the architect on our DevOps team... (Score:2)
Four standups per day is no doubt a serious drag on production. But it must be supremely effective at reminding developers that they are factory workers with no status in the company and absolutely no self-agency. Which seems to be the main purpose of Agile Scum(tm) methodology.
So what? (Score:3)
The OP and article imply that this IS a problem.
It's not.
Re: (Score:2)
You're assuming because you don't do devops, you automatically have pros.
I work for a company where we don't do devops, and ops are literal idiots.
Security are also idiots. Their idea of security is the "agreement" we had to sign promising we were only going to use the internet for "work stuff".
Then they ran for months a 4-server load balancing proxy with one misconfigured proxy. It was proxy lottery. Any request going through the bad proxy didn't go through. They had to hire an external company to fix it.
Because they need to do agile devops (Score:3)
The only reason why it's not working is because you. It's your fault.
Fortunately, we can hire consultants to help you.
Comment removed (Score:5, Informative)
Re: (Score:2)
"Ok - so here's the thing. Developers should have a firm understanding of OS maintenance, firewalls, networking, security, and all that good stuff. Operators should know how to code. I wouldn't personally hire a developer whose workstation was a disaster area, and I wouldn't hire an prod-level operator who didn't know, at least in passing, a few languages."
Well said.
"But this whole "devops" thing is kind of a joke when you get to the enterprise level. The goals of developers and operators are simply differe
Re: (Score:2)
Ok - so here's the thing. Developers should have a firm understanding of OS maintenance, firewalls, networking, security, and all that good stuff.
What is this 2003? Devops is usually used in web services/microservices/cloud type environments where you don't care about that stuff. Infra is so last decade, have you heard of AWS or Azure?
What kills me... (Score:2)
Is the ones who decree a switch to an agile development process, but still want waterfall style year+ schedules.
Re: (Score:2)
Ah yes, waterfall. The rosy world of product managers where everything goes within their schedules. Where the dev is dumb, and needs a step by step use case made by the queens of the office, the analysts (all women at my company. VERY bright girls i have to admit).
But an external consultant suggested we switch to agile. So now we devs just get told over an email what to do. Because that's how agile works right?
Do i have to say this only lasted for a couple of months?
Re: (Score:2)
We call it Agilefall, as it combines the worse features of both systems with none of the benefits of either.
Re: (Score:2)
In that case, you make the issue a feature instead of a story and then break it down into several one sprint stories.
Re: (Score:2)
You can always beak it down into something that can be fixed, tested, and demoed in one sprint:
1. Pick one part of the system that not behaving properly, even if changing that one part's behavior doesn't fully solve the bug.
2. Write test case for the part the fails due to the incorrect behavior
3. Develop a change for that one part's behavior so it now passes the test case.
4. Test that the part now passes the test case.
5. Demo to the product managers that the part used to fail the test case and now passes th
Re: (Score:2)
6, Go back to step 1 and work on the first of the 99 bugs you introduced with your fix.
Re: (Score:2)
I have no programming or DB skills, nor can I see everything that's available to work with, but I'm slowly chipping away through small incremental improvements that *can* be done by our less skilled - and available - resources.
Re: (Score:2)
There must be a duration for which the above isn't true. You can't do it in a day, for instance.
What makes a two-week sprint so magical that all tasks, when broken down as you describe, can fit into it?
Is 6/14 June Fools Day? (Score:3)
Am I the only one to whom This whole thread seems somewhat like reading a transcript of the Mad Hatter's Tea Party?
Re: (Score:2)
No, you are not!
Because people with both skills are more expensive (Score:2)
And "buy one, get one free" just doesn't work here.
Devops has its place but it is not the holy grail (Score:2)
Devops has it's place for in house development where produciton and infrastructure are linked. There it is an effective and efficient way to go from Dev to test and into production.
What does my head in is the number of vendors that we see that try to bring their devops mentaility in house for the applications that they provide. They expect that we have to mirror their development environment which is often an untested disaster over and over again.
Someone doesn't understand engineering (Score:2)
I don't believe in DevOps (Score:2)
I know plenty of developers, and even more operations / administration people.
The skillset for one is not necessarily applicable to the other.
Some of the best developers I know, I wouldn't trust them to set up a basic PC for me, I've seen the mess they made of theirs. Some of the best operations people I know can't write code that's anywhere near the quality of a full time developer, but they can definitely set up a secure firewall, or configure a bunch of servers to work reliably.
Re: (Score:3)
That's me on the ops side. I suck at php. I know this. You do not want me working on the application. I'll fuck it up.
On the other hand, I excel at scripting automation for servers. I live in bash and will almost always code a better automation script than the developers. I'll worry about getting the web server optimized, keeping it backed up, and simplifying the release process. Let the developers worry about optimizing their code. On occasion, we'll work together when the situation requires a look
Re: (Score:2)
Some of the best developers I know, I wouldn't trust them to set up a basic PC for me.
In Web services land you don't need to know how to setup a PC. IaaS and Paas has eliminated the needs for these skills (unless you work at an IaaS or PaaS provider.
Doesn't surprise me (Score:2)
As a developer, I "get it" that writing code to roll up VMs, firewalls, and so on results in repeatable software. But honestly, it's boring. I hate writing code to create Amazon EC2 instances on the fly, etc. I wish I had an Ops staff to handle these tasks.
Hammers and nails (Score:2)
When the only tool you have is a hammer, everything looks like a nail.
If you're a programmer, you naturally want to use programming to configure systems. But that's not always the best way to do it. There are other, better tools for general-purpose system setup.
If you have to configure lots of systems in exactly the same, or similar ways, DevOps might be good. But for systems that are one-offs (and there are a lot of them), not so much. The benefits of automation isn't worth the cost in these cases.
Re: Hammers and nails (Score:2)
It does seem like a pain in the butt to automate provisioning and deployment of a one-off system. Until something bad happens, and you need to rebuild that system in 5 minutes. Then you're really glad you did it.
Why the hate for DevOps? (Score:2)
I see so many people complaining about devops and I don't understand why? "Herp Derp developers writing code in production" - no dumbass, that has nothing to do with devops. Devops is just your ops guys using developer tools to streamline testing and deployment.
Tools like Docker, where your entire platform is defined and described in a configuration file. All the required firewall ports are clearly stated, the number of replicas of each deployed service is clearly stated, the build process is clearly stated
It's not Devs doing Ops (Score:2)
DevOps is not about devs doing ops work, it's not about a dev installing a server, setting up firewall rules by hand with iptables and managing the disks on the server. It's about enabling devs to do their work without depending on ops, among other things. The whole devops movement is based on the CLAMS model, where the 'C' stands for Culture, and it is an important part, because without a change in mindset, you will mostly never succeed on implementing devops. It's also the most difficult thing to do, chan
Dogs & Cats Living Together (Score:2)
Oh noes! Whatever shall we do?!
Sounds like the marketing ramp up to a lucrative round of “DevOps and Why You Can’t Live Without It” consulting gigs.
Why would they? (Score:2)
Most don't need to. DevOps is this newfangled thing that happens when you've got your pipeline optimized so far that a handful of experts can code, deploy, upgrade and maintain your appstack all at the same time, while sipping lattes and playing a round of foosball inbetween. When orgs have gone "all cloud", then DevOps is a thing that basically happens automatically. But don't expect a regular old-school company going there. It's avantgarde startups doing this, and they, in the end, might end up replacing
Maybe because it's stupid? (Score:2)
Anybody who has worked in any real software company with real projects and real life infrastructure knows that you have to keep the live environment and the test environment totally separate and the development team can't have any influence on the live environment in any way. Faster and more deployments on live systems only means more chances for failures and bugs. If you need rapid changes to the live system then obviously you haven't designed and planned the project before hand. Any automatic deployment t