In my previous post I covered DevOps from a more formal perspective. Today I thought it would be fun to relive the history of Ops to put things in perspective. The important part of any learning experience is to abstract patterns from lower level events/problems. If you were to simply start off with getting an AWS cert or building a CI/CD pipeline you might be left wondering why things are this way. Always remember each piece of modern infrastructure is a solution to previous problems. There is always a “why?” Finding this will boost your confidence and understanding.
Note on the level system: Today these terms are all used somewhat interchangeably as the job titles have converged. Don’t be offended if you current DevOps role is labeled as System Admin.
Level 1 — System Administrator
This is your introductory level. You can get a VM running on your local desktop today and start practicing running applications! Applications are often developed at this level on Dev workstations.
Manual Tasks
- Install OS
- Install Packages and Dependencies
- FTP the application to server
- Manually start and stop the application with an init daemon.
- No version control. Scripts are haphazardly written and saved on both local and remote machines.
- You find out the service is down when someone complains.
Automated Tasks
- Package commands together into a shell script.
Level 2 — Operations Engineer
This is an awkward transition period where you may not have all of the tools or experience necessary to go full automation. Level 2 and 3 are often mixed together depending on a teams/organizations maturity.
Manual Tasks
- Use console to spin up a VM image
- Resolve dependency and configuration conflicts
- At this level servers still have state, so it is important to always control and sometimes fix the state of the server.
Automated Tasks
- All configuration and script should be stored in version control
- A configuration management system like Ansible or Chef installs, configures, and runs applications.
- Application monitoring is present for every application. Operations and developers can be immediately notified of an outage.
Level 3 — DevOps Engineer
This is your final form. Both server and application errors are rare in production as they have been automatically tested in lower environments. Very little human time is wasted doing manual tasks. In security sensitive environments auditors will give you a green check mark. Pat yourself on the back! You just automated yourself out the job!
Automated
- CI/CD Pipeline runs and records all infrastructure actions. This pipeline should be connected/part of the version control system. Gitlab and Github do this really well.
- Applications are packaged as containers bound for a system like Kubernetes or sent straight to a higher level service like AWS Lambda.
- On top of application monitoring the system can now attempt automated fixes for know situations. Kubernetes will attempt restarts by default and even check if dependencies are online before continuing.
- All cloud infrastructure is provisioned as code. Terraform is the most common tool for this.
- All servers are completely stateless. Necessary application state is kept separately in systems like databases or distributed storage. Package installation is done as part of an isolated unit.
- Production servers are completely inaccessible to human hands. All changes must proceed through an automated pipeline.
Manual Tasks
- Develop the automation…for now
- Talk to other humans about what what needs to be done next…for now
Link: Intro to DevOps Part 3
