To be frank with you, DevOps has never been my thing. If the term DevOps inspires a single one of my neurons into motion, that neuron is my boredom detector. Upon recognizing DevOps, my boredom detector sends the tiniest yawn to the part of my body that stores yawn energy. And if I gathered enough yawn energy, I will invariably perform the infectious act in private or public; I don’t discriminate with yawns.
But after careful examination of the articles in this list, the part of my mind responsible for obsessive-compulsive needs to automate and organize has found a kindred spirit in developer operations. With DevOps working at capacity, the code my colleagues and I discharge upon the world can reach its target destination, the end-user, with minimal human intervention and maximum code coverage.
In these articles you will find tips, getting started guides, as well as the philosophy behind DevOps.
Steven J. Vaughan-Nichols
As a complete novice in the DevOps world, I found Vaughan-Nichols’ introduction to DevOps enlightening. For one, I had a total misunderstanding of operations and the people involved. I found this quote particularly valuable:
Development-centric folks tend to come from a mindset where change is the thing that they are paid to accomplish. The business depends on them to respond to changing needs. Because of this relationship, they are often incentivized to create as much change as possible. Operations folks tend to come from a mindset where change is the enemy. The business depends on them to keep the lights on and deliver the services that make the business money today. Operations is motivated to resist change as it undermines stability and reliability.
I related to the development camp but was sympathetic with the perspective of operations teams. The merger of these two diametrically opposed objectives allows organizations to deliver continuously without fear of ruining their business. DevOps is that merger.
Touched on in the previous article, Kornilova emphasizes that DevOps requires commitment from the entire organization—top-down. To help DevOps leaders bring skeptics on board, she targets the main groups: developers and operations leaders. Early DevOps teams should look for small opportunities to improve workflow on both sides of the aisle.
Developers will see the benefits of DevOps when they compare earlier deployments to those optimized by their DevOps team. These optimizations will lead to more frequent deployments that run faster and with fewer hiccups. On the operations side, DevOps can shrink downtime, reduce failures, and smooth-out all rollbacks. But as Kornilova points out, it won’t happen right away in an organization filled with skeptics:
Start small with the cultural shift, too — don’t expect to sell DevOps to everyone at once. In fact, by winning over smaller groups with specific projects, you’ll create ambassadors who can help promote DevOps elsewhere in the organization, creating a multiplier effect. As you build your business case, you should also remain mindful of potential obstacles to long-term DevOps success.
Mary K. Pratt
Pratt’s key point in her popular CIO article: despite soaring IT project delivery rates, the delivered projects continue to fail. Leaders traditionally believed that a project’s success was synonymous with its prompt delivery. As organizations moved to agile methods and improved their ability to deliver, they expected a complementary bump in success rate. However, across industries, IT projects continue to fail (but for new reasons):
PwC’s 2017 Global Digital IQ Survey polled 2,216 business and IT leaders from 53 countries and asked them what hinders digital transformation. Some 64 percent of respondents said lack of collaboration between IT and business is to blame, 58 percent cited inflexible or slow processes, 41 percent listed lack of integration of new and existing technologies, 38 percent named outdated technologies and 37 percent put down lack of properly skilled teams.
Collaboration between IT and business—if there’s a better slogan for DevOps, let me know.
Farcic appears to be a strong voice in the DevOps community. He’s a frequent speaker, consultant, and successful author on the topic of DevOps, more specifically, Docker. Docker is for many organizations the VM-replacing Northstar toward which they navigate their efforts. And for the teams that have already set up a static Docker cluster with continuous deployment, Farcic’s 2.2 Toolkit looks to take it a step further by building a self-sufficient cluster:
The goal I set in front of me is to build a self-adaptive and self-healing system based on Docker. The only problem is that I do not yet know how I will do that. There are different bits of practices and tools I’ve been using, but there is no clearly visible light at the end of the tunnel. Instead of defining what the book will be, I defined what I want to accomplish.
5. Google, IBM and Lyft launch Istio, an https://techcrunch.com/2017/05/24/google-ibm-and-lyft-launch-istio-an-open-source-platform-for-managing-and-securing-microservices/open-source platform for managing and securing microservices
Put on your best Stanley-knows-what-he’s-talking-about hat because I’m about to jump to conclusions. Istio grants developers, “a single service mesh that provides the monitoring services to then implement the necessary load balancing, flow-control and security policies they need to keep their applications running even if the network isn’t reliable.”
That sounds an awful lot like the promise of Farcic’s self-sufficient Docker cluster from DevOps 2.2. The key difference between Farcic’s path to self-reliant clusters and the one developed by Lyft is that while Farcic focuses on Docker directly, Istio requires Google’s Open-Source Kubernetes platform.
Ronald van Loon
Van Loon provides us with a great piece of content (that happens to pitch his platform, logz.io), but let’s not dock him any points for that. Van Loon paints a picture of the on-call DevOps engineer as they receive the dreaded midnight-on-a-Saturday error; the kind of error that requires immediate attention. Enter a mass of server logs. The engineer must parse these logs to find the right blip that maybe, just maybe leads her to a solution. Picture the agony.
Van Loon introduces an AI alternative:
This groundbreaking technology uses machine-learning algorithms to match human domain knowledge with log data, along with open source repositories, discussion forums, and social thread. Using all this information, it makes a data reservoir of relevant insights that may contain solutions to a wide range of critical issues, faced by IT operations and DevOps teams on a daily basis.
But he doesn’t stop there; Van Loon shares other DevOps responsibilities that AI may soon optimize beyond human capability.
VSTS, or Visual Studio Team Services, is a platform that combines different project management and delivery tools into one. VSTS merges Agile project management, Git repository hosting, continuous integration testing, and continuous delivery into a single tool. Meanwhile, VSTS permits developers to integrate any toolchain—not just those provided by Microsoft. In this one-hour video, Abel Wang introduces viewers to DevOps and Microsoft’s powerful VSTS platform.
Let’s keep the VSTS train going by introducing another video presentation from Microsoft. In this one, Brian Harry and Abel Wang discuss the latest features of Azure, VSTS, and Team Foundation Server that help streamline DevOps tasks.
Linux Professional Institute
The Linux Professional Institute provides an attractive option for developers who wish to establish their DevOps skill set and advance their careers. The LPIC-OT certifies developers in Git, Jenkins, Docker, Kubernetes, Vagrant, cloud-init, Packer, Ansible, and more. From LPI:
The LPIC-OT DevOps Tools Engineer certification sets you apart by demonstrating that you are skilled in working with tools that help to increase IT process efficiency and enable product innovation.
10. Accidentally destroyed production database on first day of a job, and was told to leave, on top of this i was told by the CTO that they need to get legal involved, how screwed am i
cscareerthrowaway567 (a Reddit handle)
Oh to be a freshly-minted computer science graduate. I’ve been there, but I have never been to where cscareerthrowaway567 has gone: DevOps hell. By following what I presume was an awful setup guide for his personal environment, this fledgling developer accidentally nuked the production database. This resulted in catastrophic data loss and this juvenile engineer’s immediate dismissal. Their former employer threatened them with legal action and blamed them solely for the loss of data (and not the team's lack of DevOps protocols).
I cannot imagine a more appropriate article to leave you with than this one. This sad story proves how critical a role DevOps can play in an organization. Without a proper set of rules and clear separation of responsibilities, chaotic deployments that obliterate your production database are not only possible but likely in an environment that hires college graduates (pretty much every organization). I hope that when armed with these articles, videos, and books, you gain new insight into the trends and technologies behind DevOps, advance your development operations to new levels, and keep your production databases from, you know…