Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
kira26024yObviously it sucks!
@thesagya could you elaborate on this please? Really thinking switching lanes from software development to devops and would love any feedback.
Automating stuff. CI/CD crap using jenkins, and gitlab. Deploying to customer system behind vpns. Mostly boring configurations.
As long as you automate the right stuff, and implement monitoring and alerts correctly you will have a sane worklife balance.
Totally depends on the companies size, your access to the tooling, and the receptiveness of the company to automation. I’ve worked in small startup environments with full access to everything and a blank check and projects were fast, months long at most. I’ve heard horror stories of working in large banks where anything you do needs a committee of approvals and no one has access to anything. Just pick your environment well and you’ll get the chance to do interesting work with reasonable project deadlines.
DevOps for different projects, can be very different. Android usualy uses a homebrew, or fastlane. Ios uses fastlane, BackEnd projects will build one or more Docker images, and will deploy to somewhere.
In case you have automatic tests in your pipeline - then it is your job to run them, and push to manual QA, or directly to production.
Do not get me started on data migration approaches, Or API changes that need to support older clients....
It highly depends on the project I’d say..
Some devOps I know just maintain / develop CI/CD, others keep the whole infrastructure alive. Others update software and try to look busy.
I’d say it’s kind of what a software engineer was 10 years ago - they do whatever needs to be done and the most important skill is to be able to teach yourself about technologies and environments.
Some corps see devops not as a job, but as "devs do sysadmin work through code".
For us however it's 1 fulltime devops per 15 devs, 8 devops total.
👉 Maintaining/monitoring Docker/Kubernetes.
👉 Cloud management: Access rights, predict cost changes, greenlight new services.
👉 APM (application performance monitoring), bugs, other tech debt. Not triaging/solving, just tracking stats.
👉 Deciding if a migration to a new cloud service (task management, CI/CD, company chat, etc) is worth the work.
👉 Writing integrations/bots/scripts. Their job is to find out which cloud tools work together, at the right price, with easy maintainability -- but sometimes you can't avoid knotting a bunch of APIs together yourself.
👉 Writing CLI tooling (bash/python/go) to make developers happy
👉 Documentation of infrastructure, writing developer onboarding guides
👉 Security/pentests. Not directly, but they are responsible for making security consultants do their job.
Be aware that DevOps as a standalone job is something only mid to large companies tend to look for.
Especially "scaleups", successful & rapidly growing startups look for them, as they might have started on a few DigitalOcean droplets, their CEO has tried a halfassed migration to Azure, and will ask you during your interview what your thoughts on Google Cloud and AWS Fargate are.
Half of the DevOps job is knowing about pretty much ALL of the popular SaaS services, how they fit together, and most importantly: How it fits within the company budget.
If devs want to monitor backend response times, you might suggest Pingdom to a small company, NewRelic to a midsize company, and AppDynamics to a large company.
And you constantly need to be aware of overengineering & tech debt: Migrating CI/CD to a newly launched service might have advantages, but it also costs time, introduces new complexities and risks. You have to be conservative towards "new shiny toys" in production.
@newandroidfan Okay so, I'm a devops/sre guy at my company. The company is running a legacy app and trying to work on both maintaining the app (because it's a money maker) and simultaneously break down the application into microservices and develop new features. So my typical day involves maintaining and developing our ansible provising scripts, troubleshooting broken ci/cd pipelines with devs, managing our datacenter virtualization environment, the backend SAN/NFS storage devices, a certain amount of network maintenance and troubleshooting (we have a dedicated team for networking that we are supposed to escalate to once we start getting into the routing protocols and vlans/subnetting and firewall configs), we have 4 different DB's in use and we (my teammates and I) perform some basic DBO type tasks.
Backups and restores, provisioning new DB's for environments, and recently we are working merging some DB's together to reduce the mgmt overhead of them. We have a pretty large AWS environment (not the biggest I've ever seen, but it's a good size approx 300 servers). AWS stack is basically beanstalk, lambda, and RDS (because our devs tried breaking down the legacy app into microservices) we manage IAM permissions and work on keeping costs down while also trying to help with architectual design considerations/changes that the devs want to employ. (Ex: a dev wants to run a fleet of big-ass c5 servers to run some batch jobs, we try to explain and help build a working environment that doesn't require on-demand instances; like using spot-instances instead and we figure out a linux-first OS approach whenever possible to avoid windows licensing and provisioning nightmares.)
We run docker on our virtualized datacenter environment, along with windows and linux vm's for various things. We manage things like DNS, DHCP, OS patching, security, speaking of which we have to be PCI compliant because we process CC's. We have a bunch of cloud based tools like jira/confluence, ELK stack for logs, etc... that we even manage user account creation for. We handle a metric shit ton of things at our company. We also help devs and new hires with some of basic things like using sourcetree, because some of them don't know how to use git or how to use/setup ssh keys. We are a weird blend of System Admins, IT for developers, Cloud Engineers, Network Engineers, Database Operators, Scripters (bash/python/aws cli mostly)
on a side note(I was recently tasked with working through all of the WanBlow$ environment and have gotten very familiar with Active Directory, DNS, DHCP, failover clustering, wsus, MSSQL/IIS, powershell, etc...)
We are often looking through logs to find errors and troubleshoot them, usually it's seeing if the issues are in the code or if the issue is with our infeastructure.
of course all companies are different and have different needs so your mileage my vary. (alternative side note: I'm in the 80-90k range for salary in southern california. The pay is definitely less than I'd like to make, but the team is great and I'm still learning tons everyday!)
I think one of the annoying part about DevOps is that you have to play around with tooling to learn, but unlike app/frontend/backend development, the tooling costs a lot of money.
Most DevOps employees start as backenders, working for a company without DevOps.
For example, you're one out of 4 devs, writing your little PHP controller or Java plugin, and your boss screams at you that everything is slow.
You scale up the AWS server, and your boss is happy. You tell him that the company should be better prepared for this shit, that you need information about which parts of the application are slow so they can be optimized, and that you need $200/m for a NewRelic subscription and 3 hours per week to instrument & maintain servers.
Now you have a toy to play with, and someone who finances your eagerness to learn.
The difficulty is that you're currently frontend, and DevOps is kind of "deep backend stuff", so it's not a natural transition.
If you're dead set on going DevOps, I would:
1. Check out online courses about Docker, Kubernetes, etc. You practice most of this stuff on your own laptop, for free.
2. Set up build/CI/CD pipelines using some of the popular SaaS products (Travis, Jenkins, CircleCI, Codeship, Google Cloud Build, Bamboo, etc). Many have a free tier for open source projects, you can just use a dummy hello world project.
3. Explore AWS, Google Cloud & Azure. For many things you can get away with a $10/m budget for their tiniest servers, and you can explore their various services, databases, backup options, integrations, lambda functions & logging solutions.
4. Look for a small (<50 FTE) but fast growing company who needs you in multiple roles, and mention during an interview that you have ambitions to learn more about cloud services and infrastructure.
@newandroidfan I think it differs per company.
Our DevOps are required to have coding experience, and they maintain a suite of tool scripts and integration plugins. We use a whole bunch of custom GitHub "checks" for example, which are plugins developed by our DevOps employees.
In practice, they spend less than 10% of their time actually coding though.