devopsy.kinsta.cloud

Category: Blogs

Eight critical DevOps practices: innovate, deliver, repeat
DevOps has been garnering a lot of interest for some time. Discussions and debates on forums like devopsy.kinsta.cloud are improving our collective understanding of the right approach and now we are seeing concrete proof points of fast-movers applying DevOps practices to disrupt entire industries with rapid-fire, digital-innovation based on Cloud, Big Data and Mobile technologies. I have personally been part of this transformation at IBM for several years and would like to reflect on what we have learned, and also share with you results of a recent study from Forrester Research.

DevOps helps organizations address a critical business challenge – that of continuously capturing and responding to feedback (both internal and external) so we can rapidly and repeatedly turn innovative ideas into highly relevant, and desirable, products and services. This involves not only development and operations, but all aspects of the organization, as it entails the collaboration across the entire organization including business and supply chain. Compared to single-direction, traditional models, DevOps is bi-directional and is based on not just pushing something out to the customer but also on getting their feedback to make improvements.

In a recent webcast, I discussed eight DevOps practices that speed up software delivery with Kurt Bittner, Principal Analyst at Forrester and a leading expert on agile and iterative software development. This webcast highlighted a recent Forrester survey on DevOps practices, cycle times and where enterprises are in terms of the maturity of DevOps practices adoption.
You can watch the webcast replay here to know more – ibm.biz/Forrester-talk

Their survey of 600 IT professionals with application development responsibilities found that about a third of teams consistently deliver at cadences of one to three weeks and that the fastest teams generated higher business satisfaction than slower teams, an indication they don’t sacrifice quality to deliver fast. The study reveals how these teams did it: by adopting the following eight DevOps practices:
1. Minimum Viable Product – Deliver the smallest viable product or application and then improve it in subsequent rapid releases, based on feedback, and delivering value incrementally.
2. Dedicated Teams – Form dedicated, cross-functional teams, avoid over-specialization and ensure they are not interrupted by side projects.
3. Loosely Coupled Architecture – Use loose architectural coupling within and between applications to reduce complexity and enable delivery in small increments.
4. Minimize Hand-offs, Maximize Flow – Eliminate unnecessary steps, delays and friction between steps to increase the flow of work.
5. Deliver in Small Batches – Deliver in smaller batches helps to expose the most uncertain issues first and enables feedback on the most valuable usage models earlier.
6. Transparency – Transparency into progress helps everybody to see where you are at any point in time and also visibility into risk without decreasing productivity.
7. Eliminate Overhead –Eliminate the overhead of periodic and manual status reports and status meetings which absorbs valuable time and distracts focus from delivering value.
8. Automate Testing using APIs – Shift away from heavy manual testing to improve delivery speed, quality, and testing accuracy, and dramatically reduce cost.
The study refutes the myth that releasing fast requires you to sacrifice quality and accept higher risk. Adopting these eight DevOps practices, especially automated testing and delivering in small batches, does exactly the opposite: small incremental releases are more thoroughly tested, more stable and lower risk.

The best part about DevOps adoption is the flexibility to choose which practices to adopt first, based on each organization’s priorities, and then to incrementally adopt the rest of the practices as needed to optimize the software delivery lifecycle and accelerate innovation.

To learn more about the survey and the eight DevOps practices, download the Forrester study along with the approach that you can follow to adopt these as per your organization’s current state of delivery cycles.

About the Author

Ashok Reddy is responsible for Product Management & Strategy, product Design/user experience and Business Development for Rational Software Division of IBM Software Group and for the IBM DevOps portfolio. He is based in Raleigh, NC, USA. Ashok’s role involves all aspects of global product delivery including setting product strategy and for product line management, establishing product roadmaps and partnerships for IBM DevOps portfolio.
October 22, 2014
The fashionable IT crowd

The IT Crowd

I was recently reading an article in Marie Claire UK (yes I do read non-nerdy publications, some higher AI should sentence my brain to enter a loop without an exit condition) which explained that women should start learning how to code in order to become successful professionally. That triggered my curiosity and I started to wonder when IT became classy enough to be mentioned in a fashion magazine. This might be the time for a little history.

Don’t blame Information Technology.

