Intro (represent, why choose devops, employment)

First things first, let me introduce myself. I'm an 32yrs. old Mechanical Engineer from Europe. Through all my life I was "The neighborhood guy you call when your computer doesn't work". My career starting point was a high-school's "IT guy" which was a good way to start, and a great way for me to earn money doing what I love, and also have an extra cash while going to college. This job included classic IT stuff like Windows reinstalls, hardware replacement, keeping inventory list and solving evergreen problems like "my PC beeps because I've put a book over my keyboard", "why does my header repeats itself in every page (It's what headers do, Caren...)" and so on...

Years have passed, PC's beeped, headers repeated themselves and it was time to takeover the throne and become a school's System and Network Administrator. Guess this was inevitable because my mentor was having health issues, and I've gladly chased to do as many things as I could instead of him. This position required a new way of thinking, bigger responsibilities and a few benefits of course. The biggest benefit I've felt was freedom to set the system to work as I've always wanted. Day by day, network infrastructure was changed and reinforced (with a help of my friend), students were using roaming profiles to login on any PC available in classroom etc and I could use my spare time to learn new things.

By achieving my bachelor's degree I qualified to become a teacher. Yey, something I swore never to do in my life. After first semester I had to admit it was not so bad at all. Kids have endlessly open minds and ideas which I've gladly listened to and talked to them about everything. Teaching Computer Science classes gave me a chance to point them on the right path, give them a good basics on which they can build their knowledge later. It was not about the grades, it was not about the discipline, it was about teaching them to explore and getting them ready for their careers. It also gave me a chance to iterate through my knowledge in CS. I'm not sure everyone is aware of how hard is to prepare a lesson, no matter how good you are in that subject, breaking it down so everyone can understand it takes a special kind of effort.

My Master's degree was in my hands, few years of teaching were behind me, and it was time to move on. Challenges I've had at work were not so challenging, classes have been repeated every year which has put me in an endless mind-killing loop. Cycling through possible options my friend suggested a career as a DevOps, and the google search was typed in... Continuous Integration and delivery, development cycles, releases... WHAT? Let's get one thing straight... While teaching, my colleagues and I were going to some basic programming courses (Oracle Java, Sql) and I've attended a Python workshop, so programming was not a new thing to me. But this, this was different. All those interconnected processes working together, all the platforms needed to be used seemed just like a right thing to work on.

Chasing job posts and friends that already work in IT sector was my daily routine, in parallel with learning what I could about DevOps tools and practices. Summer came, I went to a job interview in which I haven't showed much technical knowledge in DevOps, but I think they have seen my desire to learn it, and my passion about starting career in IT company. So I got hired as a Junior DevOps Engineer, HOORAY!

First days of work

It was THE Monday, I've silently entered company's office and the New World. It was sprint planning day so everybody gathered in big conference room and they started talking. To my shock, they were speaking some unknown alien language, using words I have never heard before, and displayed some presentations, which I found very nicely done. So the only thing I could do was clap when someone finishes presenting. And I did, sitting there like a kid in a theater clapping my hands repeatedly.

After planning everyone greeted me warmly, after which I followed my new team members to our space. My desk was waiting there and I couldn't wait to start working. I wasn't quite sure what "working" was at that time. But my mentor quickly had a chat with me and pointed some key technologies that we should work on. She told me to settle up, organize my workspace and ask whatever troubles me, which in next period of time I did, a lot! After setting my workspace I've had a few "meetings" with some colleagues where each of them explained some of the technologies I will use in future. As much as I listened, the more I was confused.

As the days passed, I've started to adapt to my new surrounding. My "alien language classes" were pretty much taught at our "daily meetings" where every team member explains his current work occupation, so everyone stays "in sync". When someone finishes talking, they all took some time to explain to me what was said. Patiently, I've listened, patiently, they spoke. Word by word, day by day, there was less need for them to explain to me.

Every sprint I had a new technology to explore, do some simple project in it, and then present it to my mentor. With every technology "explored" and a project done I guessed "that was it, NEXT TECHNOLOGY PLEASE". But, things just cannot go that way when you are learning DevOps. For instance, if you practice programming language, or a framework, you concentrate on it's way of thinking, you program, you learn and you get better and better. DevOps is a profession of many interconnected technologies which you must learn and logically bind them together in your head. For that to happen, it TAKES TIME. Small "cubes of knowledge" must settle down, and find their space in human mind.

