Are you a developer who is ready for a career change? You could have a satisfying challenge by switching into DevOps engineering and cloud operations. Here, I describe my own experience as I went from Ruby developer to DevOps engineer. Perhaps this article will help you decide on whether to follow a similar path. Also, if you are a manager who is considering the value of hiring developers into DevOps, please read on.
Here at iSeatz we are automating the cloud infrastructure that is used for integrating and delivering code. The goal is to reap the benefits of a DevOps culture. But what is DevOps and what is it not?
There is a natural tendency for a software company to organize development and operations into separate, self-contained departments. In this non-DevOps scenario, the operations department will resist changes and favor stability. After all, the operations personnel are responsible for keeping the system running at any time of day or night. From their perspective, developers introduce threatening changes that could destabilize the system in unpredictable ways. Uptime is at risk whenever new code is released.
Developers have a motivation to deliver features in response to client demands. The less frequent their releases are, the less frequently they will get feedback from clients. That feedback loop is necessary, because the client’s demands are a moving target. A software shop that releases software infrequently, may miss the target and the client will have to wait a long time to see if the next iteration is satisfactory. In that lag, the client’s needs may also shift. Therefore, a traditional organization is unable to effectively deliver features in response to the client’s demands. Code release cannot happen often enough if operations resists change.
Ideally, development and operations would work together to increase the frequency of releases and the quality of code by using an automated workflow.
In DevOps, deployment should be automated, but we must also address the operational concern about uptime risk. For instance, deployment could incrementally scale up from a canary. A deployment could roll back if something goes wrong, triggered by a failed status check. Smaller, more frequent releases would cause less instability than suddenly releasing weeks of code changes across multiple services at once. Further, code would be more robust and less likely to fail if automated integration would be in place. This is because code would be automatically tested and built whenever there are changes. Specialized operations personnel would build and maintain these integration and delivery systems.
In DevOps, development would no longer have resistance to the release of their code, as operations would be completely out of the way. An automated pipeline would take over from the time code is pushed into version control. From there it would automatically journey through the workflow towards release.
Also, without DevOps, there is a painful situation described as “throwing code over the wall” from development to operations. In this case, operations must maintain and configure mysterious black boxes of code. Developers are not as motivated to ensure robustness of their code because they are not on-call to service it after hours. DevOps as a culture solves this, as developers would take a more active role in monitoring their code in production, since they are the de facto experts on the components they have designed.
In this ideal culture known as DevOps, both uptime and delivery would be maximized. As an added bonus, since the workflow would be automated, extra time is gained that would allow operations to focus on security, metrics and stability.
To clarify, there is some ambiguity in the term “DevOps”. While DevOps is considered to be a culture and not a job title, in industry, the title “DevOps Engineer” is used. It refers to specialized operations personnel that build and maintain the systems for automated code integration and code delivery.
It is no wonder why companies are adopting these DevOps practices. At iSeatz, we are moving in this direction with a specialized team of engineers.
Before I joined the team, I was told it was an interesting time to come aboard. All configuration was being implemented again from scratch as part of a grand project. Every last scrap of legacy cloud infrastructure had to be replaced. The large effort was justified. Previously, it was hard to scale compute capacity and deployments were performed in-place on the same instances. The mutable deployments led to configuration drift between instances of the same application. Without standardization, immutable deployments, or scalability, we were unable to effectively respond to problems in production. It was not possible to adjust capacity to match traffic. If an instance went down it was not trivial to replace it. There was no certainty that a solution on one instance would work on another instance of the same application. Therefore, we had to get our cloud operations in order before we could embrace DevOps.
The new project involved using new tools. While we continued to use version-controlled Terraform to manage some networking and cache components of our system, all of the deployment and configuration was handled with a combination of Ansible, Jenkins and Spinnaker. Coming from a development background, the “infrastructure as code” concept was appealing to me. I am not alone here in my background, as there are members of my team from development backgrounds who seem well-suited for the task. Besides Ansible, which is a type of domain-specific language for configuration, we use languages such as Python, Ruby and shell script. The infrastructure runs on Amazon Web Services (AWS), which is a world unto itself. It is a job to keep up with the breadth and depth of services offered in AWS, and team members regularly attend AWS events to immerse themselves in knowledge. This quarter, the director of our team challenged us to get AWS certifications. The knowledge I gained from becoming an AWS Certified Solutions Architect Associate was a huge boost to my problem-solving abilities.
At first, it was a challenge to understand the wide world of operations. In my previous life as a developer I was blissfully ignorant of anything except my software requirements and the module I was developing. I had set up my own local development environment rarely, so the idea of fully configuring many applications over many environments was alien to me. Soon into my experience in operations, I discovered the domain of problem solving ranges from the big-picture to the critical details. The scope is breathtaking. It includes networking, the system of applications, data stores, logging, and metrics all humming along in real time and at scale. Also, keep in mind that operations requires being more deliberate than development, because you have access to production resources. For a developer, iteration is fast and consequence-free on your localhost and all changes are tested and peer-reviewed before being released. Yet, in operations, one misplaced command in production can bring a company to its knees. With this in mind, in operations we do exercise caution and our configuration code is peer reviewed.
With some hard work I was able to get up to speed and begin to help out with the sweeping operational changes to our system, which mostly involved writing Ansible playbooks. My first task was the configuration and deployment of the Sidekiq-based Ruby applications, since I could lean on my experience from developing such applications at my previous job. Code literacy was very helpful, since I could just study the application internally to figure out why configuration sometimes did not work as expected. Meanwhile I took on increasing responsibility over preparing software releases with Spinnaker. My familiarity with releases led to working on more automation in Ansible and Python which will save effort and minimize the possibility of mistakes. My role also requires support, even sometimes after hours. It is our duty to support cloud environments and to each rotate a week on-call to remediate production issues. I recommend asking yourself if you are the type of person who can tolerate waking up in the middle of the night to solve critical issues in production.
By now, the grand project to get our cloud operations in order has been completed and I am happy to have had a part in configuring and managing the new system. We have achieved all of the improvements we were aiming for in that project. Our production alerts are less frequent and are much easier to tackle, now. In some cases, the solution is automatic, such as when a troublesome instance will simply fail a health check and be automatically replaced by the autoscaling group. The next major project is to build out the integration and delivery systems, which are the classic features of DevOps. I am excited to move forward to optimize more of the system and I look forward to seeing iSeatz thriving with these changes. Overall, I am glad I became a DevOps Engineer.
If you are also considering the switch, why not look for an opportunity? To land a job, see if someone in your social network needs DevOps help, as it will likely be harder to switch career paths by only responding to job advertisements. Take advantage of your development skills to create your own tools or customize existing ones. You can also sign up for a free trial of a cloud services provider and get some operations and DevOps tooling experience. The more value you can show, the better your chances will be.
To view open career opportunities at iSeatz, please visit www.iSeatz.com/careers.