7 Design Aspects for DevOps Engineering

Some time ago I posted about some lessons learned by doing DevOps engineering and in the beginning of the year, I was posting some ideas and experiences(good and bad ones) around Design and DevOps Engineering. I do lots of different things on my daily basis like Architecture, Software Engineering, DevOps Engineering, Chaos / Stress Testing, Reliability Engineering, Consultancy, Management / Coaching.  I'm lucky to run a team of great architects and also code every single day,. This provides me great insights since I'm executing things but also reviewing things other people do. There are lots of things I think every day but more and more I think about Design and DevOps Engineering. The right designs and how things get bad and complicated by the lack of good design. There are several elements of good design. I already cover some aspects in other posts and today I will cover other things like Assumptions, The Right Language for the job, Multi X Single language, Troubleshooting, & Mantainence, Tech Debt and Separation of Concerns a.k.a SOC. I deeply believe some learnings are only possible after having some failures or bad experiences -- it's very hard to predict everything up-to-front.


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

Popular posts from this blog

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all language...
Keep reading

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail...
read more »