Enterprise IT

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

CLOUD COMPUTING – ENABLING INNOVATION

mali79, , Leave a comment
In my first post I spoke about why cloud computing represents the “Fourth Act” of enterprise computing – with mainframe, PC, and client-server representing acts 1, 2, and 3 respectively. So what characterizes the cloud computing era? In one of the better posts on the subject, Ben Kepes, one of the worlds foremost enterprise IT thought leaders, characterizes “cloud computing” based on guidelines provided by the National Institute of Standards and Technology (NIST), with the following key characteristics:
  • On-demand service: ideally allowing users to self-provision
  • Broad network access: access via standard platforms viz. web, mobile etc.
  • Resource pooling: resources pooled across multiple customers/end users
  • Rapid elasticity: ability to scale to meet demand peaks
  • Measured service: utility like billing
He then goes on to describe the cloud computing stack including Software as a Service (SaaS), Platform as a Service (PaaS), and IaaS (Infrastructure as a Service), and the characteristics of each of these layers of the cloud stack.

 

While this approach to characterizing cloud computing makes perfect sense, in order to understand why cloud computing represents this “Fourth Act” of enterprise computing, we have to consider not just what characterizes cloud computing from a technology perspective, but also understand it’s impact on how enterprise IT is governed, and ultimately the business value that the cloud drives.

Below is my perspective on what characterizes each era of enterprise computing from a technological perspective:

Technology Characteristics v04 MA 2Jun2016

 

 A few points to key in mind when viewing the table above:
  • While each era of enterprise computing has a primary enabling technology, there are other parts of the technology ecosystem that are quite important. In the case of cloud computing ubiquitous broadband access is one such key enabler. That said, even without ubiquitous broadband access the cloud can exist, but without the adoption curve that we have seen. Without virtualization though, there is no cloud computing.
  • People have often compared cloud computing with the mainframe era, and while cloud computing is in some important ways a modern adoption of the computing concepts pioneered in the mainframe era, in particular resource pooling and remote execution of compute workloads, there are some significant differences. In particular in terms of it’s ability to scale, both from a capacity and time perspective, cloud computing is far removed from it’s early mainframe predecessors.
  • From my perspective what’s game changing about cloud computing, particularly in relation to traditional client-server computing, is this ability to self-provision, to be billed only for utilization, and to scale almost instantaneously. However as things currently stand in large complex organizations the ability to self-provision and instantaneously scale is usually theoretical. Most large organizations have systems and processes in place that cannot stop from coming in their own way, and significantly slow down these important benefits of cloud computing.
All this being said where cloud is truly very different from previous eras in computing, is in relation to the impact that cloud drives on governance models and business itself. Below is a table that outlines key differences:

 

Governance & Business Value v06 MA 3Jun2016

 

As mentioned above, it’s the ability to self provision, to scale almost instantaneously, and to be charged based on utilization, that’s most game changing about cloud computing. It provides the coming to fruition of the concept of utility computing, that unsurprisingly also has its root’s in the mainframe era. Have an idea for a new app that the company wants to prototype? Spawn a new EC2 instance, set up your code libraries, and you are off to the races. Your app needs to be able to scale on demand? Execute your application using AWS Lambda and let it auto-scale.

 

From a governance perspective this changes almost everything. In particular moving compute workloads to the public cloud impacts who supports the workloads, how workloads are provisioned, and more broadly how IT change is managed. What was previously in the domain of infrastructure architects, system administrators, and build teams is now largely in the domain of SaaS, PaaS, or IaaS  providers, or even cloud MSP’s. It doesn’t mean all of these roles, or all of these areas of enterprise IT competency become irrelevant, but it does mean the that the nature of these roles will evolve and where these skills are needed will shift (from enterprises to service providers).

 

All of this aside, the greatest impact of cloud computing though is on business itself. Even up to about 12 years ago, when Facebook had just launched, it needed a capital investment of approximately $20,000 on infrastructure to get started. Today that cost would probably be in the range of $200 on the cloud – a 100x decrease! For this reason among a few others, startups today are challenging established players in nearly every industry – from transportation to financial services to hospitality. In addition to the dramatic up front costs savings, startups are additionally taking full advantage of the agility (near instantaneous provisioning and auto-scaling) provided by the cloud, to fail fast, rapidly iterate, and go to market.

 

