DevOps

DevOps – Cloud = No DevOps!

mali79, , Leave a comment

In the last post we looked at the DevOps tool chain which looks something like this:

devops-toolchain-v2

It is important to note when viewing the above visualization is that it does not depict “where” code is deployed – in particular what are the platform choices one needs to consider for successful DevOps. To answer this questions, its critical to gain an appreciation of why traditional IT infrastructure approaches and platforms are non-conducive to DevOps. Lets take a look once again, at the methodologies that IT has had to contend with for the most part in the past:

waterfall-v1-14dec2016          agile-v2-14dec2016

In both approaches an infrastructure provisioning cycle that is anywhere from a few weeks to several months (still the case with a majority of enterprise IT organizations) is acceptable. In the DevOps driven agile approach, with continuous deployment objectives into production (as depicted below), this type of an infrastructure provisioning approach is a clear fail.

devops-methodology-v6

In short, for DevOps to be successful, you have to platforms that development teams can self provision as and when needed, and that can scale when required – i.e. you need just in time infrastructure, or in other words, cloud, to do DevOps. In fact it wouldn’t be stretch to make the claim that:

Cloud without DevOps can deliver some substantial advantages, however DevOps without cloud is a non starter.

This being said we are not (yet) making an argument of what type of cloud architecture makes most sense – i.e. private, hybrid, or public, or IaaS vs. PaaS. Neither are we making a claim as to what the optimal unit of deployment for DevOps is – the code alone (think serverless, e.g. Amazon Lambda), code in a container (e.g. via Docker or via a PaaS based solutions viz. CloudFoundry), or maybe even a VM. As you can imagine the answer to these questions is non-trivial, and generally use case dependent. We will examine all of these options and their applicability in future posts.

Before we go there though, we will spend time looking at two more ingredients without which DevOps is a non-starter – the right Operating Model, and perhaps the most intangible and hard to implement of all, culture.

Advertisement
DevOps – Cloud = No DevOps!

The DevOps Toolchain

mali79, , , Leave a comment

In our last post we depicted a DevOps-driven agile methodology, which looks something like this:

devops-methodology-v6

vs. a standard agile methodology, which looks something like this:

agile-methodology-v4

We then went on to describe 4 critical ingredients that are required to succeed in optimally implementing a DevOps-driven agile methodology, including

– The DevOps tool chain
– The DevOps operating model
– Platform
– Culture

In this post we will cover the first ingredient – the DevOps tool chain – in more detail.

To do DevOps right, it is critical to automate, re-architect (re-arch), and/or implement  as many of the activities involved in the development, build and test, and deploy workstreams as possible. The table below outlines the key activities within each workstream, whether these activities are in-play for automation, re-arch, or implementation, as well as the typical benefits derived from automation, re-arch, or implementation of the activities.

benefits-devops-toolchain-v3

It is worth noting that in agile development, each “sprint’ cycle is generally anywhere from 1-3 weeks long, with around 2 weeks being the typical sweet spot. Without the automation, re-arch, or implementation of all of the activities listed above, it would be close to impossible to deliver a DevOps-driven agile methodology. What would remain with limited automation would look at best similar to the more traditional agile development process, and at worse a legacy waterfall process. This does not however mean that automating, re-architecting, or implementing any of the key activities outlined above, in and off itself does not drive any benefits. For example automating functional testing reduces the amount of time required to regression test as well as reduces human error. That said, in order to increase the the velocity with which code is deployed to production, i.e. to implement a DevOps-driven agile methodology, all or most of the activities outlined in the table above have to be automated, re-architected, or implemented.

So what does the DevOps toolchain look like, in terms of the vendors that play a role in it? The image below is an attempt at visualizing this:

devops-toolchain-v2

As we close it is also worth noting that when companies, vendors, and recruiters are typically referring to DevOps, they are referring to the “DevOps toolchain” depicted in the image above, much more so than any other aspect of DevOps, i.e. the philosophy and methodology, or its operating model, platform, and cultural dependencies. It is worth remembering (and reminding) though that adopting DevOps, minus the operating model and culture in which DevOps can thrive, will significantly minimize the value of DevOps. Moreover adopting DevOps without the appropriate platforms (read cloud infrastructure) is typically a non-starter. More on these in future posts.

The DevOps Toolchain

The DevOps Philosophy & Methodology

mali79, , Leave a comment

In the last post we looked at why we consider DevOps a practice, and less a movement or a culture. To recap we then updated the definition of DevOps as follows:

DevOps is a practice with an associated philosophy, methodology, toolkit, and operating model, that enables the rapid deployment of software.

Let us now take a  closer look at the philosophy and methodology driving the DevOps practice.

The DevOps philosophy can be summed up as simply as this:

Ship quality code to end users as fast as possible.

This philosophy is driven to a large degree by another related philosophy surrounding the lean startup movement (in my opinion much more representative of a movement than DevOps), i.e. the “fail fast” philosophy. Startups have embraced the “fail fast” philosophy nearly completely, and the philosophy has now rubbed off to the enterprise as well, to the extent that conglomerates like GE are leveraging the “fail fast” philosophy to develop everything from new types of pizza ovens to rally fighters.

