7 ms·

That sound you hear is thousands of Ops Engineers' future prospects falling further and further into question. It's becoming hard for me to justify staying in

• paulddraper 10y ago
  Eh. The further AWS moves up the stack, the less dominating their products are. EC2? Awesome. S3? Great. ELB? Good. CodeCommit? Eh. I'd be interested to hear about experiences using CodeCommit, CodeDeploy, etc. but I doubt AWS found the One True Workflow.
  • taurath 10y ago
    The more tooling you get around the higher level products, the more whole industries you will capture, at least in part. So many startups are just services adding a bit in the middle of AWS and clients, value that is slowly chipped away by Amazon. Instead of the "full team" you now have an automated lightweight SaaS. AWS's strategy is not looking for the one true workflow, its to envelop enough common usecases that it dominates nearly the whole field, giving you as custom a service as you want.
    • paulddraper 10y ago
      Totally agreed. I call it the "Atlassian strategy": be mediocre at enough things that you become enormously successful. It's a long way from a death knell to competitors though.
  • Androider 10y ago
    This does seem to be the case. CodeCommit, CodeBuild, CodePipeline and CodeDeploy feel like (and most likely were) developed by entirely different teams, and the actual experience of using any of them is not as good as your average 3rd party provider that fully focuses on just one of the pieces. The main thing the AWS equivalents have going for them at this time is the ultra-low pricing (by selling the underlying AWS services, and mostly not charging for the Code* tools).
  • Kocrachon 10y ago
    I use CodeCommit, CodeDeploy, CodePipeline. I admit, it wasn't the easiest thing to setup. But its nice. When I commit my changes to my mainline, it deploys the code to the host and configures everything for me, and keeps all my hosts up to date. Coworker uses it all to kick off lambda functions. CodeCommit is just a basic Git setup, so nothing special. But working with CodeDeploy and Pipelines is ok. I wouldn't say its much better or worst than other products, and you can use them to deploy to non-aws environments also. I don't know, I can't really sell it well. It does what it does, and it works well enough for me.
    • fernandopj 10y ago
      I use them too, and it works well. However, I do miss the days we used Heroku to handle those deploys _in seconds_ rather than 10-15 minutes AWS uses to roll out an EBS update.
  • justicezyx 10y ago
    Hmm, you are missing the big picture. AWS needs these to prevent other players encroach their ecosystem. The higher the upper-stack offerings in the tech stack, the lower the quality is requires to be dominant. But the ecosystem will secure the customers. It's not that you cannot beat AWS in one or two offerings, but you cannot beat them as an ecosystem.
    • mooreds 10y ago
      > It's not that you cannot beat AWS in one or two offerings, but you cannot beat them as an ecosystem. Very true! If you only offer one piece, then you have to 1. integrate with them and other providers And 2. Be substantially better (2x, 5x?) in order to beat the default provided by AWS And 3. Don't forget you are competing with open source options as well (where the cost is the time to set up a solution, but no cash outlay)
  • thoughtpalette 10y ago
    CodeCommit is about 10% where it needs to be in regards to other competitor features. They only support a single archaic code review tool (ReviewBoard). Once they manage a better UI and add additional features around their hosted git, should be a better sell. As is, I wouldn't use it without an extreme organizational requirement.
  • stcredzero 10y ago
    Eh. The further AWS moves up the stack, the less dominating their products are. Is this because the further they move up the stack, the more UX matters? That's Amazon's perennial weakness. Remember that Bezos says, "Your margins are our opportunity." They will get around to gobbling your market, unless it requires something that doesn't scale for them.
  • mifeng 10y ago
    This is called stack fallacy, the "mistaken belief that it's trivial to build the layer above yours," as coined by this blog post from a while back: https://techcrunch.com/2016/01/18/why-big-companies-keep-failing-the-stack-fallacy/ https://techcrunch.com/2016/01/18/why-big-companies-keep-fai...
    • paulddraper 10y ago
      Especially if your name is the letters AWS and the stack above you requires the letters UI.
• andrewstuart2 10y ago
  Those future prospects have looked different for a while, though obviously prophecy is infamously not a strength for us time-bound creatures. Change is inevitable, and especially so in the accelerated, automated world of IT. There's going to be a long tail of people unwilling to make changes (and that tail may never reach zero), but Ops as it used to exist is going to have to change, just as it did when VM usage supplanted bare metal, or when we realized that mainframes couldn't offer the performance necessary for today's scale. Really, if you're not okay with your job description evolving substantially every 5-10 years, then a career IT is going to be a source of a lot of stress for you.
  • AlexB138 10y ago
    Oh, you're preaching to the choir, friend. I very intentionally try to stay with modern trends, and evangelize to my fellow Ops people to do the same in order to continue providing value. The job description changes almost year to year anymore, and I'm fine with that. The source of my concern, which is maybe the wrong word, is that tooling is becoming so great that it's starting to look like I may not be needed on the bleeding edge at all! I love this stuff. I deeply enjoy watching technology develop and become more efficient. This feeling is something akin to watching your kid drive off to college: I'm probably not needed as much anymore, but I'm pretty excited to see how far it has all come. That doesn't mean there isn't a selfish pang of nostalgia for how things once were (and a little bit of existential fear for my future financial wellbeing).
    • whack 10y ago
      Kudos for honestly acknowledging your insecurities, and not angrily lashing out at Amazon. If you really feel that DevOps is a dead-end career choice, I hope you consider a lateral move to a different ladder, such as the SW-Dev ladder. As someone who made a similar transition a few years ago, I know how scary and difficult it must seem, and how much it hurts to go from a senior role to a junior role. But speaking as someone who's now a few years into my new role, I cannot recommend it highly enough. The long term benefits easily outweigh any short term switching costs.
    • andrewstuart2 10y ago