Once upon a time, well before the internet – yes kids, there was a time where people had to read books to access knowledge – IBM was ruling them all. It was such an important and powerful company that you could likely compare it to Google today. IBM salesmen were to wear suits, ties and an attaché case every day like other any other corporate person and techies had to wear a simple white shirt with an IBM logo on it. IT fashion at that time was pretty much neutral and IT was seen as any other field of work.

In the early eighties, Bill Gates who started to do business with IBM had a look that would, for some reason, stick with IT people for decades: oversized glasses, poorly shaped and tasteless beige tops with a pair of equally bad looking trousers.

Steve Jobs on the other hand when not representing his company officially was already seen wearing his now infamous denim and black turtleneck combo. The power of branding.

How come then that with so many different styles in circulation, one prevailed in people’s minds as the standard geek outfit? Well, in order to understand, we have to broaden our search a bit and we can then realize one thing: in the eighties, almost every person that had an interest in science had poor social skills and or almost no interest in fashion or styling. While this is a gross generalization a quick internet search for images of “nerd 80s style” should demonstrate what I mean.

Music has changed it all.

In 2001 Mp3 players had existed for years but were a niche market as their price was too high, their storage capacity too low (one album would fill up a player) and they required a computer and some technical knowledge. Downloading a song was also an obstacle as there was no massively spread peer to peer or legal solutions at that time.

Then came Apple with its iPod, almost like a piece of art that created curiosity and attraction and offered enough storage space for many albums at once. I think this was the first time the public saw an interest in a computer or mac related device. CDs while hugely popular were impractical – think of carrying more than one of them with you everywhere you go – huge and mostly unreliable for jogging or walking fast.

People who wanted an mp3 player and who did not own a computer had to get one and access to the internet. The internet which was mostly used by “people who knew” became more and more popular and people started to massively use emails and chats (msn, aim and all those brands which do not exist any longer) and slowly gained the knowledge to use internet in a more efficient way. This led internet providers to offer higher bandwidth and the development of a plethora of websites with ever more content.

With access to everything at all times, computers gained in popularity and the emergence of smartphones spread the use of internet even a bit further.

In the mid-2000s, technology, the people traditionally associated with it and their culture then became hip. That was the beginning of the “geek chic” trend, often confused nowadays with the hipster subculture. People started to wear old style clothes such as suspenders and those oversized horn-rimmed glasses. Not adapted to the business world, this trend quickly faded however with the public gaining awareness of things beyond glasses, thanks to popular TV shows such as The Big Bang Theory or Chuck, the geek culture spread widely.

Finally recommendable

All those factors contributed to IT becoming less and less a world of “freaks and geeks” and more and more a profession as acceptable and as open to everyone as any other, finally showing up as a recommendation for a professional path in a women’s magazine.

It was about time.

October 21, 2014
Microsoft partners with Docker to bring containers to Windows Server

Docker has taken the DevOps world by storm, and that has caught the attention of Microsoft. Now, Microsoft and Docker are teaming up to bring native support for the container technology to the next generation(s) of Windows Server.

Docker is an open platform that enables organizations to run any application as a Docker container. The Docker containers can be implemented across virtually any infrastructure—delivering tremendous agility and flexibility for managing virtual applications. The container concept accelerates software development timeframes, and allows organizations to reduce costs and improve efficiency at the same time. It’s easy to understand why Docker is so popular.

There have been more than 21 million downloads of the Docker platform, and there are over 45,000 “Dockerized” applications available on the Docker Hub Registry, and 13,000-plus Docker-related projects on GitHub. Just last month Docker took in $40 million in another round of investment.

Major names in tech, like Rackspace, Google, and IBM have already pledged their support for Docker. Now Microsoft wants to bring the hot technology to Windows.

Docker Engine for Windows Server will allow customers to create Docker container applications that can run locally on Windows Server, or on virtual Windows Server instances in the cloud on Azure. In a blog post announcing the Docker partnership, Ross Gardler of Microsoft Open Technologies explains, “As part of this announcement, MS Open Tech is contributing code to the Docker client that supports the provisioning of multi-container Docker applications on Azure. This code removes the need for our cross-platform CLI to bootstrap the Docker host. In other words, we have taken a simple process and made it even simpler.

