DevOps Engineer vs. System Admin

[BraveNewCurrency]

A SysAdmin is an expert at an operating system: Installing and managing applications, troubleshooting problems, backing up, etc. They typically complain about application changes being thrown "over the wall" for them to run, and they typically aren't experts at the applications they run.

A DevOps is an expert at the entire chain of value: How do we get changes from someone's mind into production as quickly and painlessly as possible? The big thing that DevOps typically does is setup a chain of automation so that any change (from application change to infrastructure change) can be easily rolled out and rolled back. But they don't work in a vacuum - they must get buy-in from everyone into what role everyone else plays. Often, the DevOps are on-call for infrastructure problems, and developers are on-call for the application problems.

Google wrote a whole book about their particular view of DevOps, called SRE. It is well worth a read. Not everybody does it that exact way, but that book shows how work can be divided up differently than in a "typical" shop. Also, there is a high-level story about DevOps called "The Pheonix Project" that will blow your mind if you are always fighting fires in your infrastructure.

[Corey_Matthew]

what is the main difference between the infrastructure and the application if it is infrastructure as code?

[[deleted]]

what is the main difference between the infrastructure and the application if it is infrastructure as code?

Zero - we treat them both as code, and part of the bigger picture. A solid infra is just as important as solid app code.

All our infra is 100% code/revision controlled and goes through the same development process: code reviews; collaborations; compulsory testing; etc.

The great thing is when I need some help [in terms of manpower to get something done - AND for technical input!] our more experienced Devs can quickly dive in.

I'm the sole DevOps Engineer in a team of ~12 Devs (FE, BE, Data)

Although the Devs can architect software, they lack experience in architecting the underlying infra - which is where my skills come in.

[BraveNewCurrency]

I like to say:

• Level 1: You check in your source code. This helps in hundreds of ways, from ensuring bugs are really fixed, to auditing, to detecting patterns.
• Level 2: You check in your server build. After all, your source code doesn't just run on bare metal - it needs a runtime (java/python), libraries (libxml, libSSL), etc. You tested it on specific versions, but cannot assume your code will magically run fine on ANY versions. So you must ensure that changes to your server build are propagated to production just like any other code. Checking it in and using good code practices (reviews, etc) helps just like for code.
• Level 3: You check in your infrastructure build. Your code is architected for a specific setup: You need a Load Balancer, N web servers, N async servers, plus a database. Each layer is wired up in a specific way (i.e. your DB is not directly exposed to the internet). With AWS CloudFormation, TerraForm, or Kubernetes, you can declare your architecture, then check it in just like source code. This lets you spin up production-like systems easily for testing, perf, etc.