Being able to do something from memory is something we only care about in high school. Take me, for example: did my router support L2TP termination? No. Did DD-WRT support it out of the box? No. What a developer can do is cobble together information in order to find a working solution. So would I, as a non-Dev-Ops be able to set up MPLS over IPSEC, having never done it before? Yes: I have Google and I have a brain between my ears.
I think what @scurvy was driving at is there is a lot more subtlety to network ops than developers would be willing to acknowledge.
While just an example, it shows that our professions all have subtlety and nuance to deal with. You gain the ability to handle this through experience, not Google. Throwing a "full stack" developer against every problem is definitely not the solution.
It is a much smaller issue if you are building a system from scratch and only the launch date depends on your speed, but if you are trying to modify a part of mission-critical running deployment that already generates a revenue stream... well you have to first negotiate reasonable maintenance windows and then must squeeze yourself in. Googling around will give you zero clue how much time fixing broken things will take, because, well, deboogling is done by error messages as keywords.
Furthermore, only an experienced (I'm refraining from a term "trained" here) professional can evaluate multiple possible setups, give proposals to decision makers with more or less quantitatively expressed installation/maintenance/growth costs, evaluated downtime/security risks and business impact (solution A might forget the order while still charging the customer with 0.001% chance, while solution B might forget to charge the customer at all with 0.002% chance when the load reaches 47 requests/s, so which one?). Sometimes you just want to deploy something small quick and then at some time transition to something bigger. And knowing when that is reasonable and when the small system will stop handling the load allows to actually forecast and take weighted decisions.
To the defence of DevOps: cobbled together solution is often the best (weighing in deployment time/costs) for small internal services, first dev environments or early startup prototypes. And for large deployments, someone having a clue about both sides (code and operations) is necessary to moderate the decision taking process. Because what an operator thinks to be a quick change to code might actually take several man-weeks (who was the idiot behind this architecture?) and what a developer thinks to be a small change in configs, might actually require changing core hardware (what a moron deploys like that?). In my own short experience (including, but not limited to IT/CS/EE), I have failed to witness a project where everything is decided upfront and does not change until at least first (alpha/beta/customer preview) release. The more startupy the project (the less domain knowledge), the more first release target deviates from initial goal.
Just my 0.02$
More like $2000. Very enlightening. I was reacting more to the conclusive nature of this:
> The author says that developers can do these things, but I highly doubt it.
That is not conclusively true in all situations. If my employer came to me and said: "figure it out," I definitely could and would. I would first recommend they hire an experienced devops but it's not like I could never learn it.
Dev and devops are not different like brain surgery and heart surgery are. Either role can grow into the other role and eventually (for the most part) do well at it.
But really, the author here is just misguided. Just because you can 'figure it out' eventually, doesn't mean you'll be cost effective at it. Employee productivity comes from specialization. It's not about how many jobs you can do, it's how quickly you can do them well. When developers are paid well, it's because they have specialized knowledge, just like DBAs and network engineers. There's not even really a need to put developers on some fucking pedestal make the argument against 'full stack developers.' It functions purely as bait for angry comments.
I couldn't find this in the article.
You sound even more outraged and polarized than OP is. I've met more than one developer able to do this (hint, I can also do it). Some people are actually paid to write networking software, and they often have a clear understanding of how JunOS and IOS work.
This said, for different reasons, I agree that network operations should not generally be done by your development team, but no one is arguing this anywhere.
As the business grows, you're going to need some specialization skills for some project or deal that comes your way. You should hire the right person for that job. Chances are, you needed them all along and this situation is a good catalyst to get them in.
1) The developer would just say - no, instead I'm not going to use IPSec, and I'm going to bootstrap this myself with TLS. I'm going to push complexity UP the stack, not requiring esoteric network hardware to do this.
2) I think this is a bug. The fact that the underlying devices don't have easy to understand semantics is problematic. I think that if an interested developer had a program that requires MPLSoIPSEC, they would consider it, read the relevant RFCs, and then read Junos's documentation and give up - because it's locked down.
2) Again, you could use Linux for this. You can ask the whitebox switch guys, but there's a lot of stuff Linux can't do. It's a great cause and I've got a few whitebox switches in my lab, but there's definitely still a place for Cisco and Juniper in this world.
Where I work I'll push into production a few times a day after testing in staging and the only changes really are what container is running what code.
The firewalls and routing tables I don't manage and with good reason (unless they are on AWS since security groups are pretty cut and dry but even those basically don't change much after initial configuration)
However, the problem seemed to stem from cryptic tooling and almost non-existant documentation (especially on OSS tools).