8 ms·

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 a

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.

jt2190 11y ago
> Good luck to whoever will manage an AWS infrastructure > on his spare time between developing one feature and > another. The point of the article is that this work will be outsourced to companies that specialize in DevOps, that most companies that develop software will not need the specialist in-house. (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.)
- deleted 11y ago
  [deleted]
- oblio 11y ago
  They're just moving the turtle lower. Now we'll have horror stories about devops outsourcing just like we have those about dev outsourcing :)
davidpatrick 11y ago
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.
ownagefool 11y ago
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.
brianmcconnell 11y ago
It's Techcrunch.
joesmo 11y ago
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.
- hobs 11y ago
  I think the reality is that it is somewhere in-between. Most companies dont want to spend on ops anyway, so they provision the least number of devops people and then complain that their deployments are slow or whatever results they are attempting are produced slowly (mostly due to emergent work due to ops struggles.) I really like the goog model of your SREs spending 50/50 dev time and ops time, because it forces a shift in how you are deploying things and the ops people have a big say in whatever the devs are doing (not the case in many companies.) It is not impossible to do any of these things, but you cant get around the basic complexity problem by saying "oh this is dead now, just pay someone else to do it." because the fact is you are giving over your keys to the kingdom. For instance, People have been saying for years that "The DBA is dead." but I work with many companies that building new database driven products, thinking they can handle concurrency and growth, and then when the real complexity starts occurring because their abstraction is a bit leaky shit hits the fan. An argument against specialization only works when you have completely replaced that industry with something entirely better (we dont have a lot of blacksmiths anymore), and that has definitely not happened for devops.
pilom 11y ago
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?
- mentat 11y ago
  Until you need to do one thing outside the Beanstalk pattern, then you're dealing with CloudFormation templates all the time.
  - dfsegoat 11y ago
    No. You learn to use it just like you would a normal linux box - or you use their managed container service which is basically plug and play with docker compose.
    - mentat 11y ago
      Actually you don't or else you break the whole scaling / immutability model. I'm talking from production experience here. I ended up moving to OpsWorks and the level of abstraction worked better for me then.
      - pjungwir 11y ago
        I'm curious what you thought of OpsWorks? I tried it a couple years ago, when it was really new, and it was pretty painful. I'd rather just run Chef myself on regular EC2 instances and Autoscaling Groups. I recall a lot of issues hooking into the OpsWorks lifecycle at the right place, broken Berkshelf support, failures with no good error messages, an even slower build-test-fix cycle than usual, discrepancies between the OpsWorks cookbooks on Github vs what was actually run, and difficulty testing things out in Vagrant first. Has any of that gotten better?
        11y ago
LamaOfRuin 11y ago
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).
olalonde 11y ago
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.
- fernandotakai 11y ago
  same where i work. we have team of about ~10 backend guys and we share the load of doing 'devops'. i would prefer having a guy or two dedicated to it, but we make it work.

jt2190 11y ago

> Good luck to whoever will manage an AWS infrastructure > on his spare time between developing one feature and > another. The point of the article is that this work will be outsourced to companies that specialize in DevOps, that most companies that develop software will not need the specialist in-house. (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.)

deleted 11y ago
[deleted]
oblio 11y ago
They're just moving the turtle lower. Now we'll have horror stories about devops outsourcing just like we have those about dev outsourcing :)

davidpatrick 11y ago

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.

ownagefool 11y ago

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.

brianmcconnell 11y ago

It's Techcrunch.

joesmo 11y ago

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.

hobs 11y ago
I think the reality is that it is somewhere in-between. Most companies dont want to spend on ops anyway, so they provision the least number of devops people and then complain that their deployments are slow or whatever results they are attempting are produced slowly (mostly due to emergent work due to ops struggles.) I really like the goog model of your SREs spending 50/50 dev time and ops time, because it forces a shift in how you are deploying things and the ops people have a big say in whatever the devs are doing (not the case in many companies.) It is not impossible to do any of these things, but you cant get around the basic complexity problem by saying "oh this is dead now, just pay someone else to do it." because the fact is you are giving over your keys to the kingdom. For instance, People have been saying for years that "The DBA is dead." but I work with many companies that building new database driven products, thinking they can handle concurrency and growth, and then when the real complexity starts occurring because their abstraction is a bit leaky shit hits the fan. An argument against specialization only works when you have completely replaced that industry with something entirely better (we dont have a lot of blacksmiths anymore), and that has definitely not happened for devops.

pilom 11y ago

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?

mentat 11y ago
Until you need to do one thing outside the Beanstalk pattern, then you're dealing with CloudFormation templates all the time.
- dfsegoat 11y ago
  No. You learn to use it just like you would a normal linux box - or you use their managed container service which is basically plug and play with docker compose.
  - mentat 11y ago
    Actually you don't or else you break the whole scaling / immutability model. I'm talking from production experience here. I ended up moving to OpsWorks and the level of abstraction worked better for me then.
    - pjungwir 11y ago
      I'm curious what you thought of OpsWorks? I tried it a couple years ago, when it was really new, and it was pretty painful. I'd rather just run Chef myself on regular EC2 instances and Autoscaling Groups. I recall a lot of issues hooking into the OpsWorks lifecycle at the right place, broken Berkshelf support, failures with no good error messages, an even slower build-test-fix cycle than usual, discrepancies between the OpsWorks cookbooks on Github vs what was actually run, and difficulty testing things out in Vagrant first. Has any of that gotten better?
      - 11y ago

LamaOfRuin 11y ago

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

olalonde 11y ago

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.

fernandotakai 11y ago
same where i work. we have team of about ~10 backend guys and we share the load of doing 'devops'. i would prefer having a guy or two dedicated to it, but we make it work.