Established enterprises realize all of this, but are often bogged down by their own systems and processes, which were developed and optimized in the client-server era. In the client-server era the primary function of the CIO, and more broadly IT, was to keep the lights running. This was because information technology was largely thought of as an OpEx optimization play. That view is now turning on its head as increasingly businesses ranging from GE to Ford to Coca-Cola are realizing that information technology is no longer simply a way to optimize cost, but central to their product and growth strategies. In this new world, incumbents will be required to fail as fast, iterate as rapidly, and launch as quickly as startups are able to do. In order to do this though, enterprises will have to take advantage of the cloud computing paradigm in its truest sense and to its fullest extent.
CLOUD COMPUTING – ENABLING INNOVATION

Enterprise Computing – The Fourth Act

mali79, , 1 Comment

Hello and welcome to the very first post of the The Fourth Act. In this post I will answer four questions:

  • What is The Fourth Act of enterprise computing
  • Who am I and what is my experience in enterprise computing
  • Why am I starting this blog
  • What will the fourth act blog cover

Lets gets started…

What is The Fourth Act of enterprise computing?

The Fourth Act of enterprise computing is the cloud. Note by cloud here, I don’t mean just the popular definition of the cloud, i.e. the public cloud accessed over the Internet. I use the word cloud more liberally than that and include in it, in addition to the public cloud, both the hybrid and the private cloud, and more widely the use of commodity hardware to build very large server farms for computing – where this farm resides – on-prem, off-prem, or a on a bit of both, is of secondary importance.

The Fourth Act v03 MA 31Dec2015

Why is it of secondary importance? Because really what defines an era in computing, as depicted in the image above, is not so much where the computing power resides, but how this computing power can scale. This ability is to scale is contingent on the core technology driving each  act, and the core technology driving cloud computing today, is largely commodity hardware.

The ability, or inability, to scale also drives everything else in enterprise IT – any by everything else I literally mean everything else – including the applications that an enterprise deploys, how these applications are commissioned and built , an enterprise’s information security and network infrastructure needs, end-user computing needs, and IT operating models, budgets and governance.

 Who am I and what is my experience in enterprise computing?

My experience in enterprise computing dates back to 1998 and initially covered end-user computing, and enterprise networks. In the year 2000, I got my first taste of enterprise information security and risk consulting by way of an internship at now-defunct Arthur Andersen. In 2001, I began my career in enterprise technology consulting in earnest by way of Accenture. At Accenture I was exposed to clients in a wide array of industry verticals including resources, healthcare, and public sector. At Accenture I initially worked for the Global Architecture and Core Technology practice, focusing primarily of enterprise networks, data center, and contact center technologies, and later for the IT Strategy and Transformation practice, where I focused primarily on CRM and IT  Strategy. In 2010 I left Accenture to pursue my career as an independent consultant and entrepreneur, and have since worked with some of the worlds largest brands, technology companies, and public sector entities.

Some career highlights up to this point include:

  • Conceptualizing the infrastructure design and managing the infrastructure roll out, required to support one of the largest ERP implementations in the world
  • Building the core technology that supports that largest citizen-service contact center implementation in the world (NYC 3-1-1)
  • Developing the go-to-market and proof-of-concept strategy for collaboration and unified communications (UC), for one of the worlds largest UC and Contact Center companies
  • Designing a key component of the information security strategy of a global top-3 brand
  • Creating the omni-channel customer support strategy and roadmap for one of the world’s largest technology companies

Why am I starting this blog?

I am writing this blog because I have found a dearth of high quality enterprise focused technology blogs. Most blogs I have read are either by experts in certain niche areas of enterprise technology (some are quite good for practitioners of that niche), or by journalists that have been covering enterprise technology (mostly well intended, but lacking a practitioners insight) for a while. With this blog I plan on keeping a balance between a practitioners expectations of an enterprise technology blog, with that of those that might be a little bit on the outside, but looking to better understand the wider enterprise technology landscape. I by no means claim to be an expert in every aspect of enterprise technology, but I do have a very wide breath of experience, and will pull in the appropriate experts as needed to help supplement the blog. Hopefully this will help increase both my audience’s, and my own knowledge of all things enterprise.

What will the fourth act blog cover?

While cloud computing is the general paradigm that drives this blog, the intent is for the blog to cover all areas impacted by the paradigm shift from client-server computing to cloud computing in the enterprise. To that attend this blog will focus on:

  • An in-depth look at each aspect of the enterprise IT stack, across people, process, technology, and governance, and how it is impacted by the fourth act (cloud computing)
  • Interviews with enterprise IT leaders that are leading the charge to the cloud
  • Case studies highlighting the challenges, strategies, and innovation happening in the cloud
  • Occasional looks into what lies ahead

Hope this gives you some good perspective on The Fourth Act, and look forward to sharing great content with you in 2016 and beyond!

Enterprise Computing – The Fourth Act