Agile, DevOps, Continuous Delivery – Don’t Limit Your Ability Because of Your Vocabulary…
Join the DZone community and get the full member experience.Join For Free
It seems to me that in the last few years there has been a pretty
significant change in the thought patterns around how you run Web
Operations. I don’t think the ideas are all necessarily new, but there’s
much more publicity and examples around how you scale Web Operations
from a variety of perspectives. This includes system architecture,
planning process, automation, fault analysis, etc. There is a new
vocabulary being formed and some of these ideas are well defined, and
- Continuous Flow/Delivery/Engineering/Drinking whatever…
- Agile Operations/Engineering/Development…
There’s one thing missing from this that I haven’t heard a cool phrase for: Understand the vital signs of your application. What features do your users use? What features do they not use? Which reports suck the life out of your app for 10 minutes? Which SQL queries are fast, which ones aren’t? What is the impact of that release you pushed out last week? I’m not going to give this a catchy & inaccurate name – but it’s a capability that’s important.
A few companies have been doing some of these things for a long time – but something is different now and I’ll get to that below.
If I look at the above list – I see some more specific capabilities that fall into one or more of those categories:
- Automated deployment & configuration management
- Branching in code with feature flags / config flags
- Monitoring & Reporting to understand how changes to the system impact performance, user experience, and user behavior.
- Using a project management method that allows for short iterations & low-cost pivots.
- Communication between teams & collaboration to share and leverage the abilities of everyone.
- Delivering frequent improvements with minimal effort
- Taking a retrospective look at what works and what doesn’t and using that to inform future changes
- Making everyone feel like they are contributing to the end product.
I’m sure some of you can think of other things you would list there too – and I’m sure not all of those things would fit into “DevOps” or one of the other examples above.
These ideas are not yet fully mature – they are changing and lots of people are experimenting. There are some taking lessons from other industries & trying to weave the massive amounts of research that have been done for things like aviation, utility facilities & military into Web Operations. There are a lot of similarities in the types of scenarios that arise and how you can make your response better.
What I think is really fantastic about this trend is that there is a LOT more information available about how to make your life in Operations better. Much of this information is also targeted at making the relationship between Operations and Engineering better. Operations and Engineering both become facilitators & implementers of capabilities which advance the whole system.
What I think is bad though, is people trying to fit today’s understanding of what works into a word, which is defined into perpetuity. There are a million ways to skin this cat and ones that work for one organization will not work for others. To me, this means it’s up to each organization to not only understand what is appropriate for themselves and selectively choose what they use, but also to share what works for them so that future organizations can leverage that.
The real win in all of this is collaboration. Collaboration between departments, between companies, and across the world of Web Operations experts and novices. New ideas will arrive daily and new perspectives will put old ideas in a new light. It’s being open and sharing that allows things to evolve rapidly. So stop worrying about what you call it – just do it.
Published at DZone with permission of Aaron Nichols, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.