“This development is interesting because Docker has been a really fast moving technology having come out of almost nowhere a year ago to where now it is an incredibly widely supported technology,” stated Al Hilwa, an IDC analyst. “It is a bit of engineering but Microsoft wisely decided that they did not want to leave Windows developers out of the Docker party. This is good for Microsoft because those 45K ‘Dockerized’ applications will be able to run on Windows.”

To be fair, Microsoft isn’t completely new to Docker. Earlier this year it added support for Docker in Azure, but only on Linux. This new partnership launches an open source project to develop a Docker Engine runtime for building, running, and managing Docker containers natively within Windows Server. Docker Engine for Windows Server will be managed as a Docker open source project, but Microsoft will be a major contributor to the community.

The Microsoft blog post describes why Docker’s container technology is so important for the fast-paved development of a DevOps environment. “Containers do not include a full operating system, consequently rapid development and scaling of container-based applications is possible through very quick boot and restart operations. Furthermore, highly efficient creation of modified container images, by virtue of only capturing the differences between the original and new containers, enables improved management and distribution of containerized applications; the resulting images are both small and highly portable across almost any platform.”

Hilwa summed up with some thoughts about the new strategic vision of Microsoft. “What is even more interesting is that the work on the Docker engine in Windows is being done in open source—really showcasing the new Microsoft attitude towards open source (e.g. the open sourcing of Roslyn a few months ago). I really think we are seeing a faster and more open Microsoft, one that is more willing to integrate and collaborate with competing technologies without a lot of hesitation.”

October 16, 2014
DevOps + IoT

The Internet of Things (IoT) is part marketing hype and partly a real movement. After low power WiFi chips have allowed small devices to connect to the web for a long time. Remember Eye-Fi founded in 2005?

But there is no denying it is BIG. Service revenues rooted in micro-controller-based IoT are expected to reach a whopping $7.3 trillion by the year 2017 according to a recent IDC report, with the radical new paradigm shift of DevOps leading to the perfect storm of IoT adoption.

IoT is set to be a disruption those building and connecting things. It forces a transformation that is largely driven by the integration of development, IT operations and quality assurance practices delivered for IoT under a single automated umbrella in the DevOps-oriented world.

(more…)

October 13, 2014
Enterprise DevOps: same medicine, different dose

I am presenting at the DevOps Summit in Santa Clara early next month. The title of my presentation is “Enterprise DevOps: Same medicine, different dose.” I will be attempting to tackle the sometimes sticky subject of whether Enterprise DevOps is a unique species or is there just DevOps for organizations big and small.

My personal feeling is DevOps is DevOps. That being said though, I don’t think anyone would argue that large enterprises are a different animal than smaller companies. The inertia in these organizations make culture change on a large scale harder, if not slower. Just as you would give a different dose of medicine to a child then you would to an adult, I think you have to inject DevOps differently into a larger organization than you would a smaller one.

That doesn’t necessarily mean that anyone selling enterprise DevOps services or tools is a snake oil salesmen though. I think understanding the differences between a large organization and smaller ones creates opportunities for vendors. I think that some in the community think that large vendors are just using the term enterprise DevOps to protect their existing turf from usurpers.

Anyway, I will be diving deeper into this subject at my presentation. I will post the abstract link shortly and will post me slides after the show.

In the meantime you can help me. I am interested in your thoughts on this subject and what you think is important for me to cover. I respect all opinions so if you don’t agree with me, feel free to say so, but if you do, say why.

Thanks!

October 11, 2014
The DevOps Culture Cocktail

As I have written in previous posts, I believe that IT has accumulated decades of cultural debt that is now due. We are a young industry that grew up in silo neighborhoods, each with it’s proprietary practices, language and population of like-skilled specialists. Left unchecked, the resulting “framework culture” contributed to IT’s cultural debt and is partially the motivation behind DevOps.

The goal of DevOps is not to undervalue or replace the frameworks that are in place. On it’s own, DevOps is not a framework – in fact, successful DevOps relies on combined effect of best practices such as Agile, Lean and ITSM. By recognizing and adapting the best of each, IT can formulate a potent recipe for enhancing performance and increasing customer satisfaction.

