Journey into DevOps
My passion for programming started when I was in college. Like some of you, from the first euphoric sense from compiling a Hello World program, to the sleepless nights of debugging complex systems, coding provides the constant roller-coaster thrill in the life of a developer — but this is a story for another time. At this point, I have written software for over thirteen years and have contributed codes to numerous projects ranging from enterprise applications to gaming systems. Sometimes I believe I have seen it all, but like the wise will say, there are always new things to learn.
Coding is but a small and humble part in the entire development lifecycle. Look at it like a small cogwheel in the larger-than-life software machinery. Some argue that coding is the heart of things, the core, the fundamentals and therefore, it must be the most important, right? Well, maybe. Coding a simple application is different from the implementing the big ones. When I say big, think really big, think really complex. Imagine yourself in-charge of the software operating the Death Star. Yes, that kind of moon-size big is what we are talking about. Excited now? Countless gargantuan systems working in tandem with one another, all working reliably and seamlessly. Well, they ought to.
Now here’s the problem, writing clean and efficient codes is a good start, but even the most stable software will experience change. There will be upgrades. There will be new features. There will be bugs. Fixing one thing sometimes breaks another. We need to fix them and fix them fast. It is also crucial that we focus and move at lightning speed to deliver these updates and patches to ensure business continuity and maximum impact. And guess what else? All of these need to happen while ensuring 99% system uptime. You read that right. Can this even be done? I used to daydream about that myself. There must be a way. But if you were thinking of doing this manually, I believe no amount of coffee bean supplies in town can keep the team going.
As developers, we are often familiar with using some form of automation in our projects. If you haven’t, you eventually will because I believe it is really a matter of time. After all, some tasks other than coding can be quite repetitive — compilations, copying files and running unit tests (possibly being the most notorious). I personally use ANT and scripts for my builds. However, there are equally important things beyond the sphere of individual development. For example, how do we ensure code quality is adhered across the team? Can we automatically spread workload across servers based on availability? Are we ready to deal with hardware failures? Finally, do we really need to care about all these? Yes! Because remember, we are operating a moon-size space station. There’s little room for boo-boos. Can’t we bash script everything head to tail? Hell yeah, with enough effort, you technically can. No kidding. But a better question to ask would be — What is an ideal way to do this?
Enter DevOps.
DevOps is neither a tool nor a technology. That’s right, sorry to disappoint you if you were expecting a super-software-automation-tool, but I promise this is way more interesting than that! DevOps is a practise of combining both software development and operations, and no prize for guessing — the name is an obvious blend word resulting from both terms. At the heart of this culture, DevOps strongly advocates automation and monitoring throughout the entire software development life-cycle. This means wherever you are, at every step of the way, you are part of a larger movement that believes in the virtues of highly automated systems to coordinate the construction of complex software. Are you with me? Good. The goal of DevOps is to encourage shorter development cycles and more frequent deployments. Not only will we benefit from continuous software delivery, we will also resolve problems faster, improve coordination and produce reliable systems. This will result in a team that is highly streamlined, yet flexible and extremely responsive to change.
Sounds familiar? No, I’m not talking about ninjas. DevOps has a strong relationship and historical connection to Agile — a very nimble discipline. You will find plenty of on-going and very passionate discussions about how they are same-same but different. Regardless, we can both agree that the Agile practise is highly successful and its pursuit for fast and continuous integrations falls in line with DevOps’ own philosophy. We’ll talk about this relationship one day.
Now, DevOps doesn’t rely on a “one tool that rules them all”, therefore there really isn’t one particular software to focus on. Rather, DevOps uses a toolchain — multiple tools that corresponds to key aspects during software delivery. In fact, various scripting tools could be a minute part within the entire process. And as I mentioned earlier, automation is the heart of all things DevOps, so these tools are expected to support some form of coordination along the way — development, testing, integration, and eventually deployment and monitoring. While all these sounds mighty and good, remember — automation must be done with a strategy in place. Without one, software will awaken and consume the world. Kidding. Instead, without proper planning, you will be the one staying awake to fix the mess.
Despite seeming like a really tall order, learning the right tools to use at various stages will definitely make this undertaking less intimidating. As we embark on a journey into the world of DevOps, I hope to discover new tools, strategies and concept that I can further share with you. I believe this is the right direction to understanding a holistic overview of software architecture and infrastructure. If done properly, a continuous integration pipeline can deliver a software more reliably and faster than you can say lightning-speed.
