by Evan Powell
Over the weekend I was chatting with a really successful venture investor who recently published a top trends list.
That made me think about DevOps vs. Cloud and vs. SaaS and vs. Mobile and other disruptors. I’m convinced more than ever than DevOps is the right focus for professional investors and for all of us investing our time in developing, adopting and operating IT. Examining and understanding DevOps is more useful than understanding cloud, SaaS, SDDC (software defined data centers) and more – and here’s a few reasons why.
1. DevOps is a common denominator
Keep peeling back the layers at the top operators and, underneath, you find the organizational structure and the set of tools that is DevOps. Some of these operators use containers, but some use bare metal, and some use virtualization – so there is quite a bit of variance there. Yes, there are other common patterns like developing applications that are stateless themselves and able to aggregate underlying resources – however DevOps in organization and in technology is a common denominator in a way that, for example, virtualization alone or technologies X, Y or Z are not.
June 11, 2014
by Patrick Hoolboom
I spend a lot of time talking about the positive effects of moving to a more DevOps oriented approach. The reasoning behind this because I truly believe it, and get excited just thinking about it. An interesting thing I have found is that, when explaining these concepts and what StackStorm is about to non-technical people, I almost always get the same question:
“If DevOps is so great, why isn’t everyone doing it?”
This is a perfectly valid question, so I thought I’d try to break it down into what I see as the biggest barriers to entry for a truly successful DevOps initiative. I thought back about the various places I have worked, or the reasons I have heard for not wanting to move away from the Operations/Development silo approach and was able to distill them down to 3 points (actually 4 but the last one seems to be wrapped up in the other three).
June 6, 2014
VSM: Thanks for taking the time to speak with us. Could you start off by giving our readers an introduction to StackStorm?
Evan Powell: Of course. StackStorm is a DevOps automation company, created by myself and Dmitri Zimine, with the goal of leading the third wave of operations automation. We created StackStorm because we want to deliver self-driving, self-learning operations automation to the mainstream enterprise […]
June 5, 2014
by Patrick Hoolboom
The last few weeks have been a flurry of customer meetings, infrastructure design, and recovering from the OpenStack summit. The summit was an incredible experience. Listening to the frustrations from so many people over systems deployment and administration tasks really validated many of my views of classical IT Operations. Seeing the infrastructure pain points of other organizations, combined with the design plans currently swirling around in my head, has me thinking more and more about the future of IT Operations. How will operations evolve to support the rapid infrastructure growth commonly experienced by organizations in this day and age while still maintaining as many nines (high availability) of uptime as possible?
I find myself in a very unique position here at StackStorm. Our company culture is evolving from a foundation of quality engineering, accountability, and flexibility. It enables us to build out infrastructure and processes in such a way that we can avoid many of the pitfalls that a typical operations organization would encounter. It is truly exciting, even freeing, to be able to think this way. We are not breaking down the silos encountered in a typical technical organization – we are actively avoiding them from the very beginning. The usual startup environment runs like this. Not only do you code, rack and stack servers, and do software releases, you literally take out the garbage and vacuum. The team works together to do what needs to be done without thinking “That isn’t my responsibility.” This open-minded mentality is born out of necessity. Naturally, as companies grow, groups become more specialized and lines are drawn in the sand. Some of this is needed. You want your engineers to be able to focus on technical tasks but many times this turns parts of the organization into black boxes, and tends to create bottlenecks in various processes. At best this leads to frustrations or confusion, at worst the processes get completely circumvented.
June 2, 2014
by Evan Powell
Over the years I’ve helped literally thousands of customers gain efficiencies in their data centers. I’ve met and become friendly with a lot of IT pros but I’ve got to admit – I never envied them. Well, maybe I envied some of the views in NY and Jersey City. And some of the toys they got to play with over the years were amazing.
Nonetheless, I didn’t envy them because many of my friends in director and VP roles spent a huge percentage of their time fighting politics that resulted in Orwellian distortions of the truth. A couple of stories from the early 2000s might help illustrate my point:
1. Two guys pulling all-nighters delivering a $1.5B roll out of IP communications while 25+ project managers debate progress from 9-5
The headline pretty much captures it. This now too-big-to-fail bank, as well as their vendor, had brought in several project and program managers to ensure groups from facilities through supply chain through security and operations were “aligned.” I spent a couple of meetings getting to know all of these project managers before realizing that there were two guys working every night, all night, to manually, using fingers and spreadsheets, push and validate changes. Eventually those operators quit – and the project ground to a halt.
May 28, 2014
by Evan Powell
While I am a third time founding CEO who has helped build some successful infrastructure software companies, I’m continuously learning. I don’t have a particular formula for how to build the right combination of market positioning, company capabilities, company tactics, strategies, and more.
In leading companies I rely on my own broad experience, common frameworks from Michael Porter and others, and surrounding myself with people smarter than me who are unafraid to show it.
I believe each company takes on a certain personality – a sense of the company that can be felt. This is where design thinking perhaps comes to play.
For example, whereas Nexenta was generally a scrappy company that needed to break the rules to shake the status quo, StackStorm’s personality is more that of a relatively polished upstart that expects to be the best at everything it does.
May 15, 2014
If DevOps is a verb and DevOps is a change in culture, does it make sense for anybody to call themselves a DevOps startup?
Sort of. Especially if they’ve done it before […]
May 13, 2014
by Evan Powell
Yesterday, the first day of the OpenStack Summit in Atlanta, was a great day for StackStorm and for the community. It was a pretty special day for me personally too.
First – the community. I appeared on theCube in which John Furrier and Stuart Miniman asked me to share some thoughts on the OpenStack community. I admit – I’ve run the tape back. On the whole I hope I hit the right balance.
Here’s my gripes:
Well, that felt pretty good. Here is what I love about OpenStack (the quick version):
May 12, 2014
by Patrick Hoolboom
I’ve read a number of articles discussing DevOps from just about every angle. The topics range from What Is A DevOps Engineer to There Is No Such Thing As A “DevOps Team”. The latter was written by Jez Humble who is an expert in Continuous Delivery (his book on the subject is amazing; I definitely recommend reading it). I am not going to try and dissect his statements or rebuke his article, as I agree with him. I’d like to give my spin on what DevOps is today and how it applies to the Development/Operations relationship in organizations of all sizes.
This blog is mostly focused on the benefits of DevOps as seen from the standpoint of the Operations Engineer. (There are a number of higher level, externally facing benefits to adopting DevOps – in the future I will dig deeper into DevOps benefits, and how that impacts the non-technical areas of the business.)
Man or Methodology?
Does DevOps refer to a specific role within the organization?
Are engineers trained to be comfortable working at all levels of the stack?
Or, is DevOps an umbrella term to refer to methodologies as they are applied across the organization?
May 10, 2014
by Evan Powell
I think a lot about positive feedback cycles these days. DevOps wins in part because by decreasing the cycle time of development and operations of new capabilities the software gets closer and closer to real user needs. This of course brings more users, which presumably brings more resources, which enables even more projects to further accelerate the delivery of new capabilities. And so on.
That’s the theory and the reality in many shops. However, in too many shops the automation that is core to DevOps quickly becomes technical debt. Unlike components like NoSql data bases or even underlying configuration management, there are not yet projects that have critical mass and hence have the credibility to gain more users and so forth.