Everything was going so slowly, which I later figured out is the only way to learn things. After some time I got actual working tasks which gave me adrenaline rush every time. Everybody around me were working, crowded in their tasks, but always found some time to assist me in my learning. I finally got a chance to help them, even if it was a trivial work task, I was proud! With many questions asked to my mentor and other team members, my tasks were transferred to "done" in kanban board. That feeling of closing first work task I won't forget. I rushed home and told my wife that I did some actual work today. She was like "It was about time, they are paying your a**, aren't they?".

New technologies

Ok, let's get technical... The products my company develops are based mostly on Java, so the first step for me as a DevOps was to learn how Java code is compiled and run, which distributions of Java exist, what are their key differences and which of those distributions were open source. After few days of reading and compiling simple projects I started to check different versions of Java, and how compiling in one version can affect the runtime process. So, in few days I had a chance to demolish the NetBeans software by running it in an unsupported Java version. It looked... Well... Demolished... Huge buttons were everywhere, the code part of a window could fit 3 characters (font 6). We all laughed at it, and my first lesson about Java versioning was learned.

Java's current main companion is Maven, which is my next subject. It's an "framework" for managing Java projects. It helps developers organize projects, their dependencies and build process. To get story short, it allows people to focus on actual development without side worries. Maven is a mighty tool, powered by many plugins that each cover some part of software build process. After six months of dealing with Maven, I can actually say that I've just started understanding it, and this is literally 1% of it's endless possibilities.