So how are startups and even enterprises today able to “fail fast” and, arguably more importantly “fail cheaply”? From a software development perspective they are able to do this because they leverage a methodology that looks something like this:

devops-methodology-v6

Product development teams leveraging a lean startup approach recognize that in order to reach their critical first milestone of obtaining product traction or proving market viability, they have to release software (or hardware) to end users for feedback early and often. A DevOps driven agile methodology fits perfectly into this new product development paradigm.

In contrast though the typical enterprise software development methodology for the longest time (and still to a great extent today) continues to be a waterfall methodology that looks something like this:

waterfall-methodology-v2

…and now perhaps with the slow, but inevitable adoption of agile in the enterprise it has started to look something like this:

agile-methodology-v4

What is key to note here is that even though with agile you are producing code faster, you are not necessarily deploying that code to production systems as fast you should in order to solicit the necessary feedback required from end users to “fail fast”. This is primarily due to the following factors:

  • Organizational misalignment: even though your design, development, and test teams have begun to function in an agile manner, the rest of your organization, in particular operations and various infrastructure teams still continue to operate in a waterfall approach.
  • Toolkit gaps: in order to deploy code to production as quickly as software is built and tested a toolkit is needed that almost entirely automates the entire build, test, and deploy process.
  • Platform gaps: what type of platform are you deploying your code on? Are you deploying on an IaaS or a PaaS based platforms, or on more traditional legacy infrastructure? Legacy infrastructure lacks the self-provisioning and rapid elasticity capabilities provided by cloud technologies, and these capabilities are an absolute must for DevOps to be successful.
  • Company culture: is your company culture aligned with the lean startup movement and fail-fast philosophy? If not, then even if you address all off the above, i.e. your companies organizational structure, as well as toolkit and platform related gaps, chances are the adoption of DevOps will still not deliver optimal results, and will most likely falter.

In the next post we will look closer at the toolkit gaps are and the DevOps toolchain required to close these gaps.

The DevOps Philosophy & Methodology

DevOps – its not Culture, and its not a Movement

mali79, , , , Leave a comment

What is DevOps? If I had one scenario to pick for which to use the phrase “everyone has a different definition of X”, it would be to define DevOps. In my entire career in business and technology I have come across similar confusion only twice – the first time was with the definition of “cloud“, and the second is with the definition of “omnichannel“.

So what is DevOps? If you look up with definition of DevOps on Google you get this – “DevOps (a clipped compound of development and operations) is a culture, movement, or practice that emphasizes the collaboration and communication of both software developers and other IT professionals while automating the process of software delivery and infrastructure changes.” Ok – now even I am slightly confused? So DevOps is a movement?

Well to me a movement looks something like this:

mlk

or at least like this..

sanders

& not like this…

Credit: New Relicdev-ops

Well, what if its more of a culture? Hmmn, again, when I think culture, I think something like this:

Credit: Listversesamural

or this…

Credit: mausspacebeatles

 

& less this…

Credit: Sakthi Vadivelu

DevOps Culture.png

What about practice? Now are we on to something. “Meditation” is a practice, “martial arts” is a practice. Generally a practice is associated to something that you a) do consistently, and b) that enhances your well being in some way. Well to do DevOps right – a) you have do it consistently, and b) if you do DevOps right, it will enhance the well being of most development and IT organizations. So yes, DevOps is a practice, and like with most practices, it involves a “philosophy”, a “methodology”, and a “toolkit”, however unlike say “meditation”, “DevOps” is a team practice. What this means is that in addition to a philosophy, methodology, and toolkit, DevOps requires an “operating model” in which a team or a set of teams can effectively operate. Additionally, like with any other practice, the more you do it, the better you get at it.

So with this as a foundation, how would I define DevOps? I would say “DevOps is a practice with an associated philosophy, methodology, toolkit, and operating model, that enables the rapid deployment of software“. I have used some words very deliberately here, in particular the words “rapid”, “deployment”, and “software”.

Rapid vs. continuous: Continuous deployment or continuous delivery implies a level of instantaneousness that while it might be an ideal final state, is probably not a realistic near or even medium term state for most IT organizations adopting DevOps. Rapid is fast, but its not continuous, and its certainly not instantaneous.

Deployment vs. Delivery: Software can be delivered as quickly as it has been developed and tested, but that doesn’t necessarily imply that the software has been put into use. In the IT world, for software to be used, it has to be deployed.

Software vs. Infrastructure Changes: Infrastructure changes might or might not be software changes or software-driven changes. For the purposes of this definition I have excluded infrastructure changes that are purely hardware changes.

Additionally, note that I haven’t used the words “to minimize risk” or to “reduce time to market” in my definition of DevOps. The reason is simple, its because in my mind those are value statements of DevOps, and hence imply why we should care about DevOps, but do not constitute the definition of DevOps.

Hope this helps!

DevOps – its not Culture, and its not a Movement