• metamet 10y ago
  Now would be the time to become one of the button builders. Anyone here have experience transitioning from being ops to a behind-the-scenes cloud engineer? I imagine that market is plump full of CCIEs, etc.
• ShakataGaNai 10y ago
  I just migrated from IT to DevOps and was sitting in the front row for this mornings keynote announcement. There were no collective gasps. From first pass, saying CodeStar is going to kill DevOps is like saying that Lightsale (the VPS thing) is going to kill DevOps. At the end of the day it gets you in the door with AWS until your company can be adult enough to build something for real. If anything, I think its good for DevOps. CodeStar could mean less hacked together junk at the get go. So when the real DevOps gets hired, less to cleanup and unf'k.
• watty 10y ago
  I doubt that. I'm somewhat familiar with AWS offerings and have used S3 for years. Actually creating a scalable SAAS offering correctly (emphasis on "correctly") is still a daunting task. Sure, I just created a CodeStar project which I guess hooked me into 5 or more of AWS services but now what? What if I want to create a DynamoDB or move off of CodeCommit? How do I know if it scales or is redundant? How much does this beast I just created in a few clicks cost / month - can it be cheaper? etc. etc. It may make DevOps jobs easier or help people get into DevOps but it certainly doesn't replace a trained AWS architect.
  • RussianCow 10y ago
    Genuine question: For how many small and medium-sized businesses does any of this stuff matter? Not that I necessarily disagree with you, but it seems like having one engineer who knows AWS decently well is Good Enough™ for most companies, whereas in the pre-AWS world, you needed ops people who could build most of that stuff from scratch. It just doesn't feel like you need nearly the same amount of people to scale something up with AWS as opposed to doing it in-house. But I could be wrong as I don't follow the devops world closely.
    • holydude 10y ago
      It depends on what do you call small or medium-sized business. Besides the same question can be asked about "developers". How many mediocre / junior / just developers you need "in-sourced" ? More and more work can either be outsourced to services like AWS is building or cheaper IT professionals anywhere in the world. The only question here is when taking the lead outweighs the costs.
    • watty 10y ago
      In my niche commercial industry almost all software is server-side software. Only now is everyone moving to the cloud - mostly as a way to collect data and generate some recurring revenue. So small businesses with a few devs now need to either spin someone up on AWS or hire someone. I could definitely see less ops engineers needed in some companies that move to AWS from some in-house platform but overall "devops" is rapidly increasing in demand.
• thesmallestcat 10y ago
  Come on... do you mean like how all sysadmins lost their jobs when PaaS became mainstream? Operations isn't going away, it's becoming higher-level. Demand is only increasing.
• holydude 10y ago
  Like openstack or juju killed devops ? Like Heroku killed devops ? Naah...It probably will be for more than 10 years just good enough for prototyping your applications.
• rdli 10y ago
  Here's an alternative, more optimistic view. CodeStar (and its competitors) doesn't eliminate the future prospects of ops engineers. Instead, they reduce the grunge necessary to get something working. (After all, how much fun is it to actually set up and configure Jenkins ... for the hundredth time.) So it's possible that over time, ops engineers get more time to worry about things that are harder (or impossible) to automate. For example, organizations run similar, but not exactly the same dev workflows. So understanding your existing dev workflow, and how to tune it is an ongoing thing. And with something like microservices, maybe you have dev workflows that vary by team. Or how do you tune your monitoring infrastructure to let you root cause faster, instead of just taking stuff out of the box. Etc. I could be wrong, of course. Curious what others think.
