— ROELBOB
I first heard the term DevOps from a friend in the software business when I was working at Dell HQ in Round Rock, TX. He recommended that I read The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford. I did read it and I found it a fascinating story, but as a long-time network administrator (to oversimplify as much as possible) and having never been involved in developing software, I wasn’t quite sure how it applied to me. It was enough to pique my interest though and drove me to volunteer at a DevOpsDays event in Austin. Within weeks I left Dell and joined a small software company, where I could have a better chance of getting my arms around this slippery pig called DevOps and more hands-on practice with the related tools and techniques.
So imagine my surprise when a year later, the same old friend who introduced me to DevOps suggested that the end-goal of a DevOps transformation should be that we stop talking about DevOps. Uh-oh, I thought, he’s lost the plot. But he made his case by pointing out that adding testers to dev teams–a typical step in any Agile transformation–doesn’t result in new devtest or agiledev teams, they remain simply “dev teams”. Once a business/group has fully internalized the Agile or DevOps values and behaviors, he argued, ‘working in an Agile or DevOps way’ becomes simply ‘working’. This is why many DevOps promoters, myself included, have a negative reaction to seeing ‘DevOps’ in job titles, job descriptions, or department names. While it simplifies the job of identifying which job candidates have a DevOps mindset or skillset, it effectively excuses everyone else in the organization from taking responsibility for change. “Doing DevOps” becomes the job of a particular individual, team or department instead of a philosophy internalized by the organization.
Of course the horse is already out of the barn on that one. Each year we see an increase in the number of businesses advertising for DevOps Engineers, forming DevOps departments or listing DevOps among the required skills for a position. It doesn’t matter whether we think this is a good thing or bad thing, evolution will take its course and there’s little we can do to stop it. What we can do is observe, acknowledge and adapt. Sure, the dangers are real. A DevOps department can easily become just a third silo or the DevOps Engineer might become the scapegoat for everything that goes wrong between development and operations. But if a DevOps Engineer, VP of DevOps or DevOps department can form, contribute to and/or nurture an environment of increased empathy, faster feedback and continual growth, that’s awesome; put the focus there. Don’t spin your wheels arguing that they just “don’t get it” or “they’re doing it wrong”.
I’ve spent the past couple years researching, promoting and attempting to practice this thing we call DevOps. While it’s widely believed that DevOps is impossible to define, I am firmly in the camp of those who believe that empathy is, to quote Jeff Sussna, “the essence of DevOps”. Just as the sales team needs to have empathy for its customers, everyone in the value chain needs to have empathy for each other. I’m aware that many people find this term too “touchy-feely”, but the business benefit of more harmonious interaction between one’s teams and between the organization and its customers is clear. The faster and more effective one is at converting solutions into real value for customers, the more successful one will be in the market. Thus being empathetic isn’t just being a good citizen, it’s being a good businessperson.
Taking it a step further, someone on Twitter recently suggested that “DevOps has nothing to do with technology”. The statement seemed ridiculous on its face. After all, the term ‘DevOps’– literally a portmanteau formed from the words ‘developers’ and ‘operations’–was coined by Patrick Dubois, a technologist intent on improving the process of building and deploying software. But as I thought about it I started to understand. As the DevOps movement has evolved, the most fundamental components its promoters have identified, from Gene Kim’s “Three Ways” (Systems Thinking, Amplify Feedback Loops, Culture of Continual Experimentation and Learning), to John Willis and Damon Edwards’ CAMS (Culture, Automation, Measurement, Sharing), to Dave Zweiback’s ICE (Inclusivity, Complex Systems, Empathy), are primarily about how people work. It doesn’t matter if one is building software or running a school, DevOps principles are sound.
I recently tweeted the observation that “anyone who attempts to define DevOps in a paragraph is trying to sell you something”, adding “not necessarily a bad thing, just buyer beware”. This wasn’t a criticism of tool providers; many tools, from build automation to log monitoring, are essential to an effective DevOps transformation. It was a reminder that the problems and solutions DevOps is concerned with are complex and nuanced. There is no prescribed toolset or checklist of actions one can take to be successful; an effective DevOps transformation requires thoughtful, committed action across the whole range of people, practices and products one uses in their work. It might take months or years of practice, but maybe one day we can all stop talking about DevOps.
Given the dizzying amount of best-of-breed tools that can be involved in the development pipeline, a well-written microservice comes to the rescue with just enough code to keep things running. But too much of anything is never good. Here’s how and when to use microservices.
Microservices are all the rage right now: these mini-apps are being used to integrate distributed applications that can be modified more easily. Microservices act like the glue, holding together processes and systems in the DevOps automation workflows. This means faster, more automated cycles, better implementation of continuous delivery and increased visibility into DevOps processes and deployments.
For developers and testers, who generally love the best-of-breed approach of using whatever tool they prefer for the job, microservices allow them to do that by affordably connecting many different open-source and commercial tools in the DevOps pipeline. While some of these tools have built-in integrations to other popular tools, those integrations may not be exactly customized for your needs. Asking the vendor to build custom integrations for you can be cost prohibitive and may not be feasible within the time frame your organization is looking to implement.
So with microservices, development teams have the flexibility to build their own tool stack and integrate everything to achieve full visibility into the development process. Equally helpful, REST APIs are super easy to work with compared with legacy APIs; developers can handle writing microservices without specialized expertise in the products that are being integrated. These are just a few of the extremely powerful advantages of the microservices approach.
Yet as with every other cool technology, there are a few hitches, as follows:
So, now what? It’s possible to make all this a bit easier. First, make sure that you’ve got the economics straight. Will developing microservices as your integration strategy be cheaper (factoring in staff time) than having vendors do it for you? If cost is not the main consideration, do the benefits of having a custom-built DevOps tool stack outweigh the complexity issues including downtime risks when a service breaks? Is there a clear-cut benefit from having a custom integration over taking the vendor’s not-quite-perfect integration? Do the analysis before choosing the microservices path – and remember to tie all this back to business benefits.
Here are some ways to reduce the complexity of microservices:
Go hybrid: In most cases, organizations will find that using a combination of vendor integrations and microservices is often the answer.
Outsource: For business-critical applications, it’s not a bad idea to let an outside development firm handle the microservices portion for you. That will reduce your risk and free up your developers to focus on building products not managing integrations.
Tools and languages: Choose languages for writing microservices that work well with REST APIs, such as Python and Ruby. As well, keep an eye out for tools that can help when you’re doing this in-house, such as Zapier or TaskTop. We expect those automated options to only grow, as companies expand their use of microservices and containers to optimize their DevOps operations.
About the Author/Kevin Dunne
Kevin Dunne is the vice president of strategy and business development at QASymphony. He has a deep interest in the emerging trends in software development and testing. Kevin joined QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. He can be found online at LinkedIn and Twitter.
— ROELBOB
— ROELBOB
I know we have mentioned it before but we haven’t officially announced our DevOps Connect: cdSummit SoCal event on December 3rd in Los Angeles. The event co-produced with CloudBees, the enterprise Jenkins company, IBM and devopsy.kinsta.cloud will take place from 9am to 6pm at:
The Olympic Collection Banquet & Conference Center
11301 W. Olympic Blvd., #204
Los Angeles, CA 90064
We have a great line up of speakers and sessions for this event and I wanted to share 4 of them with you today:
1st Keynote/Headliner: John Willis, evangelist at Docker – That’s right, the one and only @botchagalupe will be kicking things off. If you have been lucky enough to catch John present before you know that he never disappoints. Partly because his experience and knowledge give him superior insight into the issues and problems that IT teams face today, but also because he is so passionate about what he presents on. John will be presenting:
Kata
Mike Rother in his book Toyota Kata implied there was an invisible side to why Toyota was so successful over the years. As we we have explored the transitions from Lean to Agile and now to Devops we often fight the visible versus the invisible in accomplishing our goals. This presentation will take a look at what Kata meant at Toyota, Alcola over the years and bring it full forward with companies line Netflix and Etsy.
2nd Keynote: Andy Pemberton, Sr. Director, Solution Architecture at CloudBees. I have seen Andy present several times now and he does a great job of showing how the technology we are using everyday in our lives is being pushed, pulled, stretched and shaped by DevOps, Continuous Delivery and Agile. Andy will be presenting:
Orchestrating the Continuous Delivery Process
Continuous delivery is an end-to-end process and orchestration is the engine that drives continuous delivery. Automating the continuous delivery pipeline starts with understanding the process and of the entire toolchain. It sounds daunting, but it can be approached in stages to keep up with the demands for application delivery speed.
Boyd Hemphill, Director of Evangelism, StackEngine. Boyd is one of the great Austin DevOps folks. He runs the Austin DevOps Meet up Group, helps with Austin DevOps Days, Container Days and so much more. Like John Willis and Andy Pemberton, I have seen Boyd present a few times and he also just really brings a great talk. Boyd presented on “HomeOps, lessons he learned about DevOps while doing work at home. It is funny, insightful and a really great presentation.
HomeOps – Learning DevOps At Home
DevOps is great. You can see the benefits. All the success stories have you champing at the bit to become your very own Unicorn. Oh, but you are smarter than that. You know that every one of those success stories comes with many, often hidden, trials and tribulations.
HomeOps is the way I have become familiar with many of DevOps models such continuous delivery, lean thinking and cultural impact. Bringing these models to work with the ability to anticipate problems helped me save nearly $1.0m in costs while opening $1.8m in revenue.
Come gain some of the missing insight to your continuous delivery journey.
Bob Reselman – Publisher and Managing Writer: The World in Which We Live. Bob is half of the ROELBOB team that has been creating some of the funny cartoons here on devopsy.kinsta.cloud. Bob also has many, many (did I say many?) years of tech experience under his belt which gives him the perspective he needs in his role at The World in Which We Live. Bob will be presenting:
Making a Linux Container: My pain and agony in grueling detail
Allow me to share an intimacy: I an experienced technology writer. Also, I am a container newbie. But, I understand that containers are an important step forward in computer virtualization. Knowing the stuff is a whole lot better than not knowing it.
So I took the plunge and decided to get down and dirty by building a containerized microservice.
I do have a method. I am a learn by doing guy. First I get the concepts down, then I get hands-on and write about it as I go. I assumed there must be a lot of Hello World type stuff out there to get me up to speed with the basics. Then, I could take things a bit further and build my microservice container on what I learned in the Hello Worlds.
I mean, it can’t be that hard, right?
Wrong!
It turns out that making my first container was a journey into pain and agony. No human should have to go through such an ordeal. So I am going to share my story with you in grueling detail so that you don’t have to experience such torture… ever.
We have another 5 or 6 sessions/speakers that we are finalizing right now and will announce next week. However, there are still one or two slots open and if you are interested in presenting you can write me at editor@devops.com with contact info and we will contact you.
Besides the great sessions and speakers, we will be featuring demos of Jenkins, CloudBees, IBM BlueMix and more. Also lunch, refreshments and more will be served. There is plenty of free time built in for networking as well including caricatures by the ROELBOB team and more surprises in store. We will also be announcing additional sponsors in the coming days.
So if you are in the Southern California area and into DevOps, CD, Jenkins, BlueMix or want to learn more, this is a can’t miss event. You can get more info here. You can register for the event (there is a $99 charge for the day) on Eventbrite.
We hope to see you in Southern California on December 3rd.
At a recent Lean project report out to stakeholders, a piece of analysis was presented which showed the quantity of metrics being captured, in various areas, at different organizational levels. IBM’s Watson had been used to generate the chart, and it told an interesting story. But that story needed some translating.
‘Look at all those metrics under ‘Managers”, said one Director, with enthusiasm. ‘Seems like they’re looking at a lot of different performance measures for their people’.
‘Yes,’ said the Lean Coach, ‘but is that a good thing in itself?’
Another Director chimed in, ‘Well, when I look at how few metrics are being captured on timeliness I wonder how anyone knows how they’re doing.’
As an IBMer, and Six Sigma Blackbelt, I’m pre-disposed towards data. Information can be power. But with too much being reported, it can be hard to see the wood from the trees. Performance metrics are intended to allow teams and leaders to improve their performance. For many of those people, reading charts and interpreting data may not be a core skill and it certainly isn’t how the organization wants them to spend their time. So those teams generating masses of performance metrics may not be doing themselves, or their leadership, a service.
The key is to identify the critical few metrics. Ideally leading indicators of performance issues, rather than lagging ones. Leaving aside areas like SLA adherence and budget management to those responsible for governing them, these are the handful of metrics I would suggest a DevOps team needs to watch on a daily basis:
What do you think? What do you measure?