So let’s belly up to the bar and mix ourselves a DevOps Culture Cocktail by taking the best guidance from the top shelf of each of the frameworks and practices.

Ingredient 1: ‘Git R Done’ Scrum

Scrum is the most prominent of the Agile frameworks and with good reason: it focuses on getting work “done” in manageable increments while reducing work in progress.

Pair it with a Kanban Board

While deceptively simple, Kanban is a powerful method for visualizing workflow, identifying constraints and keeping a team focused.

Ingredient 2: Automation

There is a lot of debate around the balance of automation use in DevOps, but there is no dispute that automation and metrics play a key role in successful DevOps.

Ingredient 3: IT Service Management

ITSM is the deployment’s “ever after”. Agile and repeatable service management processes lead the way to stable continuous delivery and increased flow.

Ingredient 4: Lean

Let’s make it a skinny by creating more value for customers with fewer resources and less waste.

Ingredient 5: People

The most important ingredient. DevOps relies on the way people think, behave, interact and trust their colleagues. According to Lloyd Taylor, “You can’t directly change culture. But you can change behavior, and behavior becomes culture.”

Finally, add a splash of common vocabulary and a shot of the alcohol of your choice and you now have a DevOps Culture Cocktail! Serve it daily, share it with your neighbors or sip it while reading a good book like The Phoenix Project. It does get more potent with age.

I recently had the opportunity to present the DevOps Culture Cocktail Party at Fruition Partner’s FruDevCon Conference. One of the attendees, a hobby mixologist, formulated her vision for a signature DevOps Culture Cocktail during my presentation. We asked the hotel bartender to mix it up, passed it around and a new cocktail was born. Here goes:

The DevOps Culture Cocktail
1 part pear vodka
1 part St. Germain
1 part Chardonnay
2 parts simple syrup or 7 up

Top with a spear of pineapple and a cherry.

Improvement recommendations are of course welcome. Could this become a staple at all future DevOps events?

October 9, 2014
Share Your Thoughts about On-Call

We all know that being on-call sucks. What we don’t know is how other people are dealing with the problem.

It’s time to dig deep, ask the hard questions and collect data around what it’s really like to be doing the hard job of keeping the machines up & running. That’s why VictorOps needs you!

We’re conducting the first State of On-Call survey and would love to hear what you have to say about the topic. Whether you’re currently on-call or manage a team of on-call folks, we’d like to know what tools you’re using to make the process easier and what sort of pain points you’re still experiencing.

We’re thanking you in advance for your time & feedback. Additionally, your survey response gets you automatically entered into a drawing for a Nexus 7 tablet. Help us to better understand the problem so that we can help you make on-call suck less.

October 8, 2014
Consumer Web Automation for DevOps?

These days event-based automation is everywhere from IFTTT recipes used by non-technical folks to cross post automatically to Twitter, Google+ and Facebook to email alerts for free iTunes downloads. And don’t forget the tech savvy that create even more complex sequences from Zapier and now Stamplay to track workloads and simple business processes or automate developer tools.

But this automation is not limited to consumer uses—it can also be the answer to DevOps challenges. Simple DevOps processes implemented with services such as IFTTT and Zapier improve the workflow and boost work performance.

(more…)

October 8, 2014
Webinar: DevOps in the Modern Enterprise
We are happy to announce the next devopsy.kinsta.cloud webinar. In partnership with AppDynamics and Citrix :

DevOps in the Modern Enterprise

DevOps has been embraced by companies ranging from small e-commerce providers to large fortune 100 institutions. As the rate of adoption continues to grow there is still much confusion about how to successfully transition from “DevOps curious” to full fledged “DevOps practice”. Jim Hirschauer, Technology Evangelist with AppDynamics, will discuss the role of software tools in fostering a successful DevOps practice. Spencer Schwab, Staff DevOps Engineer with Citrix, will share his experience in transitioning his organization into a DevOps centric practice. Spencer will expose the challenges associated with shifting towards DevOps as well as the solutions he discovered while leading and participating in this experience with all of it’s ups and downs. You’ll learn how to initiate change within your organization as well as the associated pitfalls and benefits of the DevOps journey, all based upon the real word experience that Spencer brings from Citrix. One attendee will win a $100 Amazon gift card. You must be present to win

