▲ 92 points
back
148 comments
Software dev who just switched to devops recently. Good luck to whoever will manage an AWS infrastructure on his spare time between developing one feature and another. Seriously, the cloud is not shifting roles. Actually, the more everything gets moved to AWS, GCloud, etc.. and the more the level of abstraction will grow - the more you will need specialised devops IMHO.
Overall, disappointing article.
> Good luck to whoever will manage an AWS infrastructure
> on his spare time between developing one feature and
> another.
(edit: Think about $MEGA_RETAIL_CORP. Their main-line of business is not software development, but retailing. Despite being a large company with deep pockets, they have difficulty recruiting the best and the brightest in the DevOps world to come and work with them. When $TURNKEY_DEVOPS_CORP approaches them and offers their devops as a service product, $META_RETAIL_CORP eagerly signs up.)
I disagree. The argument is about things like AWS Beanstalk. Once all of your deploys are going out with Beanstalk, most of the AWS management disappears. It's basically Puppet and Chef taken to the extreme if you use all of it's features. Once your one DevOps guy gets your scripts set up to easily deploy, what else is there?
And the easier it is to build up large systems that require an organizing principle to avert catastrophic failure from a developer that doesn't understand all the moving parts. (I say this as a developer. I know my limits when it comes to ops).
Seriously. It's impossible to manage systems (ops) and develop at the same time if you have any sort of complex system. With AWS and such, you need permanent ops to deal with all the bugs, issues, and slow support. With a solution like Docker you need someone to set that up and manage the cluster. Either way, you need ops unless your infrastructure is very basic.
I'm one of those developers... it's manageable if you have the right skills and interest. I'd say I spend on average 2-4 hours a week maintaining our Deis PaaS on AWS. I'd be happy if we had someone working full time on this but we can't afford to.
It's Techcrunch.
As someone who's worked on software, as a developer, and done operations for quite a some time, I imagine I could do both together quite easily.
Given that I've done this a while, I have a bunch of patterns and reusable things, that use to deliver something quite quickly. Once it's up and running, your job is to patch. Obviously developers like to be constantly running the new shiney thing, but if you put a foot down on that, stick to a low number of well known tools, and don't chase fads, you'd have a lot of time to work on features.
However, it also depends on where you are and what you're outsourcing. If you want me to start from nothing and decide we're using a whole bunch of tech I don't have patterns for already, it's going to be a while before you see me come up for air and do any features.
It also depends on what you're hosting though. Much of what we're selling is just a fancy CRUD app, they're easy to run.
Aws/Gcloud bring DevOps and Developers closer together. We are able to work together with a better understanding of the tools being shared. Now I am able to set things up in the Development ENV, and DEVOPS can create a process to manage and automate the transition to Production. Sure I could write the scripts and tools, and it makes DEVOP roles more attainable, but it doesn't diminish the role by any means.
The commentary here is missing the point. The article is about managed services, not EC2, and yes, it is killing devops. My team just built a very successful ecommerce company doing respectable traffic volume with zero ops or devops.
We built it on Google App Engine. If you don't like GAE there are other PaaS providers that offer something similar. Developer life on a PaaS consists of building features day in and day out. It's not mucking with Docker, Chef, Ansible, Salt, Puppet, BOSH, apt, yum, or any other low-level systems management tools. This stuff doesn't even waste space in my brain[1]. Instead of learning this stuff, my team has been been learning about the business needs of our customers and building them out in code.
I plan never to hire a devops team. Running servers is like writing assembly language; appropriate only for companies with very specialized needs.
[1] Not quite true - I used to work on the BOSH team. It's a great tool for deploying CloudFoundry. But you shouldn't use BOSH, you should use CF, hosted by someone else.
I recently interviewed a PHP dev who asked me why we even have backend developers. From his perspective, we could just use Parse and it would do all the "magic" of the backend.
Then Parse shut down.
I think the lesson here is, you should never trust your core product to a third party. Also, when you use cookie-cutter services, you really limit the kind of things you can do, and vendor lock-in really, really limits your options in the long run.
I am reminded of a comment by someone famous:
"The first software companies had thousands of developers. The second wave of software companies had hundreds of developers. The next wave of software companies will have 1 developer."
Can't find the source, might not be the exact quote either, sorry.
Do you have a SLA with Google? Do you have any plans to proceed if they just shut down GAE within of a few months?
This has happened with Parse, and this will happen again.
I absolutely agree. If you want to stay in the AWS world, look at Elastic Beanstalk or Lambda. I've been doing DevOps for years and most apps (internal or external) that I deploy anymore are just one Jenkins job that packages and deploys a Beanstalk version. Give Devs permission to Jenkins or have it auto-poll git and I never need to do anything else.
What about the team(s) that manage the underlying PaaS/SaaS Services?
Does DevOps or SRE's not exist in this realm?
DevOps is dead? Well I guess that means I can finally delete my fat repo of Ansible, Terraform, and Packer configs. Using AWS, GCE and others doesn't get rid of DevOps. You're just managing computers in someone else's data center instead of your own.
>DevOps is dead?
Fyi, the title is using the rhetoric template of:
<SOMETHING> is dead. Long live <SOMETHING>. [1]
It's as if someone wrote "Cars are dead. Long live cars." to signal the change from humans manually driving the cars to AI robots doing it. If you read the "cars" literally, it looks nonsensical because there are obviously cars existing both before and after the shift to automation.
[1] examples:
http://www.pcoitmurphy.com/_books_are_dead__long_live_books_...
https://www.tnooz.com/article/hotels-Airbnb-rented/
http://www.wired.com/insights/2014/08/moocs-are-dead-long-li...
I agree.
I recently created a private cloud infrastructure on Digital Ocean. It would have been easier and faster (and more polished) if I'd gone with AWS, but then I would know how to use AWS, and would not know how to do these things myself.
Why learn about HAProxy, keepalived, tinc, etc when you've got AWS to handle it all for you?
Answer: Because relying on a service to abstract the inner workings for you is a path to the dark side.
The article is muddled. It's like some came up with a title and then tried to support their conclusion with rambling thoughts without much cohesion.
Deadlines, I guess.
You definitely need to delete your Ansible, Terrafor, and Packer. Typical Linux distro is a lot larger than your project, but it works fine without that, at hundreds of platforms. Did you learn how to achieve such level of flexibility?
I think the analogy with QA deserves some credit here. "Testing" as a part of software process has not gone away, but the people who solely did QA are now gone - either evolved into doing both dev and qa; or moved to companies where the older processes still exist.
Testing was more closer to writing-code - so that got absorbed into the dev side faster. Disappearing QA was a you-blink-and-you-miss revolution.
DevOps is a little farther. Several developers are not able to wrap their heads around the deployment systems, the implications of hardware and network etc. But they will. Eventually. Because they are smart people.
I think the message of the article is that people who solely have DevOps expertise, should look to evolve to developing code as well. That way we have smaller, well-knit teams with each member having an additional speciality other than writing code.
My current job seems to disagree with you and their point about QA. As far as I've been able to see, the market explicitly for QA Automation is actually growing. The idea of
>Developers are responsible for full test automation and making sure their code works.
Is laughable outside of [insert new sexy startup here], if only due to the difference in mindset.
Granted I'm totally biased as a QA Automation, but the analogy actually removed quite a bit of credence that this article might otherwise have held with me.
What I have noticed more and more often lately is people who say:
"Yeah, I'm in team X and I do the Devops part"
So we basically have an "ops" person sitting with the devs, and call the team a "devops" team. The devs have still no idea how to deploy their code. The ops have still no idea how the code looks like. But hey everyone feels better.
This is also true for many job offers in the form of "looking for a devops engineer". No, what they are really looking is for an ops person that has to sit in a dev team and do the part no one likes to do. s/He will be lucky if s/he can actually spend 10% of his time producing application code.
No, what they are really looking is for an ops person that has to sit in a dev team and do the part no one likes to do. s/He will be lucky if s/he can actually spend 10% of his time producing application code.
So? What's the problem with this? DevOps generally means someone who uses developer like approaches (e.g. scripting, automation, developing one-off solutions, etc) to solve operational issues. It is a role, and someone has to do it, and I would argue that there are people who love to do this role.
But if someone sought a job in DevOps thinking they'd be producing application code, they only fooled themselves. If someone sees some sort of status issue and forever tries to fight against their role, well that's just detrimental to everyone.
My title is DevOps Engineer and I still don't know what the hell that actually means – but who cares, I was hired to bring a new mindset, not a new toolset, to the development team I sit with. You're right, there's lots of devs here that don't know how to deploy code well or what configuration management is, but part of my job is spreading awareness and continually asking the question: how can we do this better. That is the spirit of DevOps, and that will never die.
What is much, much better than the alternative, where dev sits on their own room, with their own teams, and their own hierarchy, ops do the same, and there's a feud between both.
The title is a bit click-baity and misleading. DevOps isn't dead it's just becoming centralized.
The rub seems to be that quality managed services are widely available and affordable enough to obviate the need for in-house DevOps.
> The rub seems to be that quality managed services are widely available and affordable enough to obviate the need for in-house DevOps.
I have yet to find developers who are throwing themselves at carrying a pager.
DevOps isn't going away. Its just less relevant in smaller teams. Larger teams are always going to have an ops team.
>>DevOps isn't dead it's just becoming centralized.
Should be fun for the Fortune 500's. Part of the justification of moving to the cloud was laying off the sysadmins and other people that did "DevOps" before it was called that.
Once it's centralized, the human instinct to "ensure survival of the group" means the DevOps team will get bloated in headcount, budget, tools, etc.
I assume that will be followed by some new wave of features called the "AI Cloud" or something that manages itself, allowing you to now lay off the new centralized DevOps team :)
Google SRE and Netflix Devops are places where Devops is not a mindset or culture but type of engineer that requires operation and development skills.
The reality is the field is less welcoming of specialized developers. We all have to develop, test, and deploy our code. Call yourself whatever you want but make sure you comfortable doing it all.
I've started reading the Google SRE book that was just released, and now I know more about the people I have to work with when the situation arises. Liking it so far :)
http://www.amazon.com/Site-Reliability-Engineering-Productio...
I love that the screenshot is HTML. DevOps is known to be very heavily HTML based work... .
In a proportional font. Ew.
One funny things I noticed about DevOps culture is that it is usually presented as developers should do more ops. I never quite saw it go the other way, encourage existing ops to do more development. Wonder why that is.
Devops and QA are more alive than ever. The article actually makes that point. It is just that the boundaries between the disciplines are being blurred consequent to the erosion of distinctions between hardware and software, testing and deployment.
It would be more precise to say that the era of the code illiterate sysadmin or QA engineer is coming to an end. So is the era of the developer who didn't understand the basics of operating systems and networking.
This is based on the premise that DevOps is a team of people, it's own silo. And that is not what DevOps is about IMHO...
QA is dead because Agile killed it? (quoth the article)
I work at a Fortune 10 company and this is just wrong.
Furthermore, leveraging QA in an Agile process is critical to continuously improving our software quality.
Ops teams are more useful when they're analyzing data and improving architecture based on the results of their analyses. The ideal ops role is beginning to phase out the "overqualified support engineer" framework and usher in the new idea of being an "infrastructure architect".
To me, this article is more about the architectural/business decision of outsourcing as much as possible to 3rd-party services instead of reinventing the wheel in-house. How many Chef repos have the same stupid passenger cookbook vendored in? How many times have you had to fuck with that cookbook because it broke or something got updated? My websites for http://psychedeli.ca, http://brother.ly, and http://www.waxpoeticrecords.com are hosted on Heroku and, apart from the occasional Redis issue, they've been chugging along quite smoothly. I've had little to no issues with my development and continuous deployment process, which give my apps the same safeguards that I get with work (even more) with no one needed to "watch over" the project...other than me of course.
DevOps has never been more popular in the whoishiring thread. I run monthly trends on the postings, and DevOps just entered the top 10 of terms used[1].
[1] http://www.ryan-williams.net/hacker-news-hiring-trends/2016/...
"why not simply teach all developers how to utilize the infrastructure tools in the cloud?"
You need someone to liaise with the Cloud company, set everything up, test it, organize changes, and update the system regularly with new functionality. Even if a Dev had 10 years experience managing infrastructure, they still shouldn't be doing it because they should be developing products. If only there were someone whose job it was to manage Operational changes, and liaise with the Developers... Hmm.
And by the way, not everything is moving to the Cloud. We've had managed services in one form or another since the early 90's, and the result is always the same: the service provider is blamed for things working shittily and the company brings services back in-house.
And his continual refrain that "QA is dead" - does this guy understand product development lifecycle? Whether you're designing a brand new product or just bringing out a new version, you have to have QA. Can you imagine a medical device or medical web service being developed without QA, or QC?
Thanks for the troll, TechCrunch.
Devops is dying. And the secret weapon is not mentioned in the article (Docker).
With Docker and a scheduler (swarm, kubernetes, etc), what are you going to use Chef or Ansible for? Just to install Docker on a Linux instance? Docker is just getting started, and we can already see that they are going to make a lot of tools and companies obsolete.
So, DevOps as you (mis)understood it is dead. Long live DevOps as it was meant to be understood.
Look, I appreciate what people are trying to say about this stuff, but there's one universal truth that managed services absolutely cannot get around: Cost. As someone that's bootstrapped a couple of businesses from zero, I have had to lean heavily on my ability to work with bare metal. It is an incredibly valuable set of skills that translates literally to more money. Managed services will not kill off DevOps because there will always always always be companies that want to be profitable sooner, or don't have a ton of money to throw at AWS.
Second, this is a really clickbaity article.
DevOps != Ops.
You don't have a DevOps guy, or a DevOps team. You have a team that does both development and operations. The less work they have to do (like the reduction of effort with managed services) the better, but it's still work we need to do.
If you call out DevOps as a specific role, they you're not doing DevOps. Just like those practicing "Agile" are likely lacking in actual agility.
As someone with the label "Application Developer" who's been having to develop and deploy and learn my company's entire backend without much help other than "oh, here's the username/password for that, here ya go" from my superiors in IT, I don't know what to think of this.
The servers and databases are all managed by my one boss, but I'm basically now responsible for every aspect of my application's lifecycle. While I'm a 1-man team now, I know down the line we're looking to expand and I'm trying to set things up right for when that day comes - proper version control, and an automated way to push updates to my Django app.
I was looking at Docker and the likes, but we're unfortunately running Microsoft SQL Servers and Windows Servers which apparently aren't going to see much support for virtualization/containers til the SQL Server 2016 version comes out. My company is an engineering firm, not tech, so paying for an AWS bucket or me making a case to get the fuck away from Microsoft backend stuff (the headaches I've had with MS SQL already...), etc etc probably isn't high on their to-do list.
Maybe due to the sort of company I work for this article just doesn't apply to me anyway, but it seems like the author assumes any company rolling out software or a service is doing so at the cutting edge and as its primary focus.
I'm not sure my struggle to find a sane way to automate our deployment and updates would be helped too much by literally any of the cloud based services anyway. Even if they gave me a green light to go all-out on whatever service I wanted to use, at the end of the day I'd also have to manage all of those services and their connections to the app as well. I'm trading off some work for another kind, and a lot of these cloud solutions are hardly painless.
If you automate sysadmin then you can make the case that sysadmin is dead, not the people who write the automation.
Just one thing taken from the article comments:
> HTML used as the screenshot is as horrible as article.
+1
looks around my devops office
I guess our company didn't get the memo?
In my experience developers have had to set up continuous deployment environments. If you design a set of cloud resources for your application in a dev environment, you are the best person to script that deployment into another environment. So the developer of the application ends up having to script the deployment as well. DevOps always seemed like too much communication between team members for too little benefit.