|
|
My experience with DevOps began before I even knew there was a name for the approach, when my boss asked me for some help in operations. The company I worked for was small at that time, so I always had the opportunity to get my hands dirty in the release automation process. I knew a few things about servers and Linux, so I was up for the challenge. To my surprise, I loved it. I knew it wasn’t the classic way of doing operations by manually managing physical servers, firewalls, virtual machines, and the like. We were using a cloud vendor. This meant that to spin up a new server, it wasn’t necessary to know which buttons to click.
The cloud vendor had his own API and SDKs for several languages, so I never really felt like I stopped programming. Of course, that was just the tip of the iceberg because systems administration is not just about spinning up new servers, adding more storage or rebooting servers. I had to take care of the architecture and which cloud services were needed for the job. But I was sure I could apply some development skills to operations, and I did. I created some scripts that launched a new environment from scratch, made backups, and restored databases.
Then, I found out about DevOps and all its practices. And because my background was in development, I was able to work with developers and explaining in their language how they could be destroying our log files and why it was important.
So if you’re a developer new to this DevOps world, trust me. You’ll like this new way of working.
You Won’t Be Writing Less Code
Because things often go wrong when deploying their latest changes in code, developers get interrupted constantly, keeping them away from the keyboard and writing less code. At first, I thought maybe this just happened to me. But when I found out this was also an issue for Ben Treynor, who created the first Site Reliability Engineering (SRE) team at Google, I didn’t feel alone. In an interview, he described SRE as “what happens when you ask a software engineer to design an operations function.”
Can you imagine that? A developer tasked with operating a production system? At first, that sounds like a scary thing. (I was scared the first time I did it.) But it turns out that this experiment went amazingly well for Ben Treynor. SREs are now lightening the workload by automating what they can and worrying less and less about the mundane, boring operations tasks.
If you’re worried about writing less code, you don’t have to be. I think we all know coding is an important skill to have. You’ll actually be interrupted less frequently if you work with the operations team, building all the machinery to do boring deployments. And if you decide to make a DevOps career path switch, you’ll be writing more code as you automate the world’s repetitive tasks.
You Won’t Have to Wait Weeks to Push New Changes
As developers, one of the things we like the most is seeing our lines of code come to life. But realistically speaking, most of us don’t get to see this every day; deployments are done every two weeks or even more. And those deployments can be really painful. Some are scheduled late at night, on weekends, or when few users are connected. There’ve been times I had to roll back because something went wrong and the maintenance window wasn’t wide enough. That’s frustrating, but it’s the nature of deployments. It’s our reality.
So…did you buy that? That this has to be our reality?
I don’t. There’s a better way to do deployments.
According to the 2017 State of DevOps Report, some organizations have been able to do four deployments per day. Now, I’m not going to lie to you. It’s not easy to get there. But it’s possible. And no, it’s not just about automation. You’ll need a critical set of practices in place to be successful. I’ve had the joy of experiencing fast deployments. In the past, we deployed every two weeks at my company. We created new infrastructure and had to test everything over and over again with a mix of automated and manual testing. One day, we made some changes in our architecture and adopted containers. We now do several deployments per week with a push of a button, and each of them takes five minutes.
For this to work, you’ll need to make adjustments at every stage of your process. The most critical change will be to increase code coverage with automated testing. It’s not just about speed. It’s also about consistency and reliability.
There will be some growing pains when you try to reduce your deployment time, but it’s really worth it.
You Won’t Have to Keep Waiting for Feedback
When you’re able to get your changes to production fast, you can’t just restart the server to solve problems. The old ways won’t work. It’s mandatory to know, in detail, what’s happening every time you do a deployment. What metrics changed? When did problems start? Everyone should have the ability to see the system status all the time. Long gone are the days when only operations had this visibility. It’s not enough to have infrastructure-level metrics; you need metrics that matter to the business, too. What those metrics should be will depend on the purpose of your software. For a site with a shopping cart, for example, you’ll be interested to know the number of orders taking place.
One of the hardest things to do is to deploy in the same way across all environments, including your local computer. It’s possible most of the time, but it gets complicated when you use PaaS in production because the idea is to have production-like environments everywhere. This doesn’t apply to data, but if you have a load balancer in production, you need it in every environment, too. You can run local VMs or mimic some dependencies. For example, you can use a local NGINX server to represent a load balancer in your cloud provider.
If you have the chance to work with containers and Kubernetes, you can use Minikube to run Kubernetes on your computer and do deployments locally. Excuse my excitement here, but I think that’s awesome! Now, it’s of tremendous importance that you can get feedback locally because that’s the fastest feedback possible. And it’s essential you have a production-like environment running on your computer. But with this, developers can truly increase credibility when they say, “It works on my machine.”
You Won’t Lose the Opportunity to Experiment
A natural effect of deploying faster and getting feedback afterward is that you’ll now be able to experiment. You’ll have the ability to say, “Hmm. What if I do this change? Is revenue going to increase? Let’s run an experiment.” Your changes will be accompanied by a set of reliable, automatic tests, and then you can wait for feedback and make a decision. I know, it sounds simple—and it is! And now that you’ve implemented these other changes, you can easily run A/B tests with your users as well.
You Will Deliver Faster
I’ve made a career change by moving from development to operations. And because of how operations has evolved now, I don’t regret it. I still love coding, and I do as much of it as I did before—the cool thing is that I’m applying development principles to operations. You’re going to delight in this new way of working, even if you stick with development. When you see how DevOps changes the way of working at an organizational level—not just at a team level—you’ll be smitten. And the way you think about your code will change too. You’ll no longer just stop thinking about your code once you finish because now you know you might be only halfway to getting your code live.
These are exciting times for a developer. You’ll be writing more code and creating interesting new things every time. More importantly, you’ll be interrupted less frequently, freeing up time for learning and allowing you to have less stress. You’ll see your changes go live rapidly, and you’ll get feedback quickly as well. That means you can remain focused on a task and do less context switching, which kills productivity. And when deployment is so frequent it becomes natural, the doors to experimentation will be wide open to you. It’s not just that bug fixes get done rapidly. The pace of innovation will also be positively impacted. Everyone will be happy.
Taking the DevOps route won’t be easy, but it’s worth it: for everyone, not just for you.
This post was written by Christian Meléndez. Christian is a technologist that started as a software developer and has more recently become a cloud architect focused on implementing continuous delivery pipelines with applications in several flavors, including .NET, Node.js, and Java, often using Docker containers.
