We will be shutting down for the Christmas holiday tomorrow and will only publish lightly next week as we get ready to update the site for the new year. But we wanted to take a moment to share our holiday greetings card with you and wish you a year of continuous good cheer, good times and peace on earth!
Category: Blogs
-
Merry Christmas, Happy New Year and Happy Holidays from DevOps.com
-
A Year in Review: Top Developer Tools Trends in 2015
The ability to ship software quickly is now a competitive advantage for every business. As a result, continuous delivery, distributed microservices, containers and asynchronous computing have become the norm.
With these changes, come new complexities, markets and dev tool players. It’s clear that the biggest levers for business success rely on developer productivity. Great developer tools have a dramatic impact on how quickly and how well software is built.
Heavybit’s community of developer-focused entrepreneurs, advisors and investors reflect on the major trends of 2015:
- Continuous Delivery is Mainstream. “Continuous delivery is starting to become the norm, rather than just the bleeding edge,” says Edith Harbaugh, CEO and co-founder at LaunchDarkly. “Even huge corporations are adopting a release of once daily where they used to be once every three years. They are seeing a corresponding increase in developer productivity and user value.”
- Packaged Applications Replaced by SaaS. “In 2015 we’re finally getting the tools we need to orchestrate, monitor, and maintain service-oriented architectures with lots of small, independently controlled moving parts.” Says Ben Sigelman, co-creator of Google’s Dapper distributed tracing system, “The forthcoming architectural decomposition is going to turn software development on its head. Subsystems that used to be integrated as packaged applications will now be integrated as services, and the entire developer toolchain will need to adjust accordingly.”
- All Companies Become Software Companies. “Executive teams finally appreciate DevOps as they transition to becoming software organizations. Their competitive advantage is defined by their ability to write better software faster than their competitors,” says Lenny Pruss, Principal at Redpoint Ventures. “Consequently, DevOps and continuous delivery practices are transitioning from being nebulous concepts to actual initiatives that are being put into practice. Almost every organization I’ve talked to is actively re-evaluating how they deploy.”
- Modular development is here to stay. Says Bessemer Venture Partners’ Ethan Kurzweil, “Services like npm that facilitate the sharing and deployment of code modules will usher in a new era of collaboration among developers.”
- Revenue Traction in Dev Sales. “For anyone selling developer tools, there is a big question of monetization,” says Ian Saunders, CTO and co-founder at BillForward. “These sort of tools were sold as large license deals. The issue with this is that there was friction to upgrade, and a massive push to re-sell product rather than reinvesting in existing product. This area of pricing has seen a lot of traction, allowing developer tool companies to sell their tools in a more modern way.”
- Infrastructure as code is all the buzz. “By having your infrastructure as code, it’s far easier to automate builds and deploys and manage change,” says Neil Mansilla, VP of developer relations at Runscope. “The first AutomaCon, an Infrastructure as Code conference, showed that many developers were interested in adopting infrastructure as code but hadn’t put it into production yet, so the trend will likely grow as more developers and companies learn to adopt and implement it.”
- Container Category as an Ecosystem. Noah Zoschke, CTO and co-founder at Convox adds, “Everyone is working on building new tools and services for this container future (i.e. Weave container networking and visualization). AWS Lambda looks like a potentially huge breakthrough, eliminating everything about servers and providing ‘magic containers’ that spin up on demand to events.”
- Automation no longer requires a Heavyweight PaaS. “Containers are enforcing a uniformity of interface that will allow the types of automation that previously required a heavyweight PaaS, and therefore are opening up new niches and product categories,” says Cliff Moon, CEO and co-founder at Opsee.
- Data and Analytics Management Evolves. Says Justin Johnson, VP of developer advocacy at Keen IO. “The conversation is rapidly changing in the data analytics space — from how to aggregate data and make it available for the business to consume, to how to create a robust and fluid data pipeline.”
- Distributed Tools Require Greater Visibility. “Developers usually like to build their own tools, but first-in-class dev tool providers remind us that we have better things to do than build outside of our core competency,” says Hiro Yoshikawa, CEO and co-founder at Treasure Data. “As developers increase the number of tools they use, the need for integration and visibility increases. Businesses must integrate data sources (web, mobile, IoT, SaaS) and target systems (databases, CRM, visualization tools, notification systems). As a result, there’s a rise in new tools trying to solve this problem in the data and analytics space.”
- Dev to production parity remains challenging. Says Tal Weiss, CEO and co-founder at Takipi, “With continuous integration, you get to deliver features faster and see your code making an immediate impact. The problem is that a fast changing production environment amplifies vulnerabilities. No matter how much time and effort goes into testing and staging environments, your code is really only truly tested in production. This is a problem domain that attracts lots of interest as the answer lies with better tooling.”
- Continuous Integration Demands Continuous QA. “Companies who are implementing CI are hitting a bottleneck when it comes to QA. They’ve begun to realize that multiple daily releases require continuous QA practices and tools.” says Fred Stevens-Smith, CEO and co-founder at Rainforest QA.
-
Winning the game with devops at Gameforge
Gameforge is a leading game developer of free-to-play massive online multiplayer (MMO) style games. It provides over 20 games to 450 million registered users on more than 20,000 servers worldwide. As Gameforge continues to grow, the challenges with server maintenance and communication between developers and system administrators continues to increase. I recently spoke with Felix Oechsler, Lead Windows System Administrator to look at the ways Gameforge is overcoming those challenges utilizing DevOps tools and methodology.
I thought it would be interesting to capture the implementation of DevOps at a gaming company since I haven’t seen much on gaming here at DevOps.com, so I took it upon myself to speak with Felix.
As a sys admin, there are two main systems at Gameforge, the windows and linux systems. Felix’s focus is on managing the servers and his job summary includes server upkeep, security, performance management, log data, and to oversee the health of the servers. When I asked Felix how Gameforge came to use DevOps, he told me that it started 2 years ago on a project they were working on. Many issues arose because the communication between the system administrators and developers was not efficient in regards to dumps and data logs. When an error had occurred they needed to inform the developers and then manually hand the data from the server over to the developer team to fix the issues. This took away valuable time from Felix and his fellow sys admins, and also caused various security issues, since they could not give server access to the developers. Realizing the teams needed a way to interact more efficiently and effectively they asked the simple question, how can we do this better?
“We needed a better log management solution to quickly and easily troubleshoot issues before our gamers noticed any problems in the games or systems. We also wanted an all-in-one solution that would be easy to use and manage across our different departments.”
-Felix Oechsler, Lead Windows System Adminstrator, Gameforge
Alas! Devops to the rescue!
Felix’s team began to implement devops tools and best practices such as Graylog’s centralized log management platform. This allowed developers to see the logs in one centralized location without involving the sysadmins to comb through the logs to deliver the data to the developers, freeing up valuable time of sysadmins and minimizing security issues. Graylog helps to deliver 5 beneficial uses including user access management, intuitive search and filtering, visualizations, alerting, and flexible log data extraction. Explanations on each of these can be found here, a case study done by Graylog.
“My development team created our own streams and set alerts for the games we were working on. We’re able to get real time alerts on critical errors in games and applications so we can react faster than before. In one case, our mobile game team received an alert that our connection to the Apple payment system was down. We were able to resolve the problem quickly and avoided the bad user experience of a payment not going through.”
– Dennis Simon, Lead Developer, Gameforge
Gameforge also begun using key performance indicators (KPIs), Graphite and Grafana, to see how the applications are performing, such as high CPU costs. Using both Graylog and the KPIs, developers were able to continuous deploy updates to the games without involving the sysadmins, cutting down on time and cost, and effectively creating a better playing environment for their gamers. Gameforge has developed their own personal, customized continuous deployment platform using C# and powershare to code the mechanism. They decided to develop the platform in-house to best fit their structure and security policies.
Since Gameforge has begun implementing devops tools and best practices they have seen great beneficial change.
“We now monitor our entire server environment with Graylog and have total visibility, enabling us to search for internal application problems across multiple backend servers. Also, our Developers and DevOps people rely on Graylog’s alerting functionality to react to critical errors in our games or applications. Using Graylog, we are able to provide a better user experience for our gamers. Our reaction time is much faster than before, and our players experience less outages and other error-related problems.”
– Felix Oechsler, Lead Windows System Administrator, Gameforge
Using DevOps, Gameforge has freed up valuable time for the system administrators and provided immense visibility to the development teams. Visibility provides quick access to alerts on errors, allowing problems to be fixed quicker and pushed live via a continuous deployment environment. It is safe to say that devops is a valuable methodology for system administrators and developers alike.
-
A Sense of Self
Here are some other ROELBOB’s you might like
W Edwards Deming Finds His Roots
The Pink Slip
Another Pink Slip
Hot off the Press – Other great DevOps.com content
DevOpsSec: 1 in 16 Chances
CIOs Must Fight for Relevance in Face of Tech Storms
— ROELBOB
-
Rugged DevOps: Good, Bad & Ugly
The Good: DevOps has been a success for Dev.
With higher expectations, better processes, more management focus and new tools like advanced PaaS and containers, developers are churning out more and more software faster than ever. Success! Or is it?
The Bad: DevOps has been a success…for Dev.
For Dev teams, this may result in pats on the back and high fives. But for Ops, this can look like one thankless tidal wave of work after another. The same software velocity that is praised in Dev is currently overwhelming their counterparts in Operations. And frankly, many DevOps tools released in recent years happen to benefit Dev much more than their counterparts in Ops. (My pet theory is that developers at IT automation firms are acting and thinking like…developers – focusing their creative energies on solving Dev problems.) A similar problem holds true for IT Security teams who want to build quality in by “shifting left” – see https://devops.com/2015/12/10/getting-rugged-devops-right/ . From the vantage point of IT Operations and Security teams, they are doing more work than ever but without any more human or IT automation resources. To add insult to injury amid their increased workloads, many IT Ops teams have to invest countless hours (away from family and personal time) in training courses and migrations to reorient their processes to fit into shiny, new Dev-centric “DevOps” tools and paradigms.
The Ugly.
Work. Overwork. Glitch. Search. Find. Rework. Repeat.
A quick glance at IsItDownRightNow.com will show you which IT Operations teams are in a living hell at the moment. The other thing you will notice is that these IT Ops teams are from some of the most reputable companies on the planet. They are talented teams but stuck in rework cycles of web performance problems, security vulnerabilities and outages.
These problems get the attention of everyone. Operations…and Dev…and Security…and customers…and Finance…and auditors and the press.
No one likes rework. And no one likes the panicked fire drills that cause panicked rework. So what causes those rework cycles?
Drama-free IT. Visibility Cures Chaos.
Much of this chaos can be tied to miscommunication. Boring? Maybe. Simple? No. Part of miscommunication is cultural. (Hint: OrcaConfig’s “How to Screw Up DevOps” white paper covers the cultural aspects of miscommunication). But miscommunication is also cured by automation solutions that promote transparency and visibility.
If we want drama-free IT we need IT automation solutions that eliminate miscommunication and missed assumptions between Dev, Ops and Security.
What better way to do this than with full transparency and visibility?
Bird’s Eye Views:
Many IT automation tools cater to SysAdmins who are interested in managing configurations of individual servers. That’s great if your focus is on individual severs. But IT Operations, eCommerce teams, Application Owners, Compliance & Security teams and IT Managers often care more about the health and performance of their application ecosystem (including related applications, middleware, databases and configurations that tie them together). So there is often a mismatch between the tools that SysAdmins and Developers have versus what IT Ops needs.
Operating at Enterprise Scale Requires at-a-glance Visibility:
IT Ops teams need bird’s-eye views of applications, databases, middleware and ecosystems to promote ease of ongoing operation. They need to be able to see, at a glance that a configuration compliance problem exists and they need to know right away the location and nature of the error. Large scale IT Ops teams do not have the luxury of toggling back and forth between multiple reports and multiple screens searching for that non-compliant, broken needle in an ecosystem haystack. If they are faced with a glitch or an outage, they need to find and fix it right away. One size does not fit all. Dev, Ops and Security each have their own interests and their own need to view their application through a lens that is most meaningful for them. Multiple ecosystem views eliminate guesswork between Dev, Ops and Security and save precious time in the find-fix cycle.
Forrester Research spells it out well in their 7 Habits of Rugged DevOps white paper, Habit 1: Increase Trust And Transparency Between Dev, Sec, And Ops:
“I&O pros pride themselves on understanding the interconnectedness of the hardware and software environment, and they are unnerved by complexities that poorly governed delivery practices create because the firm rates I&O pros on their ability to improve the performance and stability of the production environment. To maintain the environment, they must reduce the chances of an outage or interruption of service, and they must reduce the MTTR when an issue does occur.“
Understanding that interconnectedness depends greatly on how much intuitive ecosystem visibility we provide to our colleagues in IT Operations. But it’s not just IT Ops that benefits from visibility, Dev and Security do too.
Developers are able to write more secure code when they get early, in-context feedback. As David Mortman, distinguished engineer and Dell chief security architect, said, “Security issues are product quality issues, and no one wants to write buggy code.”
Even better than efficiently finding and fixing errors is of course to prevent them in the first place and to proactively eliminate the damage they cause. Here too, the answer is better visibility. With true application ecosystem visibility, Dev and Ops teams would be able to model relationships between applications, middleware and their configurations so users will know that “changing this, affects that”.
My teenage son has better visibility via his smartphone as to his driving route and weather conditions than I have for my multibillion dollar IT operation.
Visibility into the Future:
Ecosystem visibility is a key to communicating between Dev, Ops and Security and running complex application environments in the present. But what about the future?
Release automation tools and custom scripts are excellent at deploying changes across large environments. Unfortunately they can be just as efficient at deploying typos and other mistakes across large environments, causing the chaos that we discussed earlier. Here again Operations teams would benefit from improved visibility – the ability to preview and pre-validate proposed changes across the entire ecosystem well before those changes are deployed. This is the real promise and savings of ecosystem visibility. Better visibility, with more use-case lenses cuts out the miscommunication that causes too many performance glitches, security vulnerabilities and outages. This chaos takes a toll on our IT Operations teams, our employers and our customers.
What Next?
We are soon entering a new season with new budgets. The temptation to “buy something” will be great. In the spirit of Rugged DevOps my recommendation is to take a full, bird’s eye view of your SDLC and to shift Ops and Security leftwards, building their critical considerations into your processes and into your IT automation tool selection.
-
DevOps Security: Five steps to bridging the gap between teams
Enterprise security and DevOps teams have traditionally operated separately with little to no engagement, often making it difficult to quickly identify and respond to potential vulnerabilities in applications and software. In my last column, I highlighted the value of introducing security to the DevOps process to reduce bugs and vulnerabilities before code hits production. By moving security as close as possible to the code and data, coupled with tight feedback loops, organizations will be in a better position to support the growing complexity of building software.
DevOps emphasizes an agile infrastructure that can change rapidly as new code is deployed, making it a breeding ground for bugs and vulnerabilities when security isn’t taken into consideration. So how do you close the DevOpsSec gap within your organization? The secret is to start simple, take small steps and earn easy wins. Below are five tips:
- Build a development team that cares about its code in production. Your developers must care about their code during development when they’re writing it, when adding new features, how it performs in production and when they create fixes for issues. The team should have complete ownership of the code, what I like to call “code love,” and be able to defend it as if it were their child.
- Implement peer code reviews. The initial way to encourage “code love” is through peer code reviews, which allow developers see what others are writing, encourages them to work together and fosters discussions among the team on how to improve processes. Additionally, with these review processes, teams will be able to identify bad practices early on and improve them.
- Introduce a test-driven development environment. Test-driven development environments mean reproducible testing and can then leverage a continuous integration (CI) server to encourage the team to run security tests every time code is submitted. Many organizations inconsistently do this, don’t do it well or bypass this step entirely. By having developers do more testing and reviews, you can more tightly integrate DevOps and security within the organization.
- Extend the automation. Once establishing the above, it’s time to extend the automation. Encourage your team to do code style and quality testing, which are additional tools to automate “code love”. Good clean code that is easy to read will always have fewer bugs. Additionally, introduce static security analysis to your CI server to help identify low hanging fruit and early-on implementation issues. Another option is to introduce abuse cases by having your team write malicious user stories. These are a great way to ensure the same issues don’t regress, and simultaneously serve as training material for new team members.
- Build firefighting teams. To ensure that everyone across the board cares about this process, pull members of the DevOps and security team and put them on-call together on a weekly basis. This collaboration will allow each team member to see the issues other teams face and how their needs overlap, building a deeper understanding of each others’ roles and processes. After “code love,” this is the second most important feedback loop you can introduce to your organization.
To successfully initiate DevOpsSec within an organization, developers need to have clear parameters to work within to include the security team in the software development lifecycle (SDLC). By breaking down organizational silos and encouraging the cross-pollination of DevOps and security teams, they’ll be able to gain a better understanding of the issues they each deal with and naturally introduce joint solutions.
-
A Force Awakens
“Star Wars is an Agile software development methodology…Star Wars values rigidity, Spam, fragility, immobility, viscosity, Spam, needless repetition, Spam, and opacity above all other virtues…” – http://bit.ly/1YqhGQG Here are some other ROELBOB’s you might like
W Edwards Deming Finds His Roots
The Pink Slip
Another Pink Slip
Hot off the Press – Other great DevOps.com content
DevOpsSec: 1 in 16 Chances
CIOs Must Fight for Relevance in Face of Tech Storms
— ROELBOB
-
Why do you need to implement a DevOpsSec team?
Just 20 years ago, organizations relied on a single wall of defense to secure their applications and networks. Fast forward to 2015 and that large fence is no longer adequate. With the proliferation of mobile, cloud and SaaS technology adding to the complexity of ever-advancing systems and networks, it becomes much more important that teams across an organization work together as one, toward a common goal. We’ve already seen enterprises adopting new methods of organizing internal structures to increase collaboration through DevOps, but as security continues to be top of mind for organizations, many are looking to further this approach by including the security team in the DevOps conversation. With a DevOpsSec team, organizations can work toward delivering software that is not just reliable, but also secure.
Introducing security to DevOps provides the means to this protection by reducing the number of bugs and vulnerabilities during the build process before code hits production systems. Moving security as close as possible to the code and data will bring a large number of high value benefits to an organization.
The first benefit of introducing security to DevOps is the enablement of team collaboration through tight feedback loops. Development, operations and security teams all have different goals and are motivated by different things, which are often contrary to the other teams. To ensure that these groups don’t work as adversaries within an organization, DevOpsSec encourages them to work together, pulling from all parties’ strengths and building a collaborative and engaging environment. This collaboration offers transparency into the assorted issues that arise within each team, establishing a deeper level of understanding and respect across the board.
The second benefit is that DevOpsSec provides a wider perspective across previously siloed teams. As a result of greater team collaboration, Dev, Ops and Sec teams are able to gain more insight into how the other teams operate. This widened perspective decreases friction between them, further revealing common goals and generating more natural solutions. Overall, the assortment of perspectives results in more efficient strategies for the organization in keeping its systems secure.
Lastly, the implementation of DevOpsSec ensures faster response time to issues. As applications and systems become more distributed and complex, it becomes more difficult to identify and fix bugs and vulnerabilities. Developers are writing and pushing code faster than ever before, and what used to be monthly or longer release cycles can now be measured in hours. This is due in part to the fact that code is being used both inside and outside our networks, requiring more thorough network security. The new normal will be found in developing DevOpsSec teams and moving the security as close as possible to the code and data. Through more continuous review processes and more ownership over code in production, the merging of DevOpsSec can mean faster times in closing feedback loops and will ultimately help organizations to operate more efficiently.
So what will an organization look like after implementing DevOpsSec? As a result of the cross pollination between teams, organizations will have curated an elevated platform for innovative ideas, gained greater insights across teams and developed faster response times to help the business run smoother. With DevOpsSec in affect, organizations will better understand and anticipate security issues and the decisions required to diminish them.
-
The Limits of Project Management
Here are some other ROELBOB’s you might like
W Edwards Deming Finds His Roots
The Pink Slip
Another Pink Slip
Hot off the Press – Other great DevOps.com content
DevOpsSec: 1 in 16 Chances
CIOs Must Fight for Relevance in Face of Tech Storms
— ROELBOB
-
DevOps Chat: Mustafa Kapadia, IBM DevOps Transformation Workshop
I always enjoy listening and speaking with Mustafa Kapadia of IBM. Mustafa is one of the leaders of the IBM DevOps services team. As such he gets to work with dozens of different organizations in helping them on their DevOps journey. As a result Mustafa has amassed a ton of experience and knowledge on the correct patterns towards successful transformations. He had developed a workshop around this that I think is a really great exercise for any organization thinking about DevOps to go through.
I recently sat down with Mustafa for a DevOps Chat. We spoke to him about the workshop and process. Below is the soundcloud audio of our conversation. Below that is a video of a workshop demo Mustafa recently delivered at our DevOps Connect: cdSummit SoCal event in Los Angeles this month. I think you will find them both useful.
Also the transcript of my conversation with Mustafa is below that. Finally, below that is an interview I did with Mustafa at the recent DOES 15 event as well. Hope you enjoy.
[soundcloud url=”https://api.soundcloud.com/tracks/237701095″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”150″ iframe=”true” /]
Transcript
Alan Shimel: And we’re here for another DevOps Leadership Chats. Today’s guest is Mustafa Kapadia of IBM. Mustafa, welcome.
Mustafa Kapadia: Thank you, Alan. Good to be here.
Alan Shimel: Yes. So Mustafa, of course you and I know each other for some time now. But for our audience who may not be familiar, what is your role with IBM right now?
Mustafa Kapadia: Sure. I am the service line leader for our DevOps Consulting Practice.
Alan Shimel: And a great job you do of it. I’ve seen you in action.
Mustafa Kapadia: Thank you.
Alan Shimel: Happy to have you here. Mustafa, one of the biggest issues we hear from executives of enterprises especially is well, this DevOps sounds great and we can understand how startups and smaller companies do it because they are doing it on a green field or from the get-go. But how do I turn the ship here? How do I get started in DevOps? How do we lead the transformation if you will?
Mustafa Kapadia: Yeah, Alan, that’s a good question. In fact, that is probably the most popular question we get asked from our clients. DevOps has so many arms and legs and it’s so hairy and it’s such a big topic, getting started is hard and the way to get started to get the biggest bang for the buck is even harder. And that’s where we start bringing in something that we call value stream mapping exercise. And that really helps our executives figure out what is my end-to- end picture looks like? What are my bottlenecks? What are my low hanging fruit? And probably one of the most important outputs of the exercise is what are my metrics? What is it that I can improve through using DevOps?
Alan Shimel: Yet. And Mustafa, of course I’ve seen you talk about this and you have developed a whole workshop around this value stream method.
Mustafa Kapadia: That’s correct.
Alan Shimel: And recently we were out at our DevOps Connect CD Summit event in Southern California and you had an opportunity to actually do this live, right, on a white board. No slides or anything.
Mustafa Kapadia: That is correct.
Alan Shimel: But why don’t you kind of walk our audience, if you will, and again we don’t have a lot of time but let’s walk them through a little bit about what you do in this kind of workshop.
Mustafa Kapadia: Yeah. Well, first of all, Alan, thank you for inviting me to the Summit. It was actually great to catch up with you… It was great to be there and present… But to answer your question, what we start off with in a value stream mapping exercise is just ask the audience or ask our clients How do you do thing folks from point A to point B. Who does it? How many people does it take to do? How do you set up a DevOps environment? What kind of tools do you use? How long does it take? What processes do you use? And depending on how much time we have with our clients, we can go very deep, in the Summit itself, we were very high level since we only had an hour and a half. And what that does is A) Even for the clients, it gives them a complete point of view about how you actually get an idea to market from the time the development team starts coding to the time that it actually reaches the end customer or as we say, moves into production? And it in many ways it is simply a conversation. It’s a facilitated conversation with a goal in mind but it is a conversation about how do you do things and where are your problem areas? And in many cases, for a client, this might be one of the first times that development and operations are actually sitting down in the same room and talking to each other. In many cases, operations is a separate environment and then the development team has to go in and do their own stuff to get the environments ready, to be ready for the developers to start using it. So value stream mapping exercises in many ways is the first time that they are collaborating on the big picture. And that’s what DevOps is all about. It’s about getting the dev and the ops teams together.
Alan Shimel: Yep. And Mustafa, typically when you are doing these in the field with real live enterprise customers you’re dealing with, what’s the feedback from the executives that you are working with?
Mustafa Kapadia: The two that come to mind is that number one, most executives are amazed at how long it actually takes them to develop code and actually bring it out to the market. It is not uncommon in a large enterprise for the entire lifecycle from the time an idea has been generated and approved to the time that it actually meets the customer or the end-user. It could be as much as 300 days. We were at a bank in which it took them almost 390 days to get some type of a release out to the client. So number one, it’s first just – they are surprised at how long it takes. Number two is, the honest dialogue that they can generate, not just with us but more importantly within their own team, is probably the most valuable key of that exercise.
Alan Shimel: Agreed. And Mustafa, I know some people are listening and they’re saying oh great; here’s an IBM services guy who’s going to be pushing us to buy IBM product…But the fact is or maybe it’s not the fact, it’s my understanding the fact is that that’s not the case in this exercise in these kinds of engagements that you work in, correct?
Mustafa Kapadia: Yeah, definitely not. In fact, a lot of I would say close to 99% of the time, maybe even 100% of the time, we rarely talk about IBM tools or any system tools for that matter. It doesn’t matter if it’s open source, or if it’s proprietary. That exercise is more about understanding the…process and the…pain points. So it has nothing to do with IBM or it sets of tools but more about clients understanding the end to end workflow.
Alan Shimel: Yep. And so Mustafa, let me throw something else at you. I’m going to throw the big C word out there, culture. Because that’s the other thing we hear from execs, correct? How do I change my culture? So everyone talks about this DevOps thing being a cultural sort of leadership thing. How do I do that? What do you do – do you do anything around the culture as part of this exercise?
Mustafa Kapadia: We do, we do. So cultural behavioral changes, that’s what we call it here, is a big part of this exercise. Part of it is that I’ve mentioned earlier is people sitting down and talking and sitting down at a table and talking about the entire workflow. But the larger question is a lot of the cultural change happens is actually go through the transformation journey together. So instead of just the operations team doing their fees and development thing in doing their feeds, when we start putting solutions together for our clients, we bring both these teams together and sell the solution together that both of them can support. And that is where the cultural and behavior change starts happening. Not just what they’re doing but how they are doing it, how they are communicating. A lot of the change happens by doing as opposed to just somebody coming in and say well, you need to change or organize your structure this way or you need to put a new metrics and so on and so forth. Our customers that succeed in DevOps do it primarily by actually doing some of the stuff together as opposed to doing organizational realignment.
Alan Shimel: Makes sense. So Mustafa, my next question to you is sort of the classic consultant’s dilemma, right, and that you come in, you identify the pain points. You identify new processes, new ways of doing things. You advise the client. You may even stay there on a short engagement timeframe to hopefully see these things starting take root. But what happens after the consultant leaves? What’s the success rate of this stuff really taking hold?
Mustafa Kapadia: To be honest with you, a lot of the bread-and-butter at IBM in our service lines is actually what happens after the consult engagement. What we sit down with the client and actually help them execute the roadmap that we had developed together from A) building the platform to integrating disparate capabilities into the platform, supporting that platform and even training. In fact, one of the things that we are rolling out right now with some of our clients is actually training our customers, our clients, on how to start using some of these DevOps platforms tools and so on and so forth. So our longtail…believe it or not, is actually sitting down with the customer and helping them through the entire journey as opposed to just coming down and putting things down on PowerPoint. In fact, the consultant piece is a very small part of that business. Our real business is about hand-holding them through the journey.
Alan Shimel: Great. Makes sense. So Mustafa, we are coming close to our time limit but I have another question or two for you. I was on a webinar this afternoon with Gene Kim and lady named Shannon Leitz from Intuit. And it was on security DevOps. But we got a couple questions from the audience in there. It’s a reoccurring theme here at DevOps.com. One gentleman wanted to know this is all fine and dandy for tech firms. But do you have any examples….chemical or energy-related firms that were doing DevOps? Of course, another person wanted to know did you have any white papers on financial related firms doing DevOps? And you and I were both at the DevOps enterprise. We saw all kinds of companies from presenting there…
Mustafa Kapadia: Yep, definitely.
Alan Shimel: But your own personal experience, Mustafa, is there a particular vertical that is more suited to adopt this or less suited to adopt these kinds of ways?
Mustafa Kapadia: Yeah… So the general rule of thumb is that anytime you have a system of engagement application, that is the best place for us or for you guys to start DevOps. That is where you get the biggest bang for the buck. And that is where this whole idea of being agile … to market makes a difference. Now, with that being said, there’s actually three key industries taking up or adopting DevOps faster than all the other sectors that we have within IBM. First is financial services. Second is retail and third is believe it or not, actually software development companies. So it’s these fast-paced companies that are trying to get some more features and product out to their customers and clients. We see those three sectors taking up DevOps or adopting DevOps much faster than the rest of the industry. But that doesn’t mean that the other parts of the industry are not doing it. In fact, we are right now working with healthcare clients. We’re also actually working with an energy client who is trying to figure out how to bring DevOps into their mix.
Alan Shimel: Excellent. The next question is I’m actually working on a report that I want to put out next month on my prediction for 2016 that this is the year of the great divide where we are really going to see the gulf widen between companies who are adopting DevOps patterns and not just DevOps but the Cloud, hybrid Cloud, big data, IOT, the open enterprise if you will versus companies who are sort of digging their heels in the sand… Do you think this is the year we see….real gulf starts opening up or old-style companies skate by still?
Mustafa Kapadia: Yeah, I unfortunately think it’s more of the latter than the former. I think some companies, especially in traditional industries, are still going to stick to their guns, so to speak, and think DevOps is just a fad. But then the industries that I’ve just talked about, I think those is where the gulf between the doers and the not doers is going to start widening especially when you get a retailer who can now push out enhancements to their e-commerce website, we’ll definitely see them picking up the benefits of DevOps as opposed to somebody else who just chooses not to do it. I think that’s where it’s going to happen this year or I should say next year. And then if that does happen it, 2017 becomes a really interesting year because that’s when everybody starts to catch up. A lot of our customers are trying to get on the ground in 2016 so they are not in bad shape in 2017.
Alan Shimel: I think otherwise it could be fatal to their business. Mustafa, one last question and I usually ask all my guests on the podcast near the end and we’ll let you go. For our leaders out there who are wanting to maybe dive deeper into DevOps or just want to lead the transformation at their organization, if you had to pick one book for them to read, what book would it be?
Mustafa Kapadia: Oh, that is a very tough question. There is actually a book called Competing Against Time. It was published in I believe 1975 by a managing partner at Bing. …While it doesn’t talk about software development or application lifecycle, it really talks about how you can start thinking about time as the element of competition. And it’s what other companies are doing or perhaps have done in the past to actually help you actually use time to kind of gain not just an advantage but almost an inhuman advantage over companies, right? So that one comes to mind…Dell comes in mind. This idea about DevOps is not a new idea. It’s new to IT. But the idea of us drinking time has been around for quite some time. And I really like that book because it kind of, a lot of the principles that we talk about now in software development can be found in that book in examples outside of IT and in other industries.
Alan Shimel: Fantastic. That’s a new one to our book list and great suggestion. And it just goes to show what’s old is new and some things never go out of style, right? Anyway…
Mustafa Kapadia: That is correct.
Alan Shimel: Mustafa, we are over our time, I apologize. It’s hard to do these things in 12 minutes. I apologize. But thank you so much for appearing on this episode of DevOps Chats. And thank you so much for helping us whether it be at CD Summit or DevOps Enterprise Summit or at so many locations we run into each other. Not to mention writing press here at DevOps.com.
Mustafa Kapadia: Thank you. And Alan, you’ve always been generous and I appreciate that. I also, if I have a few seconds to make another offer to all of your audience. Three things, actually. So this value stream mapping exercise that we’re talking about in many cases, will actually do it for free for some of our clients so you guys can reach out to me. And Alan, you have my card…
Alan Shimel: Yes, we’ll put it in there.
Mustafa Kapadia: So that’s number one. Second is, we have this IBM conference call, Interconnect, which is in Las Vegas. It’s on 2/21-2/25. It’s a great way to learn about DevOps.
Alan Shimel: I will be there, Mustafa.
Mustafa Kapadia: And last year we had 300 or so DevOps sessions. Perfect, perfect.
Alan Shimel: Yes.
Mustafa Kapadia: And the last thing, if I’m not running out of time, is if you guys can’t wait until Interconnect, I actually publish a monthly newsletter and if you can just email me, I’ll be more than happy to put that on as well.
Alan Shimel: What’s the email, Mustafa?
Mustafa Kapadia: Email is M.A.Kapadia@US.IBM.com.
Alan Shimel: Fantastic. Mustafa Kapadia, IBM. Thank you so much for being today’s guest on DevOps Chats.
Mustafa Kapadia: Okay, thank you very much, Alan. I appreciate it.
