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.