Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
The term DevOps emerged into mainstream software development communities roughly 10 years ago. It represented a combination of tools and techniques which helped solve many pertinent issues of the time, namely responsibility for code in production and lack of a positive feedback loop. As of today, DevOps is a massive movement. It is considered the default way in which software development should be practiced. It has allowed even small teams to function with the same efficiency as much larger ones. Several engineering teams have adopted derivative approaches of the DevOps methods in order to suit their niche workflows.
The Dark Side Of DevOps
DevOps in practice presents a lot of tangible benefits to software engineering teams. Automation, transparency, and velocity are the chief advantages. From a business perspective, engineers are now more invested and accountable for the experience of users. The era of “Your Success Is Our Success” has finally arrived for engineers—and business teams couldn’t be happier.
For the individual developer, the number of things they were responsible for was piling up. More objects to monitor in production. As more features were getting built and deployed, alarms from internal systems kept going off more frequently. Individually, an engineer became responsible for the behavior, performance, security, compliance and so many other aspects of the application and underlying systems. Often, this became a distraction and began to defeat the very purpose of the DevOps methodology which meant to remove hurdles that were in the way of developers.
This is DevOps done wrong. Lack of maturity within software engineering teams has caused a lot of people to go down a DevOps path that is toxic and consequently forced engineers to burn out quickly. The core tenet of DevOps is to enable engineers to do more, but not to the point where they’re having to undertake enormous toil. DevOps still recognizes two distinct forms of specialized effort – software development and platform operations. The nature of services, scaling, and security may vary the degree to which dev and ops responsibilities converge.
Dev-Oops: It Goes Wrong Over Time
Interestingly, engineering teams view DevOps as development, and “everything else”. From the time a developer checks code into version control, there is a large assortment of workflows that kick in. Ideally, there is testing, integration, more testing, deployment and feedback. This is a large body of work, often underestimated and underrepresented. To pile this responsibility onto members responsible for development alone is where things begin to go wrong. Often, as a product ages, incident management, maintenance, and other engineering efforts pile up–resulting in fewer cycles being available for product development over time.
There is also the complementary case, where engineering teams are focused on product development and assign most free cycles to it. Platform operations are forced to become a watered-down effort and consist of the bare minimum it takes to keep the lights on, so to speak. This is a common observation in small teams and startups that typically have a new product release.
When implemented correctly, DevOps must allow engineers to take responsibility for all aspects of developing a feature and managing it in production. This means that programming the business logic, creating the declarative and non-declarative software, binding with services, building the artifact, and finally deploying to production all come under the gamut of a developer. In addition, a feedback loop—created by baking observability into the mix will provide insight into the health of the service (or feature)—will require the engineer to stay on top of the operational aspects of performance and reliability.
The current definition and practice of DevOps originated from Agile methodologies. They take off from the limitations of typically Agile teams which were released in “sprints”, still kept dev and ops efforts separate, and were agnostic of underlying tech. DevOps, on the other hand, is more tightly-coupled with the technology employed, for example: Microservices and automation. It facilitates continuous deployment and a high frequency of releases. Most importantly, it converges the notions of development and platform operations. We find that the interpretation of this “convergence” is what differentiates good implementations of DevOps from bad ones.
The Right Kind of Shift Left
At the heart of healthy DevOps adoption lies a technology shift complemented by a cultural shift. The fundamental principle that belies successful teams is a great developer experience. Irrespective of the infrastructure that powers the technical stack of a web application, software engineers who work on it need to be able to develop and deploy with ease. Let’s explore how.
Examples of tools that aid engineers during the development phase include IDEs, Source Control, TDD suites, documentation generators, and many more. Tremendous amounts of research and product development are currently underway in enabling developers to program better and facilitate more efficient development.
Different skill sets and focus areas are required to optimize different portions of the operations spectrum. In the case of large enterprise organizations, the dichotomy is clear. There are Platform Operations teams that are responsible for keeping all the systems running by providing automated means to set up and sustain reliable systems on the server side. Application Development teams are tasked with creating the applications, API endpoints, integrations and various other artifacts that will enable users to execute their tasks.
Because of the common underlying nature of both these functions–writing software–they tend to cross-pollinate. This coalescing is welcome, provided it is managed well. This is where abstractions come in handy. In particular, PaaS abstractions that provide in equal parts agility and intransigence. Pliant enough to accommodate custom workflows and bespoke needs of software products and teams, and yet preventing needless osmosis between Dev and Ops responsibilities, ultimately resulting in a superior developer experience as the nucleus of this atomic transformation.
PaaS With Flying Colors
The PaaS-low’s Hierarchy!
The perfect balance can only come from PaaS systems that comprise an architecture that is modular and offers the functionality of application build and deployment. The ability to work across multiple languages and frameworks combined with packaging and deployment best practices is a basic tenet. Abstracting the underlying infrastructure to favor support for container-based artifacts and orchestrating them at scale is the next most desirable component of a PaaS framework. A batteries-included approach to automating continuous delivery, security best practices, and other workflows goes a long way in ensuring that the PaaS substrate works for all kinds of developer needs. When using abstractions, the biggest opacity comes in the form of a lack of production parity. If the PaaS can be functional on all staging instances viz. dev, test, pre-production, prod, or any other remote instances, it would save tremendous toil arising from a lack of parity.
Bonus points for being open source and accommodating compliance, policy mandates, and customization to suit the dynamic needs of different organizations. An active community supporting the ecosystem and driving innovation and change management would make a more compelling case for PaaS tools.
