Looking For Alternate IT roles
-
@RamblingBiped said in Looking For Alternate IT roles:
So using python to architect and write a serverless application doesn't count as software engineering? Developing, testing, and deploying custom resources for CloudFormation doesn't count as Software Engineering?
^That work literally follows the same steps and workflow as developing a microservice.
Nope
That is again infrastructure as code. Python is used by damn near every Linux admin
-
@RamblingBiped said in Looking For Alternate IT roles:
So using python to architect and write a serverless application
Define application?
-
Cloudformation is just a json files. Nearly every system admin deals with json files
-
@IRJ said in Looking For Alternate IT roles:
Cloudformation is just a json files. Nearly every system admin deals with json files
...not because we like json.
-
One of the most recent examples was a python-based serverless application composed of multiple lambdas that interfaced with AWS Organizations to provide automation around creating, configuring, and deploying AWS accounts and automated governance. It is exposed to end users through a self-service portal as a Service Catalog Product.
All written in python, deployed and managed via SAM templates, and maintained via a CI/CD pipeline.
-
@IRJ said in Looking For Alternate IT roles:
@scottalanmiller said in Looking For Alternate IT roles:
@IRJ said in Looking For Alternate IT roles:
DevOps = Cross between IT admin and Engineer. It is almost solely scripting and command line based, which makes it awesome IMO.
Yeah, DevOps makes it almost impossible to keep your hats separate because you kind of role the two together.
Also DevOps roles never deal with users. Some people may or may not like that
Not desktop users. But they will often deal with software dev users or other IT departments as users.
-
And yes, CloudFormation is IAC via JSON or YAML templates. It does have more dynamic aspects that allow you to code logic into the provisioning of resources though.
(Intrinsic Functions, Mappings, Conditions, Imports/Exports)
-
@RamblingBiped said in Looking For Alternate IT roles:
And yes, CloudFormation is IAC via JSON or YAML templates. It does have more dynamic aspects that allow you to code logic into the provisioning of resources though.
(Intrinsic Functions, Mappings, Conditions, Imports/Exports)
Yeah I mean I use terraform and have used cloudformation as well. To me it's still all infrastructure as code
-
And developing a Custom Resource for Cloudformation usually involves Software Engineering, as it is either backed by a Lambda function, Application, or considerably complex architectures triggered via SNS.
-
@RamblingBiped said in Looking For Alternate IT roles:
And developing a Custom Resource for Cloudformation usually involves Software Engineering, as it is either backed by a Lambda function, Application, or considerably complex architectures triggered via SNS.
Microsoft has a good definition of IaC and everything you mentioned falls under it. Obviously you know your stuff, I think we are just using a different definition.
https://docs.microsoft.com/en-us/azure/devops/learn/what-is-infrastructure-as-code
-
@IRJ The newest approach that AWS is starting to push is a declaritive language that generates CloudFormation from code.
The Cloud Development Kit (CDK)
It is conceptually similar to stacker, but a bit more complex. It can reduce template size by up to 70%, and allows you to do conditional provisioning of resources without the added complexity of nested conditions and inflated parameter hell.
-
@IRJ I'm just saying don't sell yourselves short. A lot of "DevOps" engineers that consider themselves as having only an Infrastructure skillset are practiced Software Engineers. Its something that almost happens organically as a result of being put into the role.
-
@RamblingBiped said in Looking For Alternate IT roles:
One of the most recent examples was a python-based serverless application composed of multiple lambdas that interfaced with AWS Organizations to provide automation around creating, configuring, and deploying AWS accounts and automated governance. It is exposed to end users through a self-service portal as a Service Catalog Product.
All written in python, deployed and managed via SAM templates, and maintained via a CI/CD pipeline.
This is (IT-related) automation (DevOps), not software development/engineering/programming.
-
@RamblingBiped said in Looking For Alternate IT roles:
@IRJ I'm just saying don't sell yourselves short. A lot of "DevOps" engineers that consider themselves as having only an Infrastructure skillset are practiced Software Engineers. Its something that almost happens organically as a result of being put into the role.
I think you, myself, and @Obsolesce have an advantage because we have system admin backgrounds. IMO that is more valuable than development experience for DevOps
-
@IRJ Absolutely. I mean, blending the skillsets is hard approaching the role from either perspective, but understanding how software runs on infrastructure is super important; especially as more and more automation and code replaces the traditional admin duties going forward.
-
@RamblingBiped said in Looking For Alternate IT roles:
@IRJ I'm just saying don't sell yourselves short. A lot of "DevOps" engineers that consider themselves as having only an Infrastructure skillset are practiced Software Engineers. Its something that almost happens organically as a result of being put into the role.
Yes this is a good point.
There are two sides:
- Moving into devops from a Software Engineering background
- Moving into devops from an IT Engineering/Administration/Operations background
Both are equal, overlap, and some things do not overlap. A DevOps person from a Software Engineering may ALSO do software engineering, but that doesn't mean a DevOps person from an IT background does.
-
@IRJ All that said, I hate touching/managing servers.
-
@RamblingBiped said in Looking For Alternate IT roles:
@IRJ All that said, I hate touching/managing servers.
+1
...well, not physically. But I don't mind automating for them!
-
@Obsolesce said in Looking For Alternate IT roles:
@scottalanmiller said in Looking For Alternate IT roles:
@Obsolesce said in Looking For Alternate IT roles:
What exactly would a f500 company pay someone $400k to administer, who isn't a management title? Because, whatever system they are administering and being paid that much to do it I need to learn it ASAP!
Linux primarily is what pays in that range. I was literally consulting for a hedge fund two weeks ago talking about them setting their admin scale to $450K for the more senior roles. A manager admining something is crazy, totally different skills. Places that give manager titles to tech roles are the ones that will never pay well.
Windows will almost never top $300K, regardless of the role.
So what is it that a Linux systems admin does in a F500 to get $450k that the same role gets for 1/4 that in a non F500?
A lot, actually. So just using myself as one example.... here are some things that make Linux administration different in a high demands environment...
-
Outages can be worth in excess of a million dollars a minute, just being the guy who doesn't need to pee before fixing a problem can make the difference between a $100K salary and a $300K salary. Literally, that one thing, once during a critical outage, is all it takes.
-
Loads of servers. A single snowflake admin might have six hundred unique, critical servers. That's just a lot of work. A DevOps guy might have tens of thousands. For myself, I had 650 snowflakes that I directly managed, 8,000 snowflakes for which I was the "buck stops here" guy (L5 admin), and 10,000 in a DevOps environment that I was directly in charge of. No SMB has that many servers across all staff, let alone for a single person.
-
Unique Issues. Solving nanosecond kernel tuning issues "never" happens in the SMB. You just don't run into those problems. In the F500, you can end up being the only shop in the world hitting a specific bug or adjusting a kernel in a specific way. Having done administration in both realms, the day to day differences are actually pretty big. One is very "by the book" and essentially trivial. The other there is no book and you have to know the hardware and software inside and out and do things that you can't research in Google.
-
Automation. An SMB can automate, an F500 has too. This isn't the big difference it might sound like, but it's a difference. Just one of many factors where something is cool and good in the SMB, but a foregone conclusion in the F500.
-
Advisory. Even if you are the best SMB admin every and you are asked to sit on the SMB's board of directors (this happens to me, for example) it's trivial compared to what you do in the F500. Being the IT guy on the board of directors for a company making $50m a year is nothing compared to being the business advisor to the managing director of a "product" that moves a trillion dollars (yes, for real) a day. The order of magnitude of responsibility, risk, and expectations is unbelievable.
-
Currency. In the SMB people hope that you "keep current", but running an OS from five years ago isn't going to get you any looks as long as you patch it. Run Windows Server 2012 R2 today and people go "haha, time to upgrade", but they assume you are still doing your job. In the F500, we are dealing with the OS and hardware vendors constantly testing things expected to release one or two years out. You are not just on the bleeding edge (in what you know, not necessarily what you deploy), you are past the edge! The research and information you have to keep up on is completely different.
-
Security and Responsibility. For me, my hot seat position meant I was the last line of defense. Not just did I have to secure the systems, but I was the judgement call for people accessing or trying to access our systems. I've come down to a single call away from having the FBI walk people out in handcuffs (employees making big money because they pushed their luck too far.) My meetings would include the head of the CIA or the head of the Federal Reserve Bank. I've been followed home by private investigators (and spies.) I've had my phone tapped. I've had to work in sealed buildings. I've been in meetings where risk is assessed at a political and nuclear war level.
-
Performance. Being the end of the line support means you are on call 24/7/365. For me, that was ten years with only one real break. It can be intense. Few SMBs actually depend minute to minute response at that level. They might act like they want that, but you actually get to sleep most days.
-
Access. I was a key holder to the global exchange trading floors. I had that responsibility to get in places where even senior managers could not go.
-
Personal Judgement Calls. At my level in banking, one of my tasks was to "breach protocol." Technically not allowed, and no Senior VP could do it, but my personal role was the one guy allowed to "ask forgiveness" rather than permission. If a MD called me, and I concurred on a change, break, shut down, or whatever, I was the sole person able to override bank policy and ignore my managers and do a change or whatever. Boy do you have to defend those decisions, but it was my job to either stand up to policy and break the rules to protect the bank; or to stand up to the division heads and not let them make a change to their own systems. I had no overriding rules, other than SEC of course, and always had to make the final call. And a bank MD is like going toe to tow with the personal owner of a multi-billion dollar multi-national company. A division might be worth $10bn USD or more.
Just some of the ways that high end big administration is different from what you typically see in the SMB or in the F500 trenches.
-
-
@IRJ said in Looking For Alternate IT roles:
@RamblingBiped said in Looking For Alternate IT roles:
@IRJ I'm just saying don't sell yourselves short. A lot of "DevOps" engineers that consider themselves as having only an Infrastructure skillset are practiced Software Engineers. Its something that almost happens organically as a result of being put into the role.
I think you, myself, and @Obsolesce have an advantage because we have system admin backgrounds. IMO that is more valuable than development experience for DevOps
For sure. I have both backgrounds, so I'm extra lucky. But my SA background is 90% of my DevOps skills, my Dev background is only 10% (and I have 30 years of dev, and have owned a development company for essentially half of my life.)
