5 ms·
Every year cloud providers announce tens of new services, poorly tested and far from production ready. Non-ops eng teams and management are always happy to use
by andmarios 8y ago
Every year cloud providers announce tens of new services, poorly tested and far from production ready. Non-ops eng teams and management are always happy to use the latest buzzword out of AWS, then ask their ops team to make it somehow work.
Certifications are moot. I don't care if you are certified, or if you have used a cloud (or kubernetes) following a tutorial. I do care if you have seen enough issues throughout your career, so you can debug every time (not when, nor if) mud hits the fan. I don't care if you can type a port in a yaml file or in your browser. I do care if you know how many ports are there, what's the ephemeral port range and so on. Systems are 75% experience, 25% basic knowledge, you can't get away just with certifications which matter only after you get experience and knowledge.
If you are experienced in ops, I know you can learn and work out any cloud. If you claim you are experienced with a specific cloud though, then better have to share a ton of war stories or it will just be a huge red flag on your CV.
Let's call it for what it is, clouds, like data-science are hot fields right now. It's only natural that many people will go after a good-paying job claiming expertise in the field.
- scarface74 8y agoIf you have experience in ops and don’t know the specifics of how to do operations in the cloud and take that same mentality to A cloud provider, you are going to end up spending more and not get any benefits from being with AWS/GCP/Azure.
- andmarios 8y agoIndeed, but ops people have to learn new technologies all the time, so it's not that big of a leap. When you talk about a cloud and see a sysadmin rolling their eyes, it's not that they have something specifically against the cloud, it's that they've seen so many diverse bugs and issues in their life, that they know you just exchange one set of problems for another. Also, a challenge to using clouds more effectively is you need to bring onboard your developers. Ops people often have to act as coaches and basic systems' knowledge is very important in this role.
- scarface74 8y agoIt’s not just about learning a new technology it’s about learning a new mindset. Unfortunately part of that mindset is giving up control over the underlying infrastructure, automation, and could be making yourself or some of your redundant. Not too many ops people that I’ve dealt with that move to AWS reach for Python, CloudFormation, creating custom resources with lambda to plug into CloudFormation, etc to automate. Most won’t even use System Manager to automate EC2 maintenance.
- ldoughty 8y agoI've seen a good number that do once the org makes it a priority and allowed money to be spent on learning and experimenting. From there, some people still want to stick to their old knowledge, but chances are you still will need that. Only start ups are "easily" going 100% Serverless. And even then many still want a few 24/7 servers. So there's still a job for older ops. Ops people tend to be slower because brand spanking new tends to be over hyped and the brand new thing was designed with a goal for ease of use and performance. Security will be added on perhaps next year. Systems manager is cool, but if you already need to use something else to orchestrate, it's often easier to use that and keep a smaller toolset.
- scarface74 8y agoIt’s not about going serverless, it’s about how to automate the management of servers. When my manager first came, the one ops guy we had was manually going through a list of EC2 instances and patching them. That’s an old mindset. We have a third party web application that was on one server and when it went down, they would get an alert and reboot it. That was an easy win - put it behind a load balancer and an autoscale group with a minimum and maximum of 2 and http health checks so it would just kill the instance and bring a new one up. This same guy saw a lot of EC2 instances that he didn’t recognize come up in the middle of the night and wanted them to follow our naming conventions APP0x and wanted to know the IP addresses. It took me forever to get him to understand that they were ephemeral, were part of an autoscaling group based on a queue, and that he couldn’t put whatever old school alerting system on them and they were all tagged with the corresponding autoscaling group and environment. The best I could tell him was the subnet that they would be launched in and the corresponding CIDR block.