7 Design Aspects for DevOps Engineering
Assumptions
Your assumptions are crucial for a good or bad design. More code is often more complex and if you need work on to do something simple it's often a small of a wrong design. Some problems are hard don't get me wrong. However, you need to mind how many steps, files, lines of code you need to go through in order to get something done. Sometimes some decisions we made make our life harder and not easier.
The Right Language for the job
Simple tasks could be done with simple scripts in BASH, Groovy, Python or even Ruby. However complicated and important work should be on more structure and compiled language like Go, Java or Scala. I'm being opinionated here in case you didn't notice. More and more I think Python, for instance, is a wrong tool for several things around DevOps. I'm really happy doing things with Java, Scala or even Go however not quite happy about Python nowadays.
So the right tool for the job is obviously, first of all, something your time has great skills in it. Anyone can code anything in any language but to perfect it takes time and sometimes you don't have the right mindset for the language and will take time and effort to get it and somethings it just does not pay off.
Multi X Single Languages
It's hard to code in one language nowadays. When we talk about Engineering but for DevOps Engineering is even worst. So there is this natural temptation to write all in same easy and shine script thing like Python, however, we need mind how many languages we add. This is because it makes harder to maintain and support a vast number of languages not to mention that the integration gets a little bit ugly.
I'm not saying we can deal with all problems with just 1 language. Something it's possible but other times it's not. For instance in one of my solution my team had to generate images. You can do this in many languages but seriously JavaScript has the best support for charts, images right now. So we could do this in Java or Python for instance but would be harder and takes more time -- not introducing another language is not necessarily a problem. As long as you are thoughtful and proper weight in all pros and cons.
Trouble Shooting and Mantainence
That's something we don't think up-to-front most of the times. However when 6 months pass and you need change old provisioning code for the new use case you realize how much things could be in a different way and realize how hard could be to add changes in something simple - why?
There are obvious reasons for bad design and/or tech debuts but also the language you choose could be harder to maintain and debug and figure it out what is going on. Being able to remote debug is really crucial and if you have the compiler and auto-complete as your friends use it when time pass you might realize more and how much this is important.
Tech Debts
DevOps engineering is code. So it has some pros and cons like a code do. Time to time use cases change and you might lose requirements and new requirements might change. That's a good reason why tech debts happen. Another good reason is you. In theory, you will be a better engineering in 6 months, even talking about DevOps Engineering so you will learn new tricks and think differently about problems.
More people working on the problem -- As you get more people working you will get different visions. Code reviews are great and we do it but when you are coding and hacking to change things in are in way deeper engagement them in the "reviewer mode" let's say. There are things I only see when I try to change the code and I could not see it in the review moment. So yes there is tech debts on DevOps engineering and you should address.
Separation of Concerns - SOC
Going back to my first point(Assumptions) separation of concerns is moving the code where it should be -- this could be in the function level, script/class level, and system level as well. Like should you put that code on the crontab of the box or should be it in Jenkins. Should you be using Terraform, Boto 3 or Ansible? Should you have 1 single bash to do the job or have several classes and reuse somethings -- believe me there is some commons code you can find between different tasks.
DevOps Engineering is Engineering
In conclusion, DevOps Engineering is Engineering. DevOps Engineering it's not just code or scripting and it should not be because this makes things go slower and more complicated as time pass and in the end of the day this is still software and someone needs to maintain.
PS: Footnote on Python.
So don’t get me wrong. I don’t hate python. I respect the language and those who work with it. IMHO there is better tooling around JVM and I see my team more comfortable on JVM tooling. It’s possible to do great things with Python. However, I don’t think is a great fit for what my team is doing. Also bad code is bad code and bad design is bad design no matter the language. However, again, some languages force you in some directions and otherdon'tt.
Cheers,
Diego Pacheco
