Skip to main content

Posts

Showing posts from 2017

What's in a Name?

Over the years, I've written on the topic of application release on several occasions ( here and here , for example).  The topic itself is generally straightforward in that automating your application release process provides several benefits: Increased reliability insofar that the deployment process is being managed by software, meaning that "friendly fire incidents" are less likely to occur Increased release velocity as the time to deploy the application in a single environment is reduced, sometimes substantially Increased release cadence as more frequent releases are now possible given the previous two points Is ARA always about applications? Not only this, but automating your CICD pipeline is a key enabler for DevOps, as it is one of the five tenets of that school of thought.  (The others, if you aren't aware, are cultural change; efficient processes that are void of wasteful, time and resource consuming steps; measurement of the effectiveness of you

Only the Finished Product Matters

For many years, people have lamented the ever increasing use of automation in the workplace.  In the 80's it was on the assembly line, and people complained that the impact on the blue collar labor force would have a detrimental and even a material impact on the economy.  Since the late 90's, this discussion has shifted to the white collar labor force, especially as it relates to IT Automation, and the resulting amount of noise has increased exponentially in the last 10 years. "The robots are coming!" What, specifically, is the complaint? "Replacing people with robots" (as we've often heard it characterized) eliminates the need for the people in the first place.  They lose their jobs, which is bad for both moral and economic reasons.  Often, FUD (Fear, Uncertainty and Doubt) is incorporated into the message along with "#skynet" as people say that we will only be one step away from computers taking over the world and eliminating humankind

Where Were You When...

Where were you when ...Hank Aaron hit his 715th home run? ...Steve Jobs introduced the first iPhone? ...Felix Baumgartner jumped from 39km in space and parachuted to Earth while televising it? Mmm...soda! My wife and I have had this long-standing debate about whether drinks with Aspartame should be consumed.  She says no, but I say yes because I don't want the added sugar since I'm overweight as it is.  (Nevermind the options of not consuming the drink in the first place because then I'd drink beer instead and that's no better for my waistline.)  So once while consuming one of my favorite beverages - San Pellegrino Limonata - I read the list of ingredients to see which type of sweetener was present.  It was sugar.  I lost. "Remember when there was this huge backlash about High Fructose Corn Syrup?" I asked her, in hopes of avoiding discussing the fact that I was drinking something with sugar in it.  At that point, we both acknowledged that during

Use the Right Tool for the Job

Image copyright (c) by James Aiken My wife and I have a fun dynamic: she approaches situations with surgical precision, while I tend to be more of an imprecise paintbrush like you would imagine was used in the painting you see here. One day, she chastised me one day for cutting something with a butter knife and insisted that I should be using a paring knife instead.  I argued that it wasn't needed. Who was right? As you can imagine, I was intentionally vague with the description of the situation above so that I could illustrate that an understanding of the context is required to answer it properly.  In this particular situation, I already had the knife out from making my daughter a sandwich for her lunchbox and had switched to cutting strawberries.  So, technically, she was correct, but I was also able to properly execute my task with the tool at hand, literally. This loosey-goosey approach to executing a process works in some situations, but in others it should be avoide

Application Development Done Right

In a previous article, entitled DevOps as the Ultimate Panacea? , I described how developing code without thinking about the current needs of the end user as well as the future needs once they've become accustomed to using your application ends up not only frustrating them but also can result in customer churn and ultimately lower revenues.  In this article, I'd like to describe something simple that I came across today that shows a definite degree of effort to do quite the opposite. Recently, we had a severe snowstorm, one with blizzard-like conditions, which is unheard of in central New Jersey.  Being responsible adults, my wife and I went to the grocery store to stock up on essentials (read:  chips, chocolate, etc.) in case we get stuck at home. As we were ringing up our order, the cashier mentioned to us that the store has a mobile application.  Since both of us are in technology oriented professions, we were skeptical about the need for a grocery store mobile applica

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While that

DevOps as the Ultimate Panacea?

Truth without love is cruel, and love without truth is foolish. - Sam Leung Those of you who follow me on Twitter (@foolomon) know that I tweet industry news relating to DevOps and other topics (such as Information Security, IoT, etc.).  Based on the sheer number of articles that I come across but do not tweet about, you would be justified in believing that DevOps is still the darling child when it comes to marrying application-based functionality with the business value it should be aligned with. "What if I told you," Morpheus might ask, "that DevOps is not the panacea you think it is?" "What, what?" you exclaim.  "I thought DevOps is the be-all, end-all of application development!  'Continuous delivery' is the way to go, man!"  Bear with me while I explain myself. Recently, I read an article in Forbes that said something quite profound: "people don’t want to buy a quarter-inch drill bit; they want a quarter-inch hole.&quo