Getting into DevOps

[Username888]

I have been working in an Applications Deployment role on a big Government project for sometime, mainly Windows based. We are slowly changing the infrastructure to a DevOps solution, which I am hoping to become involved with, - plus there seems to be more and more DevOps roles needed throughout the company elsewhere.

I was hoping for a little guidance on how I could best prepare myslelf to move into such a role.

I have recently completed a Linux & Docker training course, which I figure will give me a good foundation on which I can build upon, however, if I don't continue to use those technologies I am sure I will forget everything. Or any advice on where and how to concentrate my efforts will be appreciated. I have a lot on, so initally I going to try and put aside an hour a day on this.

Many thanks

[h0b0]

I am neither dev nor Ops but I have overseen the transformation of large organizations to move to a more agile approach. It seems that those who have a DEV background can easily adapt to DevOps and the "you build it, you fix it" mentality. Those with an OPs background are almost certainly just going to change their job title. The same is true for SRE.

My potentially biased view is that if you are Windows based you are probably on the wrong OS. The conversations I have are all about making Windows the last resort in the data centers. Yes, your developer is going to be working on a Windows machine but (s)he is going to be developing for Linux. If there is a Windows need we always ask "why?".

[fat80b]

I'd agree with the Windows sounds like the wrong place to be.

You need to get familiar with Docker, Kubernetes (K8S) and cloud providers (AWS and or Azure) as a first step.

We use all of the above, plus chef.io for deployments as well as a bunch of other services for logging, management etc.

I'd suggest picking something and building it yourself based on the above before thinking which bit interests you for digging in deeper.

[Simbu]

Devops is a wide-ranging term these days and means different things to different businesses. You could include:

- Source control integrations
- Environment orchestration
- CI / CD
- Monitoring
- Alerting
- Logging
- Disaster recovery
- Developer security tools
- etc

Our devops focused engineers tend to look after the tools that other engineers are 'users' for.

If you're using a cloud hosting provider (AWS, Azure, GCP etc) then I'd look for opportunities to play with the tooling that they offer.

On the CI side, you've got loads of options that all offer similar-ish solutions (Jenkins, Teamcity etc)

For logging, monitoring & alerting, we use ELK (Elasticsearch, Logstash, Kibana), Grafana, AWS Cloudwatch, Pagerduty. All of which are fairly popular tools and understanding them will yield some transferrable skills.

Many of the above are either open source or offer a free tier, so you can try them out.

[Username888]

Thank you all. That's very helpful - hugely appreciated

[95JO]

I'd mirror what others have said but another significant piece to the puzzle that seems to have been missed is "Infrastructure as Code". The process of developing automated, repeatable and scalable code which can deploy virtually hosted Infrastructure via the providers API's - The most common tool for this is Terraform, it's well documented and although it still hasn't released it's first major version, it's pretty much the industry standard and you can't go wrong learning it.

I'd definitely continue your learning with Linux administration and Docker, try applying it practically in your workplace if possible.

Maybe your organisation has a static webpage that hosts documentation or similar - You could create a source code repository (GitHub) and practice managing code. Firstly, write some Terraform code to provision a Linux server in AWS. You could then write a Dockerfile to create a Docker container which runs a web server (NGINX/Apache)... Then maybe pick up an automation tool such as Ansible/Chef to automate a base level configuration for your server (e.g. add users, start up your Docker container etc). Link it all together using a basic CI/CD pipeline in Jenkins/GitLab CI.

I think this is good introduction to "DevOps" tools - In a typical greenfield environment you could simply pluck an existing Docker image from Docker Hub and slap it in a cloud providers managed container service (AWS = ECS/EKS, Azure = AKS) but you wouldn't learn much.

Edited by 95JO on Tuesday 13th October 17:05

[Username888]

Many thanks for the practical suggestion and great direction 95Jo, that's excellent.

[Chris Hinds]

I'm an Enterprise Architect working with large scale COTS applications and I'm going to go against the grain ever so slightly and say I'm not so sure a Windows background is all doomed. Certainly a lot of the tools for Windows are a generation behind the Linux ones but they aren't non-existent and many of the same technologies run just as happily on Windows as Linux.

For me the bigger picture though is that [most of] the principles of DevOps can be applied on Windows too and that's a good thing... ideals like

1. Deploy small iterative improvements not big-bangs where you can
2. The Dev experts need to make sure it runs and stays running, The Ops experts need to understand why it can't stay the same for 20 years and the Sec experts need to realise it's got to go live at some point and there will always be risk
3. Design for failure tolerance
4. Stateless sessions are a good thing to have
5. Monitor what helps you improve, not what someone sold your Ops Director
6. Small groups make their own decisions, they don't go outside the team for approval (aka CAB is evil)
7. Infrastructure-as-Code is the right approach
8. Good DevOps/DevSecOps Teams don't let team members touch prod... use a pipeline
9. Configuration = Code, so manage it as such and change control it as such
10. Quality will only improve if everyone is invested in it improving
11. GUI is there to make admin easier, real control is done through coding and scripting (as a nice byproduct Dev = Test = Prod)
12. Servers are cattle not pets... kill them and spin up another environment instead of leaving them ticking over forever

There are more of course but those are things I try to look for as much as possible, and I've used them regardless of OS. But then I'm an EA not a coder/admin... where I'd be more frustrated that Microsoft DSC isn't quite as good as Ansible, and the Docker/Kubernetes community treat Windows as as second class citizen.