> The author says that developers can do these things, but I highly doubt it.

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.

As a sysadmin in a prior life, I see this as the equivalent of a non-developer (for instance, a sysadmin) asking can I create a site scraper using google, curl/sed/awk/..bash, copy/paste and a little bit of of brain between my ears ? Yes. As a developer you know there is a lot my subtlety to programming than that.

I think what @scurvy was driving at is there is a lot more subtlety to network ops than developers would be willing to acknowledge.

Yes, indeed that was my point. While the two examples I gave were easy to Google and get a "functional" setup going, there are enough things there to blow up in your face if you just go with the StackOverflow/ServerFault answers. You're going to run IPSEC, which DH group are you going to use? What cipher? How often are you going to rekey? Should rekeying be based on bytes, time, or both? Your Juniper box is connecting to a Linux tunnel server. What should your inner and outer identities be? I haven't even come to OSPF yet...

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.

And then you happily charge 10x more than a networking guy.

What Google will give you are usually some snippets for a [very] particular and usually constrained setup that Just Works™. But once you start adapting configs for your own setup - from software versions/brands, auth/app/whatever backends to security features, network setup (just otoh: Googled snippet might assume local sqlite db and you have remote MSSQL with LDAP auth, or the given setup might intend to run own unicorn and you want to proxy to supervisorded uwsgi, whatever) - things start to break in weird ways (if work at all).

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$

> 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.

The reverse is true as well. I have a dev-ops job description, but I've been tasked at one point with creating and maintaining a web app. Arguably, it's a lot simpler to write a new webapp with Google than try to determine how to configure the particular version OpenLDAP you're running or debug the last guy's custom schema.

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.

> The author says that developers can do these things.

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.

No I wasn't really outraged at all. My stance is that at some point you should stop trying to hire "full stack" developers. Chances are, they're not very good at everything and will miss some tiny detail that blows up big or creates a mountain of technical debt. Outside the founders and first three engineers, you shouldn't be hiring "full stack." You should start to specialize and start fixing the first five employee's problems.

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.

Two things:

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.

1) What if your deal partner (who intro'd the requirement for IPSEC) has a corporate security policy of IPSEC? You need the business, you'll do what they ask. Also, you can do IPSEC on every major OS, no hardware required.

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.

You are right but I don't think a lot of this is what is actually being done when it comes to whatever 'DevOps' means.

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)

I think the point of the article is that if developers were required to do this, they could do it.

yeah I think I could figure out how to do it by reading a bunch of documentation, set up some scripts to do it, whenever I have to do it take longer than necessary until I had done it enough times that I had it as one of my remembered functions, and basically perform subpar on doing this thing. Which I guess is the author's point.

Having recently tried to do this & similar in a "DevOps" capacity, before handing the task over to a network engineer, I have to concurr here.

However, the problem seemed to stem from cryptic tooling and almost non-existant documentation (especially on OSS tools).