Next technology step I had to learn was Git. A version control and collaboration tool that is a "must learn" for anyone trying to enter IT world. You can imagine it like a time capsule that tracks all changes you (or your collaborator) made on the source code. So, when someone messes up (of course it was your collaborator, not you), to avoid punching them with your keyboard, you two can calmly sit down, and go few steps back in code changes, find the commit in which HE took a huge d*mp in the code, reset it, and continue forward. Also, it allows different sets of people to make branches from the base code, and develop different things independently from others. When they finish a feature or part of project, their code is sent to "be accepted" into main code by sending a "pull request". The changes are then evaluated, commented, polished up and if they fit the main code "merged" successfully. Everybody involved in developing the same project "pull" that changes into their local code to stay in sync. This is my short explanation of how git works, and it is far away from all possibilities and options it has. You will work in git for years and still have the "AHA!" moment from time to time (so I've been told). After six months of everyday use of Git i can proudly say "I can understand enough basics to keep working, with a few google searches for detailed commands".

"Good afternoon gentleman, my name is Mr. Jenkins. Can I have your order?"... The delicate, well suited waiter bows gently, and works it's magic. My personal favorite in all of the technologies I've crossed my path with is definitely Jenkins. It's an automation platform used for creating continuous integration and continuous delivery workflows. This is THE DevOps tool! Almost every workflow you can imagine, write or draw can be transferred into Jenkins pipeline or job. A "job" is a logical group of tasks that should be done when something happens, if something happens or when some parameters are satisfied. Job can be as simple as "power on a specific machine every morning at 09:00", which can be done by sending "wake on lan" command to a machine every morning. Jobs can also be parameterized, so a user can write an IP address of a machine to wake up ("wake up machine that has address 192.168.1.50"). Apart from the simple tasks, jobs can be built in a way that they pull the source code from a repository, build the programs, test them, and deploy them if necessary, all of that in a single mouse click. For such big tasks, multiple jobs are transferred into pipelines, which can be imagined as series of jobs that need to be executed in order (or in parallel). Each jobs exit parameters are evaluated and depending of outcome, the next step of pipeline is executed differently. Every process that repeats itself, can and must be automated! "Thanks, Mr. Jenkins, your (work) flow is magnificent".

The last, but not the least technology I must mention is Docker. Virtualization is ever-present thing in IT industry for quite a while. One physical machine can run dozens, if not hundred of virtual machines in same time. Docker is a platform that does a similar thing, but in a much delicate way. The key difference between VM and Docker is that Docker uses few layers more from the base operating system, so it uses less resources than VM. Whit that comes the great speed in which docker starts and stops containers (name of one Docker "VM"). The images that are used for running a container (a running instance of a image) can be developed on any platform (Windows, MacOs, or linux) and can be shipped and then started on other platform, where Docker will make sure that container has the same environment every time you run it, wherever you run it. For instance, we develop software using Apple devices. The shell environment and commands differ from linux shell. So, if i need to try some linux command, i would have to install some VM software, find a Ubuntu image, download it, run it, and wait for it to start. It would take me roughly 15 minutes to do that. Having Docker installed, all I need to write in console is "docker run -t -i ubuntu /bin/bash" and in a brief moment my MacOs shell prompt changed into linux shell prompt. Few things did happen in the background. The Ubuntu:latest image was downloaded and added to Docker images list, and from that image, a container was started, and bash shell was run inside of it. But it all happens in a mater of seconds. Docker takes part in every development company, it makes life easier and development process faster and more reliable. This was just a brief explaining if it's simplicity trough look of my eyes...

What I've learned

Ok, before I summarize the technical learning path I’ve followed for last six months I would like to say a few things about things I’ve learned about working in IT. First of all, IT IS GREAT! For the last six months I go to bed thinking about tomorrow’s new challenges. I wake up in the morning joyful and I can’t wait to get to work. To be honest, I thought that rush will last for a month or two, but it still does! I can’t wait to come to the office, spend time with people who share my interests, making jokes and together, trying to build something great! My whole life I knew what I wanted to do, but I haven’t got enough courage or right opportunity to do something about it. Now when I did it, the feeling is just great! I think the most valuable lesion for me in this first six months is a good old “do what you love”. Well, I heard a lot of sayings, but this one, this one I’ve proved to myself.

Secondly, if you are easily bored by doing same things over and over again, if you want to constantly learn new skills, if you like combining knowledge learned at different places, and of course if you like automating things, you can try a DevOps career. There is no end to what you can create, what kind of idea you might get to build next. Probably most of the code you write won’t ever get to the final customers, but your job is to develop platforms on which the code for the customers is built, and that’s something amazing! Your colleagues rely on your work to make their life easier, so they can focus on coding!

One of the most important thing I’ve learned is to take things slowly. It is OK to be driven by desire to learn new things constantly, but you cannot expect to understand everything right away, no matter how kind of knowledge wanted prodigy you consider yourself to be. (I consider myself more of a “knowledge wanted” than a prodigy, to get things straight). Some of the things you read, learn and try today will start getting clear in a month or two, when you try to do some other work, related to that technology, and it is completely OK. Take your time, don’t push yourself too hard, don’t try to learn everything at once, and don’t force yourself to work at home after work (a friendly advice given by friend). Otherwise, you might catch yourself in a “Halt and Catch Fire” state (google that phrase, and watch the tv show with the same name).

Finally, after this wonderful six months I can say I’ve just scratched the surface of my DevOps path that I’m following. And you know what? I like what I found under my fingernails… That vast amount of new things to learn and different approaches to create solutions, where every solution that is made, can be made even better in the next iteration of upgrades. All those thing that work together, to make one organised flow of things that runs smoothly. If it doesn’t go smooth, fix it, if it works, make it better so the flow runs 1 second faster, and you’ve just saved your company few dollars (most of modern cloud services are billed by seconds per used resource)

Friendly advice

• If you are choosing a career in IT, try DevOps
• If you cannot solve task yourself, ask for help. It is OK to be stubborn, and challenge yourself to finish the task yourself, but you have to consider time and effort you have to find a solution. Don't fall into endless vortex of searching for solution online, if you have your colleague who is always there to help you.
• Explore, be curious, and always give yourself a challenge worthy of a fight! If you finish your task before time given to you, try to make it even better, or in learning period, try to complicate it yourself a bit more, it will be fun!
• Talk with your teammates about their part of work. Ask the testers what are they testing, how and why? Try to write a simplest test with their help. Ask the developers on which module they are working, what are their plans and strategies, so in future, when you get to be experienced DevOps, maybe you will create a flow they need before they even ask. They will be well pleased and happy to have you beside them.
• And the most important advice I can give is... ENJOY YOUR WORK AND HAVE FUN!