• eropple 10y ago
  Operators are probably done-for, sure, with the exception of some deep-magic systems. But DevOps? Nah. It's just that "operation" is a subset of development now (as in many ways it was before I was born, when "sysadmin" was a dirty word for "Perl hacker"). Much of my value as a consultant is that I can drop into a shop, understand the tooling and the stack, and develop a solution that makes sense, using AWS tools where appropriate or general-purpose ones where the AWS ones don't fly, and I can make it approachable for developers (not operators, but developers) with less experience and make it easy for them to hammer on it and expand it as needed. That's not going away--if anything, the steadfast drive towards understanding less of how anything you do works makes people who do understand it more valuable when the shit hits the fan. And it always does.
  • bauerd 10y ago
    I completely agree with your point. I've been investigating options for moving a SaaS application away from Heroku, over to a self-hosted PaaS stack (e.g. Kubernetes-based Deis). While I think I have a modest to solid understanding of Docker, Kubernetes, and so on, shit will hit the fan and I'll be the one to frantically dig through docs, logs and other stuff once it happens. I've toyed around with the modern DevOps stacks(tm), and while the out-of-the-box experience has mostly been really great, I'm certain the dollars we'd save are not worth the sweat. Once it's out of the box, it will break, it's only a matter of time. Someone will have to fix it. I should mention it's a very small team and the option to split the DevOps work does not exist. I'm still evaluating GCE and friends, because the amount we pay for Heroku is ridiculous. Edit: Also I feel like a need an AWS <-> English dictionary
    • eropple 10y ago
      Ehhh. This is an unpopular viewpoint, but to be frank: I've rolled up k8s at scale, and to be honest? I think you might as well just use ECS if you're going to already be into AWS. And it plugs into pretty much everything AWS does without having to either reinvent every wheel or having to build translation layers (or use ones you don't fully understand). Failing that, use EC2 and run singleton Docker containers on each instance (easy enough to do with a short cloud-init script). You already have resource segmentation. You shouldn't have enough headroom in your cluster as-is to not be using all of it (otherwise it's just deadweight loss). The set of shops that actually benefit from k8s or the like are a rounding error and so many person-hours are burned building stuff like this that it hurts. Simplicity is better than complexity until your needs require complexity. If you'd like to chat further, feel free to reach out - email's in my profile.
• petra 10y ago
  When thinking about how higher-level stuff can go(without AGI etc), programmers meet the limit at understanding the customer and explaining it to the machine, which leaves them quite a lot of work. But DevOps ? wasn't/ins't it always just a matter of time, for most small/medium sites, until someone hides all of the complexity behind a nice, smart interface and leave very little for people to do?
• morgante 10y ago
  Tools like this will just force Ops engineers to further up-skill. I live by a simple motto that anything which can be automated will be automated. That includes setting up most generic toolchains. Ops engineers have two choices: adopt a symbiotic relationship with the tooling, where they can be even more productive than before while wielding the tools, or eventually lose their jobs.
• avip 10y ago
  I don't share your pessimism. Anyone I know who has a good grasp of current cloud tech is extremely sought after. You just need to shift from "I know to edit this /etc config file" to "I know to build this on aws|gc|azure". It's actually quite liberating.
  • mewm 10y ago
    I agree, however, shifting from editing /etc config to "how to build this on aws etc", actually never really "shifted" me from not editing /etc config.
    • autotune 10y ago
      Could be argued that it has shifted to editing an attribute/variable/template/whatever in your config management tool rather than directly editing /etc config.
• rapind 10y ago
  No that sound you here is thousands of software engineers picturing being forced to use JIRA.
  • obiefernandez 10y ago
    Exactly. Nobody wants to use JIRA. At one of my employers we had a dedicated employee to "manage" our JIRA install. They also managed a team of consultants that took care of developing custom features and maintenance of the JIRA server(s), which went down often. Pivotal Tracker for life!
• ranit 10y ago
  No need to feel down. Hopefully, you built good "dev" skills (as part of your "devops"). There are no signs, these are going to be replaced soon.
• sly010 10y ago
  AWS is the Salesforce of computing. Salesforce "consultants" routinely charge $10K+ for setting up an account and configuring a few triggers. We will not loose your job, it might just look a little different. Perhaps instead of writing code, we will be pulling levers and turning knobs, but someone will have to have an in-depth knowledge of a the arbitrary limitations and the magic lever combinations. There is enough chaos in this space for everyone to make money... edit: typo
• jwilliams 10y ago
  That regular feeling of obsolescence is pretty germane to being in tech. I remember feeling that way about Quantum Computing... in 1999. The nice thing is the technology moves. In fact I imagine that's what attracted you to the industry in the first place. As these things roll forward we start doing more and the pie just grows. Maybe the future of DevOps is in managing, deploying and optimizing AI stacks? Or maybe just managing the -cost- of AI? Or how do we manage and exchange personal health data on these platforms? Or biotech experiments? Or global IoT stacks? Maybe it's managing APIs, or solutions that are federations of third-party services. So much stuff in the technology pipeline it blows my mind. Some of the harder skills may become less relevant (they'll never go away, in actuality). The principles and soft skills you have still have a long way to go.
• siculars 10y ago
  You're just being a bit hyperbolic, silly even. Managin any environment, on-prem through hybrid through cloud is a non trivial task. Don't let this or anything else make you think otherwise. Take a look at all the devops containerization, scheduling and automation software. You can do a lot of stuff. But still it takes at least one person or a team of people to actually do it and be responsible for it in production. This stuff is not as easy as vendors or aws would have you believe.
• ascendantlogic 10y ago
  By this logic Heroku should have left us all jobless years ago.
• venture_lol 10y ago
  The sound you hear is millions of devops engineers counting their money, courtesy the proceeds from migration to aws, then migration to higher and higher clouds, then, one day, once the pendulum has reached its extreme swing on one end, migration back to on-prem :) mainframe, timeshare, client server, cloud, it goes around and around