Date: October 30th

Time: 1pm eastern, 10am pacific
```
REGISTRATION LINK: (Limited registration, so don't wait!) 
```
About the Speakers:

Spencer Schwab – Currently, as an Operations Application Owner at Citrix, Spencer leads a Dev/Ops team that is responsible for the availability, run state, capacity, and configuration of the GoToMeeting, GoToWebinar, and GoToTraining products in production. Prior to Citrix, he spent eight and a half years working for Fedex where he designed and implemented many high-availability solutions to support the company of over 300,000 employees. He also has served as the Director of Systems Management for Message Factors Inc. and has worked for several small technology firms. Spencer always enjoys a troubleshooting challenge and thrives under pressure. When not working hard, Spencer enjoys spending time with family, cooking, gardening, and riding the waves on his boogie board.

Jim Hirschauer – Technology evangelist for AppDynamics, Jim Hirschauer has an extensive background in highly available, business critical, large enterprise IT operations environments. Jim has been interested in application performance testing and monitoring since his days as a systems administrator in a retail bank. His passion for performance analysis led him down a path to design, implement, and manage the cloud computing monitoring architecture for a top-ten investment bank. During his tenure at the bank, Jim created new processes and procedures that reduced the time spent in the test and QA cycle while simultaneously increasing overall code release quality and dramatically improving end user experience.
October 7, 2014
The Dark Side of Infrastructure as Code

We spend a lot of time extolling the virtues of infrastructure as code. All of it is true. Treating infrastructure as code can add great value in terms of its ability to promote consistent, predictable and repeatable results during the application deployment process. One of the ways in which infrastructure is treated as code is through the use of programmability.

Programmability is an integral component in software defined architectures and a part of the DevOps approach is automation through integration with traditionally development lifecycle focused tools and technologies. APIs, app templates and the ability to programmatically interact with the data path are enabling rapid provisioning of services in the network. That’s important to the business. Improving service velocity in the network is critical to achieving faster time to market and enabling the operational scale necessary to meet growing pressure on networks arising from the growth of applications driven by cloud, mobile and the Internet of Things.

Speeds and feeds of processes are now as important to gain a competitive advantage as speeds and feeds of packets.

Those who see DevOps and SDN as having a strategic impact on their organization view programmability as having even greater importance.

But that does not mean that treating infrastructure as code doesn’t have its dark side. Because adopting a programmatic approach to anything means you get both the benefits and the risks.

I happened to be cogitating on this topic when I stumbled across a post reminding us of the importance of code reviews. The content was so-so, but the premise was spot on: code reviews are a must for those embracing the notion of treating their infrastructure as code.

Why is that (or should it be) an imperative?

Consider some stats from InitialState, “a technology startup helping engineers capture and understand product data. Our cloud-based log visualization-as-a-service platform helps engineers make sense of the exploding number of logs being produced by “smart”, complex products and applications.”

According to their data, developers have to find and fix 100 bugs per 1000 lines of code. And it takes 30 times longer to fix one of those bugs than to write one line of code. Overall, developers end up spending 75% of their time (about 1500 hours per year) debugging code.

Now spend a moment thinking about what that means when you start treating infrastructure as code, writing scripts to automate provisioning and integrating with other systems to orchestrate deployment processes.

I won’t lie, code reviews can be tedious. But the first time someone points out an error, particularly one that could have resulted in a security breach or an undesirable service outage, the pain is more than made up for. In the long run, code reviews are beneficial to eliminating disruptive errors. A SmartBear survey in 2012 found that “70% of organizations indicated that code reviews are very important” and “Those that do code reviews clearly have a greater level of satisfaction in the overall quality of their software – they were twice as likely to indicate that they were very satisfied with their software quality.”

In other words, code reviews are an important part of the software development lifecycle (SDLC). Which means it should be a part of the software deployment lifecycle when it leverages programmability to treat infrastructure as code.

Therefore it is important in the early stages of DevOps (or SDN if you’re going that way) adoption that you put into place processes to check (and perhaps double check) the scripts, templates and integrations you’re using to automate application and service deployment along the entire operational chain – from the app to the network.

October 7, 2014