DevOps: Coming a Full Circle


How do you feel when you listen to a remixed track from your younger days, a popular single that you loved dancing to or listening to all day. Only this time around there is something different about it, something not right, something hitting some part of you that you do not realize exactly what, but then millennials love it. They find it fresh, exciting to their groove and hate the older version that you cherished so much.

Bring in 'DevOps' and the feeling is exactly the same.

DevOps by definition is the amalgamation of 'DEV'elopment and 'OP'eration'S', wherein, instead of having separate teams for development of software / digital content and managing infrastructure, resiliency and releases, we have teams that overlap both the core functionalities. 



Voila! Something that old school development teams have grown up doing when they did not have a concept called an 'operations' teams. Back in the day, the developers wrote code, test cases, managed the DEV/UAT/PROD environments and released code to each environment themselves. Somewhere down the line organizations felt that developers were spending too much time in managing the infrastructure and releasing instead of producing more code i.e. develop. 

To help improve their efficiency and make better use of their time, in came a team called 'Operations'. Comprised of technologists, but not aligned to development, they helped setup and manage the different environments/infrastructure, handle the resiliency needs and also take ownership of releasing signed off code to these environments based on instructions provided by the development teams. Sounds perfect doesn't it? Well slowly became the nomenclature across the industry and development teams eased into the concept as well (I mean who would not like a reduced breadth of responsibilities?).

For the younger generation and newer entrants into the corporate world or the technology jungle,  organizations had already streamlined their Development and Operations strategies, so that each skill set has a fixed duty to perform and boundaries they do not need to cross. The older generation at times missed and cribbed about the days with more control (they did not need to make detailed release guides or wait for Ops team time to lookup or debug environment specific issues and could improvise if something went wrong on a particular infrastructure instead of having to roll it back). Two sets of people, two sets of exposure, worlds colliding at some point.



In comes the latest Remixed Track of the current technological trend, christened 'DevOps', a new trend which overlaps Development and Operations responsibilities, where Developers are aware of and can handle Operations activities and vice versa. The same track we heard as kids, but feel something is off somewhere, while the newer generation thinks its something new and something cool to learn.

However, this time the industry is now geared with better models and streamlined processes to govern the overlap and control the process, instead of the complete and uncontrolled access to the whole process to a single team. To understand this, we may need go over a few concepts.

DevOps doesn’t differentiate between different sysadmin categories; 'Ops' is a blanket term for systems engineers, system administrators, operations, release engineers, DBAs, network engineers, security professionals and various other job titles. 'DEV' is used as shorthand for developers in particular, but really in practice it is even wider and means “all the people involved in developing the product,” which can include Product, QA, and other kinds of similar roles.



DevOps has strong affinities with Agile and Lean approaches. It can actually be interpreted as an offshoot of Agile; Agile software development prescribes close collaboration of customers, product management, developers and QA to build and rapidly iterate towards the final product. Similarly, DevOps stresses that service delivery and how the product and systems interact are a fundamental part of the value proposition to the client as well, and so the product team needs to include those concerns as a top level item. From this perspective, DevOps is simply extending Agile principles beyond the boundaries of the code to the entire delivered service.

The primary work areas for a DevOps structure include:




Continuous Integration
A software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run. The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.

Continuous Delivery
A software development practice where code changes are automatically built, tested, and prepared for a release to production. It expands upon continuous integration by deploying all code changes to a testing environment and/or a production environment after the build stage. When continuous delivery is implemented properly, developers will always have a deployment-ready build artifact that has passed through a standardized test process.

Microservices
A design approach to build a single application as a set of small services. Each service runs in its own process and communicates with other services through a well-defined interface using a lightweight mechanism, typically an HTTP-based application programming interface (API). Microservices are built around business capabilities; each service is scoped to a single purpose. You can use different frameworks or programming languages to write microservices and deploy them independently, as a single service, or as a group of services.

Infrastructure as Code
Infrastructure as code is a practice in which infrastructure is provisioned and managed using code and software development techniques, such as version control and continuous integration. The model enables developers and system administrators to interact with infrastructure programmatically, and at scale, instead of needing to manually set up and configure resources in a manner similar to how they treat application code. Because they are defined by code, infrastructure and servers can quickly be deployed using standardized patterns, updated with the latest patches and versions, or duplicated in repeatable ways.

Configuration Management
Developers and system administrators use code to automate operating system and host configuration, operational tasks, and more. The use of code makes configuration changes repeatable and standardized. It frees developers and systems administrators from manually configuring operating systems, system applications, or server software.

Site Reliability Engineering
Operate your systems; monitoring and orchestration, sure, but also designing for operability in the first place.

What are the benefits of DevOps?



Collaboration and trust
Culture is the #1 success factor in DevOps. Building a culture of shared responsibility, transparency and faster feedback is the foundation of every high performing DevOps team.
'Systems thinking' is being aware of how your actions not only affect your team, but all the other teams involved in the release process. Lack of visibility and shared goals means lack of dependency planning, misaligned priorities, finger pointing, and 'not our problem' mentality, resulting in slower velocity and substandard quality. DevOps is that change in mindset of looking at the development process holistically and breaking down the barrier between Dev and Ops.

Release faster and work smarter
Speed is everything. Teams that practice DevOps release more frequently, with higher quality and stability. Lack of automated test and review cycles block the release to production and poor incident response time kills velocity and team confidence. Through automation and standardized tools and processes, teams can increase productivity and release more frequently with fewer hiccups.

Accelerate time to resolution
The team with the fastest feedback loop is the team that thrives. Full transparency and seamless communication enable DevOps teams to minimize downtime and resolve issues faster than ever before. If critical issues aren't resolved quickly, customer satisfaction tanks. Key issues slip through the cracks in the absence of open communication, resulting in increased tension and frustration among teams. Open communication helps Dev and Ops teams swarm on issues, fix incidents, and unblock the release pipeline faster.

Better manage unplanned work
Unplanned work is a reality that every team faces–a reality that most often impacts team productivity. With established processes and clear prioritization, the DEV and Ops teams can better manage unplanned work while continuing to focus on planned work. Transitioning and prioritizing unplanned work across different teams and systems is inefficient and distracts from work at hand. However, through raised visibility and proactive retrospection, teams can be better anticipate and share unplanned work.



All in all, this time around, the remixed track seems to be part of a well managed evolutionary process which we cannot ignore or do without. It happens to be the current trend towards which the industry is headed and we need to adapt to move ahead. There is a lot of information and tutorials available online.

1 comment:

Powered by Blogger.