devopsy.kinsta.cloud

Category: Features

  • In DevOps, Speed Isn’t Always the Point

    In DevOps, Speed Isn’t Always the Point

    The high-tech industry has fallen into a rut and seems to be struggling to get out of it. This rut is most fervently seen when talking about DevOps, but it exists across the board.

    We’ve fallen in love with the idea that faster is always better. That idea is provably false, and the assumption that everything needs to be faster is false, also.

    Early on, time to market and increased responsiveness to user needs were the driving market differentiators for agile development, DevOps and DevOps tools. There were indeed cases where IT was not responsive enough to business needs—I think most of us were acutely aware of this issue, so dwelling there for a while was not a terrible thing. But responsiveness to business needs is one piece of a much larger puzzle. And we seem to be stuck, with some lip service paid to other strengths of DevOps … as long as it’s still delivered yesterday.

    In my career I’ve worked in two industries where speed of delivery was a tertiary concern for core business systems. To be blunt, when you are putting together a system that will administer contracts expected to last a hundred years or more, you really don’t get that worked up about it being out there tomorrow and “good enough,” you worry about it being right when it does go out, so you’re not still paying for mistakes a century from now that were made by rushing today.

    Of course, there are vendors that don’t want to hear people like me say these things. Of course, there are products with other benefits that are more important than speed of delivery. But as an industry, we’re still too obsessed with speed.

    How we too often see priorities

    Most industries do not even fall into a neat category where they are all or nothing. For most, some teams need to be fast, using agile, CI/CD and fully automated deployment to drive out changes fast (not as fast as some talk—most don’t even need weekly, but fast, nonetheless), while other teams need to be more thorough and cautious and the cadence of releases really doesn’t matter as much as the final result.

    So my advice is similar to advice I’ve offered on similar “hot” topics for the last decade or so:

    You are the rock stars.

    No vendor, analyst, pundit or author knows your vertical market, organization, environment or team the way you do. Do not let them proxy their view of what is “right” over you. Yes, far too many act as though, “If you’re not doing X, you’re behind.” But again, you can look at your industry and get a better grasp of what the definition of “behind” is than someone talking in generalities.

    Know what you need, know what is most important, know how to get to what you need. Don’t do what “everyone” says you should.

    But don’t dismiss the need, either. There are other benefits to these technologies that we have only recently started discussing. Infrastructure as code is an astounding way to transfer knowledge should something happen to critical people, for example. You just have to choose the technologies for the right reasons, and what the right reasons are is dependent upon the organization, not what Vendor Y is selling today.

    We’ve come a long way, and are on the cusp of some very cool stuff, but make sure you know what you need, and how to get it, then keep doing your magic.

    — Don Macvittie

  • Automation’s Impact on a Structured Life

    Automation’s Impact on a Structured Life

    A few years back my sister’s husband died after an unexpected illness. My sister, who was in her early 50s, experienced a devastating loss at a relatively early age. To her good fortune, my brother-in-law left behind an adequate pension and their mortgage had been paid off, so she didn’t have to bear the burden of having to work to make ends meet. And she didn’t—for a while, anyway.

    After a period of mourning and adjustment, however, my sister decided to return to work. I asked her why, and this was her response: “There were only so many movies I could go to, only so many TV shows to watch, only so many trips to take. I just needed something to do.”

    Now you may ask, what does my sister’s loss have to do with the impact of automation on human employment? Consider this: As automation replaces more human labor, fewer people will be required to make the economy function. Many of those whose labor is no longer needed will be left unemployed, sitting at home deprived of the thing that gave their lives meaning and structure: a job. And without a job, many will be left adrift—not just economically, but also psychologically, living a life without meaning or purpose. That which made their lives worth living will be gone. The implications of a population put aside by automation and living a life without structure or meaning are significant.

    Allow me to elaborate.

    The Need for Structure in Day-to-Day Living

    Human beings are not born with the instinct to organize their waking hours. Anybody who has a 2-year-old can tell you, a child will run around all day until he or she drops. It’s up to mom or dad to say, “It’s time for breakfast, “It’s time for lunch,” “It’s time for a nap,” “Bedtime’s coming; put on your pajamas and let me read you a story. Good night.”

    Children need structure imposed on them from an external source. That’s how it is. This role is filled by a parent, and later in life the school in the form of structured activities performed at usual times. By the time a youngster enters high school, most will have a firm sense of how a day is organized.

    This sense of organization transfers well to the workplace: A good employee respects the structure of the day. She arrives on time, does the tasks for which she is responsible, communicates the status of her tasks, respects the time of others and meets the time demands made upon her. Whether you work in a factory or a law office, being able to operate effectively within the structure of the workday is essential to one’s economic and psychological well-being. There is a certain comfort that comes from knowing where one is going to be on Tuesday and knowing what one will be doing.

    So, what happens when the job goes away? How does one organize himself or herself without something explicit to do? As my sister said, “There are only so many TV shows to watch.”

    Let’s take a look at the extreme.

    Providing Structure Where None Exists

    When I was a young man, before I got into programming, I was a counselor at a secure detention facility for adolescent boys. This a nice way of saying I was a guard in a kiddie jail. Most of my day was spent supervising the movement of teenagers who had committed very serious crimes. When I say supervising their movement, I mean that in the most literal sense. The job of my squad was to make sure the residents woke up on time, dressed in their rooms and were ready to go to school. Then, we called for lineup. The boys lined up and were counted. After count, our squad moved the line to breakfast and then onto the facility’s school. Once in school, we stood at the back of the classrooms to supervise the residents. If a student acted out, we removed him from class. At the end of the school day, we did the lineup again and went back upstairs. The residents went to their rooms. Then they lined up for the exercise yard. At 6 p.m. we lined them up again and went to dinner. After dinner, we moved the line upstairs. At shower time, we moved the line to the shower room. The day was very structured, to say the least. Day in and day out, everyday was predictably the same.

    And you know what? It worked.

    The residents responded to the structure. Most grew to accept the routine. They went to school and got a little smarter. Three square meals a day made them a little healthier. These were boys who had been left to their own devices since early on, mostly because of neglect. They had little sense of how to organize a day. They just did whatever popped into their heads. And sometime what popped into their heads was an armed robbery or felonious assault. In terms of the ability to organize themselves, most were at the level of a 2-year-old—a scared 2-year-old. Not surprisingly, the predictability of events and presence of supervision made them feel safe. Once, I asked one of the residents why he was there. He said with surprising candor, “Because I want to be.”

    When a Job Goes Away

    Granted, adolescent incarceration is an extreme example of imposing structure on someone’s life where no structure exists. But, what happens to a person when a job—the basic agent for organizing one’s daily life—goes away?

    Here’s what happens.

    Some people die prematurely. A study of Shell employees found that those who retire at 55 are 89 percent are more likely to die in the 10 years after retirement than those who retire at 65.

    Others have increased rates of substance abuse. A study conducted by the Substance Abuse and Mental Health Services Administration indicates that 17 percent of unemployed worker suffer from substance abuse—twice that of those who are employed.

    Or, they spend more time sleeping and watching TV, as reported by the Wall Street Journal.

    Clearly, having a job is better than not having a job. Financial considerations aside, it’s the way by which most people organize their day. As more people become displaced from the workforce because of automated labor and are living without the demands of daily work to structure a day, more of the population will feel adrift. If the trends described above stay true, there will be an increase in substance abuse, TV watching and death rates. They also may look to other external forces for structure, such as political movements that promote order, rank and predictability.

    So, what are we to do? In earlier versions of this article, I included a call to action to revamp, maybe even revert, the educational system to focus more on the arts and humanities rather than the baseline skills required to get a job. I planned to point out that artists, athletes, scientists and entrepreneurs don’t need to a job to structure themselves. They always have something to do. They have an internal ability to organize themselves in the pursuit of short- and long-term goals that are their own. As we move toward full automation, these folks are going to do just fine.

    Anyway, that’s what I planned to propose in the earlier versions. Now I just don’t know. I am not sure we have the social or political will to address the problems that are on the horizon. The highly educated people who have good analytics skills and a creative outlook will find paying employment. But, as trends indicate, those who are paid to follow instructions and perform redundant tasks will be replaced by robotic automation. They will go home. They will watch unlimited amounts of movies and TV on Netflix, Amazon and YouTube. They will play games on the internet, for a while anyway. Then, one day they will come to realize that there are only so many movies to watch and so many games to play. The appeal of an unstructured life will wane. They will want something to do and have no idea about how to make that something happen.

    So the questions at hand are these: Will we fortunate ones—particularly those of us in IT, the people who are implementing the automation—watch from the sidelines? Or, will we come to understand the consequences of automation on human employment—and in doing so, will we be become part of the large-scale solution, devising ways that help those that are going to be displaced think different and be different?

    I hope so.

     

    This article is the last of the series, The Impact of Automation on Human Employment. Here is a list of the previous articles:

    What Do We Do When Everything is Automated

    Rethinking Unemployment in the Age of Automation

    The Impact of Automation: Considering 3 Facts

     

    — Bob Reselman

  • Security @ the Speed of DevOps Survey: Efforts Still Lag

    Security @ the Speed of DevOps Survey: Efforts Still Lag

    Enterprises today are in a relentless race to digitize or die. If they don’t digitize business processes, services or internal workflows and their competitors do, they will be at a steep disadvantage—and perhaps soon an irrecoverable one.

    In more and more companies these efforts are being driven by DevOps. According to IDC, the vast majority of businesses today think—and rightly so—that it is essential for them to put into place the right resources and IT processes to support a digital business model. Unfortunately, about 75 percent of organizations don’t think that their IT organization is actually scalable enough to deliver and support a comprehensive digital business model.

    There are many reasons why so many organizations have a challenging time with their digital transformation efforts. Many of these are cultural: IT commands tightfisted control over all information technologies used throughout the organization, yet being unable to deliver the infrastructure and digital services enterprises need to succeed, for example. Or, others within the organization still are unable to see how rapidly the world is being changed by digital technologies and so aren’t taking the necessary steps.

    Another reason is security. That’s because this rapid digitization of business processes can have a profound impact on how enterprises secure their data, applications and software development and delivery. In devopsy.kinsta.cloud’s inaugural annual “Security @ the Speed of DevOps” survey, we queried 255 security IT decision makers within organizations currently practicing DevOps or that are on a path to DevOps adoption. The survey found that enterprises of all sizes are embracing DevOps, cloud, continuous integration and deployment. But in securing these processes, however, we found vast differences in maturity.

    When it comes to DevOps practices, larger companies are outperforming. For organizations with 5,000 to 9,999 employees, a full 90 percent have either adopted or started DevOps practices. However, only 38 percent of organizations with 500 or fewer employees have started DevOps or widely adopted such practices.

    As I wrote in our report on the survey, smaller organizations also have a way to go with automated security testing. Only 6.5 percent of those with fewer than 100 employees have automated large parts of their application security testing, while 29 percent have automated some of their application security testing. For firms with 5,000 to 10,000 employees, 38 percent have automated large parts of their testing, and nearly 50 percent some of their testing. For those with more than 10,000 employees, these figures are 20 percent and 48 percent, respectively.

    The challenge here, for many organizations, is the same with enterprise security in general: the view that security slows things down. For the business, it’s about getting more digital capabilities out as quickly as is possible. It’s the same for developers. Security too often is seen as standing in the way of this.

    When this conflict is experienced at DevOps speed, there is the risk not only of development slowing down but also security processes breaking. To succeed, enterprises can’t take the same approaches to security as they did in the past. They must find tools and processes that are designed for the highly automated and continuous world of DevOps.

    Have a look at our survey and report to see how enterprises are tackling this challenge today.

    — George V. Hulme

  • DevOps Chat: Justin Vaughan-Brown, AppDynamics

    DevOps Chat: Justin Vaughan-Brown, AppDynamics

    This episode of DevOps Chats is with Justin Vaughan-Brown of AppDynamics. This was recorded just prior to the announcement of Cisco’s intent to acquire AppDynamics for about $3.7B. So sorry, folks no insight into that deal here.  Nevertheless, Justin is a DevOps veteran. While at AppDynamics for just a few months, Justin has worked and helped lead several DevOps tool and consulting businesses. He has some great insights that he shares here with us.

    As usual, the streaming audio of our conversation is immediately below, followed by a transcript of our conversation. Enjoy!

    Alan Shimel:                Hey everyone, Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. And our guest for this edition of DevOps Chat is Justin Vaughn Brown of AppDynamics. Justin, welcome to DevOps Chats.

    Justin Vaughan-Brown:          Thanks Alan, glad to be with you.

    Alan Shimel:                Glad to have you here. Justin, you are a DevOps industry veteran, if there is such thing, in a relatively short time. But you’re hanging your hat at AppDynamics now. How long have you actually been with AppDynamics?

    Justin Vaughan-Brown:          I’ve been with AppDynamics since – it was the very last day of October, so kind of two to three months in now.

    Alan Shimel:                Perfect, just enough to get I guess the lay of the land there. And as we spoke beforehand Justin, and as I think most of our audience, it’s been a busy two to three months, you know, between the end of the year and everything going on in the market you’ve had a good chance I would imagine to get a flavor for not only what AppDynamics is doing but really kind of where the market is heading a little bit in terms of DevOps APM and stuff like this. Correct?

    Justin Vaughan-Brown:          Absolutely Alan. I think what was very interesting was – actually a few weeks after joining – was spending time with customers and partners and colleagues at App Sphere in Las Vegas in November: that was absolutely fascinating, so that was a real eye opener in terms of how APM customers – you know, those of AppDynamics are actually using DevOps and adopting it and how they’re leveraging our technology to help them in their DevOps adoption.

    Alan Shimel:                Yes, I was actually at App Sphere as you know – I was at App Sphere myself and it was a great conference and it was a great customer-focused conference in that there were a lot of users there – real live users, right? – the rare, endangered live user at these conference – not a Biz Dev first and not a sales person but real users and I had some fantastic conversations myself.

    Justin, I wanted to spend a moment a little bit talking about APM because sometimes when we look at software development life cycles and kind of where the action is around DevOps you know a lot of people get all hot and bothered and hyped up around configuration management, right, the puppet and the chef and the ansible and salts and these kinds of things. And then, you know, they move from configuration management to CICD and of course that’s a world unto itself.

    But then when we look at let’s say post deployment, you know, okay, so now we delivered and we’re delivering continuously, but what impact is that having? How are things going? Are our customers happy? Are we delivering better products, right, and are they performing as intended?

    And you know all of these things you would think would make APM sort of king of the castle, top of the heap. But a lot of times it doesn’t: it kind of gets subsumed within the whole DevOps conversation or is maybe a little bit outside.

    I’m interested in what’s your opinion on that?

    Justin Vaughan-Brown:          That’s an interesting perspective and I can see where you’re coming from. I think it’s possibly because, you know, from historically a lot of the vendors are more and more what you call classically the dev side and have generated a lot of interest and adoption. But ultimately we’ve seen the company grow from strength to strength, and I think what was really eye opening was – at App Sphere – was seeing how critical app dynamics was in enterprise DevOps adoption.

    And I think what most particularly – you’ve hit the nail on the head there – if you look at for example the impact of those applications in production how are they actually performing, where our issues lie, where the – the apps themselves can be fine tuned and ensure that you have the best customer experience possible.

    I think in the main – and this is a generalization of course now, there are exceptions – I think we’ve gone beyond the state where applications – with the exception of certain tougher cases like say, you know Black Friday and so forth where sometimes some organizations can have challenges – but in the main I think what we are seeing is most applications perform at what I would call a base level – what we’re really now into is tuning them: is identifying absolutely the tiniest little bit of latency or glaze or issues wherever they may lie so that the performance of those applications, irrespective of where they’re delivered – you know, on a tablet or mobile device, on a PC or whatever – are highly high performance, and again, irrespective of platform, operating system or so forth – all of those – I think that’s become one of the overriding demands.

    And I think it’s evolved even more so now – you know, we recently launched Business IQ which actually drills it even further and actually looks at the business benefit of the application you’ve released where a consumer’s using the application, where are they located, where are they on the user journey, where are they on the purchase cycle. And you’re finding lots of consumers are going through to about to purchase and then there’s a delay in the actual purchase process as the transaction is going through or not going through.

    So I think it’s definitely evolved and I think we’re seeing certainly an absolute relevance for APM now.

    Alan Shimel:                Got it. Absolutely. Justin, let me – as I said earlier you’re a DevOps industry veteran though and AppDynamics isn’t your first stop on the DevOps train.

    Why don’t you, if you can share with our audience a little bit – we’d like to hear your views though on – so that’s APM and what sets it apart – what other kind of – let’s look at trends in the DevOps space and maybe how it relates to APMs.

    What other kind of trends are you seeing?

    Justin Vaughan-Brown:          I think one of the interesting ones that we’re seeing is – you know, you’ve seen the evolution of Docker over the last kind of 18 months to 24 months, and I think that and the overall rise of containerizations in general is having a huge impact.

    I recently saw an article by a bank – folks who were going to report that they’d recently issued on the – I would say the stellar rise of containerization and adoption, and it’s almost a case of, you know, there’s no going back.

    So I think it’s really down now to where you’re adopting containers and to what degree, one or another, if, for example. And that’s where we’ve seen our ability to help that; for example in terms of their integrating and monitoring docker container performance easily to ensure that you’re optimizing and maximizing the potential there and that doesn’t become a black box area where you’re not getting the granularity of insights that you’re looking for. So that’s one area definitely.

    I think also, you know, with cloud adoption as well, to be able to monitor across multi cloud environments – and that’s just not one vendor only, you know – as I said multi cloud – whether it’s Amazon AWS, Microsoft Azure,  and so forth.

    So I think there’s a need to be, you know, platform and cloud agnostic going forward. And that’s something recently I’ve seen at analyst conferences where they talked about so many enterprises now from an operations point of view being cloud brokers and then looking at not just one vendor – not being locked in – but being able to switch and change dependent on which particular application they’re working on or initiative and so forth. So I think those are two clear areas.

                                        I think the last one probably I’d highlight is micro services where, for example, the ability with APM to automatically monitor in micro services, you know, deployed in an elastic infrastructure so you can look at issues around say threat contention and then zoom in and identify and address their root causes.

    So seeing all these kind of technologies orbiting around that APM can absolutely assist in the adoption. And if you adopt this properly obviously they’re hugely advantageous. If you struggle with them then they can actually set you back and you’re worse than if you hadn’t embarked on that journey. So those are three that immediately come to mind Alan.

    Alan Shimel:                And I don’t disagree with any of them Justin, I think they’re all dead on.

    Let me throw another – and this might be a bit of a curveball at you – but as a fellow observer of the DevOps space Justin what I find interesting is that when we first started talking about DevOps everyone sort of said, “Oh yeah, DevOps is great for startups because it’s in their DNA and they do it by – you know, not by choice: they have to. And this is – DevOps was made for these folks.”

    Where you know this whole issue of “enterprise DevOps” was almost like a different animal or a different set of stripes. And you know I was always one of the ones that argued DevOps is DevOps, you’ve got to recognize who your customer is and who your organization is, but the principals of DevOps apply across small and large organizations.

    But low and behold here we are now, you know, a new year and we’re a couple more years into this DevOps thing and it almost feels like DevOps is a big organization way of doing business, maybe even more so than the startups. What’s your feeling on that?

    Justin Vaughan-Brown:          I think you’re absolutely spot on Alan. I mean I think we’ve both been on that journey where we’ve observed certain trends and how the markets evolved.

    And if you look at, for example, at the DevOps Enterprise Summit that took place last year in San Francisco and London – both extremely well-attended – and then if you look at those agendas on both of those the vast majority from my perspective of those presenters presenting from the end user side were representing enterprise organizations – household names – in fact if anything those smaller organizations were the minority, and equally even the – you know, there’s also I think with the larger organizations it was those that were not just the, you know, the purely kind of online shop equivalents where they’ve got no legacy infrastructure that they have to deal with: a lot of these are, you know, 50-, 100-year-old companies that have been around a long time yet are making that brave journey.

    And I’d like to just kind of re-quote an observation made by Gene Kim last year when he said what really impresses him is – it makes him really think of people who are being heroes within these large enterprises, within these organizations, who are, you know, probably I’d say mid-level advanced in their career and in age and during their career who are making these brave decisions, who are doing things differently: they could carry on as normal.

    And in doing so they are trying different things, they are embarking on new journeys and they’re bringing their teams with them, they’re collaborating more closely.

    And I think that’s – it’s those kind of – I think Gene Kim is absolutely spot on in it’s those kinds of heroes, those catalysts to change – and I think frankly DevOps is absolutely for the enterprise and will continue to be so.

    Alan Shimel:                Makes sense. Justin we’re running a little low on time. Let me turn this back to App Dynamics if you don’t mind. What are you – so we’ve talked about these trends, we see the market kind of taking shape – what does it mean for AppDynamics?

    Justin Vaughan-Brown:          I think it means a lot of opportunities to continue to help the enterprise customers. Most of all I think – you know, from a personal level I’m very excited by the recent release of Business IQ because I think that enables DevOps teams now to take information relating to how that application is being consumed, where and in which way of these visual user journeys – to actually then take that information and present it to the business – and that moves it from purely a DevOps conversation to a business one just to say, “Look this is – you know, we’ve all be slaving away the last couple of months on this application. Here’s the actual impact to your business; this is what’s happening, this is the value.”

    And then maybe the business turns around to say, “You know what? Interestingly sales in this region are going really well but not in this region or this group of customers, you know, our gold card member carriers are absolutely loving this promotion but our silver card holders aren’t. Maybe we need to incentivize them in some way,” you know, and so forth.

    So that’s moving, as I said, the DevOps teams into a more business conversation. We know about this topic such as Citizen Developers and obviously Shadow iTeam – more and more and more the businesses are being involved in these decisions, and that’s the way for DevOps to help drive that dialogue rather than being on the receiving end and taking requests from the business, that they’re actually driving that discussion which puts them in a really good position.

    Alan Shimel:                Excellent. Justin, we’re just about out of time here but I want to ask you one last question and that’s the kind of question I ask a lot of our guests here on DevOps Chat.

    For our audience listening out there if you had to recommend one book – and not the usual, you know, Gene Kim Phoenix Project that you would expect from a DevOps podcast – what book would that be?

    Justin Vaughan-Brown:          I think I would go back to a book and a course that I took almost 20 years ago which is The Seven Habits of Highly Successful People by Steven Covey which pretty much broke down most of everything that I knew and rebuilt it another way and gave me a fresh perspective, so I strongly recommend that.

    And if you’re pushed for time I think there’s some YouTube videos where you can go in and get the canned insight in 15 minutes, so that’s well worth taking a coffee break.

    Alan Shimel:                Absolutely. But that’s a classic. And for any of our listeners who have not read that one it really should shoot to the top of your list.

    Hey, Justin Vaughn Brown, AppDynamics, thanks for being this episode’s guest on DevOps Chat. Look forward to having you on again soon and sharing some more market insights.

    Justin Vaughan-Brown:          My pleasure. Thanks very much indeed Alan.

    Alan Shimel:                Okay. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. We’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • Gain a Competitive Edge with DevOps

    Gain a Competitive Edge with DevOps

    DevOps has attained mainstream status. It is no longer a cutting-edge concept that only startups and progressive companies embrace—it’s a business imperative that delivers a significant competitive edge. If you want evidence of the impact of DevOps, take a look at the 2016 State of DevOps report.

    But what is it about DevOps that gives companies a strategic advantage over competitors?

    “A DevOps approach enables companies to respond much more quickly to customer needs, competitive pressures and realize faster time to innovation,” says Sacha Labourey, CEO of Cloudbees. “Because DevOps is all about a culture of shared goals, and processes that accelerate software delivery through smaller, incremental releases, issued more frequently.”

    However, Labourey cautions that DevOps doesn’t work to its full ability if the entire company is not on board. There needs to be strong communication and internal education within an organization to successfully implement a DevOps culture. You have to educate staff at all levels in the enterprise of the cultural and structural shift. Essentially, you have to break down barriers and get teams working together that haven’t typically worked together before. In fact, you need teams that may have been at war before, to now work together.

    Struggles between teams often are driven by opposing goals and measures of success. DevOps empowers teams and individuals to work together and collaborate toward common goals more effectively. It’s a synergy that fosters cooperation rather than conflict.

    Labourey says any company has the potential to transform to a DevOps culture. But there are some crucial questions organizations must answer before planning a DevOps transformation:

    • Can the enterprise commit to putting the time and hard work in that is required to effect internal change and behaviors?
    • Does the company environment support a DevOps culture and the values it brings with it?
    • Is the executive team fully supportive, and maybe have even mandated, the change to DevOps?

    “In order for DevOps to truly work, there must be a commitment to enable the change. This only happens with a lot of hard work, diligence and support from the top,” Labourey says. “Any company that needs to deliver quality software—and deliver it quickly—should care about DevOps and the supporting practice of CD.”

    DevOps, and the culture of teamwork it instills in organizations, delivers significant benefits:

    • A decrease in time to market—innovation is delivered rapidly. Additionally, experiments can occur, with a “fail fast” mindset.
    • Internally, satisfaction with the overall software delivery process attracts and retains better IT talent.
    • Employees can innovate quickly and just as quickly see the results of their innovation.
    • Software is of higher quality, since releases are smaller, incrementally produced and have less impact on the overall application and infrastructure.

    I know that this isn’t news to many companies and individuals, and that, to some extent, I am preaching to the proverbial choir. For those just climbing onto the DevOps bandwagon, though, or those who may have lost their way and have become frustrated with their DevOps experience, I think it’s important to remind everyone what the benefits of DevOps are supposed to be if you get it right.

    — Tony Bradley

  • DevOps Chat: Chris Lazzaro & Peter Klenk, IBM Bluemix and IBM Bluemix Garage

    DevOps Chat: Chris Lazzaro & Peter Klenk, IBM Bluemix and IBM Bluemix Garage

    In this DevOps Chat, we catch up with Chris Lazzaro and Peter Klenk of IBM Bluemix and Bluemix Garage. With IBM InterConnect just a month or so away, it is a good time to hear what those innovative Bluemix folks are up to. Peter and Chris give us their take on new IBM Bluemix services, as well as the continuing evolution of IBM Bluemix Garage and the Bluemix Garage method.

    I will be chairing a panel at InterConnect too by the way called: DevOps, It Takes a Village. If you are going to InterConnect come say hi!

    As usual below is the streaming audio player, followed by the transcript.

    Alan Shimel:                Hey, everyone, Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m happy to have two people as our guests on this edition of DevOps Chat. I’m joined by two friends of mine from IBM, Chris Lazzaro and Peter Klenk.

    Peter, Chris, welcome to DevOps Chat.

    Peter Klenk:                Thanks a lot, Alan, glad to be here.

    Alan Shimel:                Okay. Peter, why don’t we start off by just giving our audience a little bit of background on your position and who you are at IBM?

    Peter Klenk:                Sure. I’ve been at IBM a while doing a lot of various type things, but as we try to become a cloud company I’ve become the product manager for pretty much everything DevOps in the cloud, so how we promote working, the kinds of tools we’re offering in the cloud and so on.

    Alan Shimel:                And, Chris, how about you?

    Chris Lazzaro:           I’m Chris Lazzaro. I’m the lead architect for the Bluemix Garage Method. The Garage Method is where we try to teach customers how to be successful in the cloud, adopting best practices for DevOps and really act like a startup.

    Alan Shimel:                With scale like in enterprise.

    Chris Lazzaro:           Yep, and meet those enterprise demands.

    Alan Shimel:                Absolutely. Gentlemen, obviously the cloud is not new. It was funny. I spoke to someone the other day and they were with another large provider such as IBM, and they were transferred internally. They said, “Well, yeah, they wanted me to go to IOT and stuff because that’s where all the growth is.” I said, “What about cloud?” He said, “Oh, cloud is old news already. That’s not as strategic anymore.”

    I must admit I was somewhat blown away because everything I’ve seen says while most or the overwhelming majority of organizations have some infrastructure in the cloud, it’s a relatively small amount of their total infrastructure and the greater migration is certainly ahead of us.

    Peter, you are DevOps in the cloud. What are you seeing? Is that true, not true?

    Peter Klenk:                The reality is I think most enterprises have been experimenting in the cloud, doing pilots, doing some innovation projects, but the bulk of the workload in the world is still running in a more traditional infrastructure. We still talk to a lot of mainframe clients. We talk to certainly a lot of on-prem datacenter clients.

    There are kind of two things going on. Getting to the cloud is part of it, but I think the bigger question they ask is: how do we get more efficient, more developer productivity, more team productivity, more essentially rapid innovation, reduce the time to feedback from our clients, so that the systems we’re building stay relevant and don’t get disrupted by all these kind of born on the cloud enterprises, which we see popping up in every industry, like in entertainment, you name it?

    Alan Shimel:                Yeah. Chris, when we talk about Bluemix Garage Method and stuff, there is a certain element of that, right, taking what these startups, these, as Peter said, born in the cloud sort of startups, some of what’s in their DNA and trying to – I forgot the word of the program we use to edit DNA now, not Zipper, but whatever – trying to –

    Chris Lazzaro:           CRISPR.

    Alan Shimel:                CRISPR, you’ve got it – trying to transplant some of that DNA into these enterprises. That’s what you guys spend a lot of your time on.

    Chris Lazzaro:           We are trying to bring that rate of innovation that’s possible in the born on the cloud kind of startups, and then teach everyone how to utilize the cloud in order to get those innovative ideas that are out there as quick as possible, and reduce those barriers from going from idea to production.

    But like you said, there are a lot of enterprises out there where the backend systems of record are mainframes or just data that simply won’t ever be able to move to the cloud, and that’s why hybrid cloud is so important. Some of these new technologies like IOT and cognitive, you can start experimenting with those and still connect them back to your on-premise infrastructure.

    Alan Shimel:                Yeah. You know what? Certainly IBM is going to be the last company that tells you, “You should move off your mainframe.” But you’re right. People aren’t going to move off their mainframe, but that doesn’t mean there are some things that remain on your enterprise mainframe system and some things that are better off in the cloud, and you do have this sort of hybrid, not one-size-fits-all, and you do what’s best for that individual need. Sometimes it is staying back in the datacenter. Sometimes it’s moving up to the cloud.

    Peter, I think you hit it on the head in saying it’s all about improving productivity. If it feels good and if it’s better for the company, then do it – to paraphrase a 1960s thing.

    Of course, gentlemen, this is a big part of the whole Bluemix – not Bluemix Garage Method, but the Bluemix platform in general in the cloud. Correct, Peter? And that is to make developers or make developing more productive and more efficient. Fair enough?

    Peter Klenk:                Yeah, fair enough. I think what Bluemix is has changed since we launched it a couple years ago. I think maybe this is just indicative of what’s happening in the cloud in general, but we started talking about very specific runtime environments and you’re going to run workload on the cloud.

    It certainly is that and Bluemix has infrastructure. It has cloud foundry. It has containers. It has a serverless programming model called OpenWhisk. There are plenty of ways to run your workload in the cloud.

    But it’s also this catalog of services you can use in your application. How is that related to developer productivity? Well, no one is going to build a NoSQL database or a natural language processor or a cognitive sentiment analysis or any of these types of frameworks on their own anymore. You’re going to use services, and that’s a big part of what the platform is, is this rich catalog of services.

    It gives you a leg up in building the application for your domain, leveraging new direction models, cognitive models, IOT-type sensors and feedback systems.

    Alan Shimel:                I think it’s even more than that, Peter. You mentioned NoSQL. No one wants to stand their NoSQL up themselves, their NoSQL infrastructure up themselves. And certainly what we’ve seen with Mongo recently around security issues, it’s nice to know that you have an IBM, right, and everything they bring in the way of security, standing behind your Mongo service that IBM has stood up for you.

    I think that’s a big part of it. Who can afford to really do it right?

    Peter Klenk:                I think that’s something we bring to the table. If you look at our catalog, we’ve got open source-based things. We have third-party things. We have IBM homegrown things, like the whole Watson set of cognitive services. But with them all comes – you know, it’s a foundation of scale and security and global distribution with points of presence around the world, but you need an IBM-scale kind of partner to deliver.

    Alan Shimel:                Yeah. Chris –

    Chris Lazzaro:           So it’s that –

    Alan Shimel:                I’m sorry; go ahead.

    Chris Lazzaro:           It’s that ability to get a small application or a minimum viable product up and running very, very quickly using a platform as a service or a cloud, but then being able to scale it as required and to add those DevOps tools, the management and monitoring tools or deploy it across multiple datacenters with multiple instances. So the complexity can grow as you start gaining customers and being successful with your app.

    Alan Shimel:                You anticipated my question. That was exactly it. Really, that is sort of – because when you look at how most startups operate, they don’t create to scale immediately. It’s not build it and they come. They build it small and as they come they kind of build it bigger.

    I come from that world I should add. I spent 25 years in that world. It just seems to me to be a no-brainer to say, “Geez, if I can partner with someone who can bring me that instant scalability, and not just the cloud infrastructure as a service, but the whole kind of scalability that a Bluemix brings to me, just from a DevOps perspective that just has to make things much easier.” But it’s much more appealing and it’s probably much more economical.

    Peter, agreed?

    Peter Klenk:                Yeah, agreed, and you got to the DevOps point, which is to me is part of that whole cloud picture. It’s the platforms, the services, but it’s also the way of working, which is what the Bluemix Garage Method is all about. Chris can elaborate on that, but it’s meant to be a set of practices that teams will adopt, potentially incrementally. It’s not everything will apply to everyone out of the gate, but it’s kind of the foundation of how effective DevOps teams work. Then we back that up with a set of tools that represent the kinds of tools that support those practices.

    Similarly, everyone needs a place to store to their code, and a way to build it and push it onto a runtime on a platform like Bluemix. But, let’s face it; most of the world has on-prem stuff. They might be dabbling in other clouds. So it’s really deployed multiple places often.

    And for that little startup mentality maybe that’s all you have, but as you grow you’re going to want to add different kinds of testing. You’re going to want to move the code through more environments, to expose it to different kinds of scenarios around performance and scale and security and vulnerabilities. You’re going to want to probably have more rigorous change management policies about what gets allowed into production with what level of review.

    So when we build out the DevOps offering, we’re providing point tools. We’re partnering with point tools. But we’re really focused on how they integrate together and how they can be simple for the teams that really are just starting out, the kind of – I won’t even say two pizza teams. I’ll say the one pizza teams – but then grow up with those teams and then with those whole organizations, where now they’re deploying multiple apps across multiple runtime environments, multiple clouds, and manage the rigor and complexity that comes along with that.

    Alan Shimel:                Agree. Guys, as often happens here, our time starts getting ahead of us or behind us, but I wanted to come back to there is some new news around continuous delivery on Bluemix. I don’t know. Peter, are you the better person to share with our audience or is that a Chris thing?

    Chris Lazzaro:           Well let me set the context first and then I’ll hand it off to Peter.

    Alan Shimel:                Great.

    Chris Lazzaro:           There’s two really key points. One is as we look at DevOps methods and help people define that, IBM’s definition really starts with idea. It’s everything from going from idea to production and then managing and scaling that up.

    So we start off with design thinking, and that’s really important to really get that into your DevOps process. From there it’s all about reducing the barriers of bringing that idea into production, and you want to get rid of all the barriers and friction points. You need not just a platform that can support you, but also a set of tools that enable continuous delivery, so that your developers are curating and getting that right out into production.

    That’s where the continuous delivery service really helps. Peter, do you want to talk about that?

    Peter Klenk:                Sure. We just announced at the end of last year a new service in the Bluemix catalog called Continuous Delivery. It focuses on a few things. One is the continuous integration, continuous delivery pipeline. But another is managing the set of tools and the integrations that a team is going to need to do the whole job around software delivery.

    One thing we find in the enterprise is that it’s easy for a couple of folks to go off and start downloading a bunch of different tools, and getting them to run somewhere and use them like in their little project because maybe they’re motivated to try new stuff, but to then scale the successful patterns across the enterprise is really hard. Not everyone is as motivated. Not everyone wants to do the research to figure out what’s going to work in their environment.

    So in addition to that continuous integration, continuous delivery pipeline, we have this first-class concept called Toolchains that can be captured in templates, so that you can easily provision new teams onto, say, a source repository on an agile plan or an issue tracker and CI/CD patterns that have the right kinds of jobs and environments in them, to give you a way to just quickly bring new teams into this modern world of tools and practices.

    Alan Shimel:                CI pipelines, sure. Peter, if someone is interested in kind of toying, messing, experimenting with Bluemix continuous delivery, do you have to be on Bluemix to do it? Does it have to be on public cloud? Where could they get more information on that?

    Peter Klenk:                They can start reading about it at Bluemix.net/devops. If you have a Bluemix account, you have everything you need to get started. If you don’t, that’s something you can easily create, no monetary commitment. The service right now is free. I imagine it will remain free for small teams that just want to start trying it out. So it is running in the public cloud.

    We do have something called Bluemix Dedicated, which is a single tenant instance of Bluemix for certain enterprises that want that, and the service is also available there.

    Alan Shimel:                So private cloud, is that not in style anymore, Peter?

    Peter Klenk:                I think that’s fair. I think there are different ways to –

    Peter Klenk:                Yeah. The key point here is it’s a single tenant instance, but it’s the full Bluemix stack. So our service is available that way as well. But for tire kickers, go to the public cloud, Bluemix.net/devops.

    If you’re not quite ready for that, Chris, Garage Method. How do you get started over there?

    Alan Shimel:                We’re going to come back to that in a second, before I lose my train of thought, because it doesn’t take me much. Peter, you mentioned the toolchain aspect of Bluemix and the continuous delivery in the stuff you’re putting together. If someone is experimenting or testing the Bluemix continuous delivery, can they add other tools to the toolchain, sort of maybe do a custom integration?

    Peter Klenk:                They can. The pipeline is highly customizable through scripting. There is a set of integrations, the third-party tools available, kind of no box because it’s on the cloud, but virtually out-of-the-box. And certainly then in the applications they’re building, they certainly have access to all the other services in Bluemix as well. So there is some cool stuff.

    Alan Shimel:                Got it. Chris, let me come back to you. We mentioned Watson earlier. I remember last year at InterConnect I was kind of blown away when I realized Watson was going to be on Bluemix. With APIs anyone can hook into Watson. I met some lady who in no time created a custom dating site where Watson was picking your dates for you. I mean I’m married, it didn’t me any good, but it was still an interesting concept.

    But, Chris, when we talk about this Bluemix continuous delivery, does it work with Watson and some of the other services? And is that something we can do with the Garage Method and so forth or no?

    Chris Lazzaro:           The continuous delivery pipeline can definitely work and deploy cognitive or Watson applications. We’ve got a number of examples of those on the Garage Method site. So if you just Google Bluemix Garage Method you’ll get there.

    What’s really neat is that with these toolings and this platform, you can deploy an application that’s making use of the giant Watson cognitive capabilities and then easily tie in your logic to that. So you just plug into Watson as if it was a regular service.

    Alan Shimel:                Excellent.

    Chris Lazzaro:           So we’ve got those courses out there that walk you through it. The other place to get started would be at InterConnect this year. We’ll be having a lot of workshops and training and sessions at the InterConnect conference.

    Alan Shimel:                Let’s talk a little bit about InterConnect. Of course it’s coming up. It’s moved back a little bit this year. I believe it’s in – is it late March now or April?

    Peter Klenk:                March.

    Alan Shimel:                Peter or Chris, you don’t have the exact dates, do you?

    Peter Klenk:                I will in a second. I want to say March 20 –

    Alan Shimel:                Yeah, like March 20 to –

    Alan Shimel:                I know the 22nd is a Wednesday and that was a big thing. I’m speaking there as a matter of fact. I just got all my speaker kit stuff today.

    Peter Klenk:                The 19th through the 23rd at Mandalay Bay in Las Vegas.

    Alan Shimel:                Yes. Guys, we might as well end things off then with an InterConnect question. What are you most looking forward to this year at InterConnect?

    Peter Klenk:                Feedback.

    Chris Lazzaro:           I always love the expo floor and being able to talk directly with the clients and get that feedback and just see the cool things that are being developed.

    The other session or workshop actually that I’m looking forward to is the one around the method, where attendees will actually – by the end of the workshop they’ll have applications up and running in Bluemix that cover all the phases. So they’ll have the tooling plugged in for managing the app and the continuous delivery tools as well.

    Alan Shimel:                Got it. Peter, what about me?

    Peter Klenk:                For me it’s feedback. Last year at InterConnect we were certainly talking about the method and different tooling approaches and we had some previews, but it’s different now that we have our service out there in the Bluemix catalog with real users doing real applications and solving real problems. So I just want to hear from them and also hear some more perspectives from clients and other companies in the business about the trends they’re seeing.

    We’re going to have a couple good panels with some of the other DevOps companies. So that and then clients talking about the kinds of apps they’re building on the cloud is always fascinating.

    Alan Shimel:                I always enjoy talking to clients as well at InterConnect. It’s great stuff. And I will just mention that if you really want to sit in on a great session, there is one called “DevOps: It Takes a Village.” I’ll be hosting that one. I want to say it’s Wednesday at 9:00 AM at Mandalay Bay, but I’ll put more on that at devopsy.kinsta.cloud in the near future. Just a little personal plug guys. I’m sorry.

    Peter Klenk:                Shameless.

    Alan Shimel:                Shameless on me. Anyway, guys, I look forward to seeing you both at InterConnect. We’re actually going to probably have some devopsy.kinsta.cloud surprises there in terms of our coverage. So maybe we’ll get a chance to sit down and chat.

    But for now, Chris Lazzaro, Peter Klenk, thanks so much for being our guests on this episode of DevOps Chats, and we’ll see you in two months or so out in Vegas hopefully.

    Chris Lazzaro:           Sounds good. We’ll see you there.

    Peter Klenk:                Always a pleasure.

    Alan Shimel:    Okay. Chris Lazzaro, IBM Bluemix Garage Method, and Peter Klenk, IBM Bluemix and Cloud Services for DevOps, thanks for appearing on DevOps Chats. This is Alan Shimel of devopsy.kinsta.cloud hoping to see you on another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Ken Cheney, Chef on AWS OpsWorks for Chef Automation

    DevOps Chat: Ken Cheney, Chef on AWS OpsWorks for Chef Automation

    devopsy.kinsta.cloud catches up with Chef’s busy CMO Ken Cheney. Ken give us the inside look at AWS’s OpsWorks for Chef Automate. While this is an AWS offering it is based on Chef and is a pretty big bet by AWS on Chef. In addition Ken brings us up to speed (pun intended) on other things regarding Chef. Ken is always a great person to chat with and full of great info. We are going to have Ken on every month or so, we can count on hearing more Chef and DevOps talk soon.

    In the meantime, as usual the streaming audio of our conversation is below and the written transcript of our chat follows. Enjoy!

    Streaming Chat

    Transcript

    Alan Shimel:                Hi, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I am happy to be joined in this episode of DevOps Chat by Chef CMO, Ken Cheney.

    Ken, welcome.

    Ken Cheney:                Alan, nice to hear your voice again.

    Alan Shimel:                Nice to hear from you, Ken. Actually, I think the last time you were on our podcast or the last time we spoke you had maybe just been appointed CMO, or maybe it was even before you were appointed CMO at Chef, but it’s certainly been a busy time for you I’m sure.

    Ken Cheney:                Yeah, it has. There’s been a lot going on in the past two months and some of it we’re going to talk about today, the work we’ve been doing with AWS.

    Alan Shimel:                Yeah. I think the last time I spoke to you was right before AWS re:Invent, and there was some big Chef news coming down the pipe that we weren’t able to talk about then. It was still kind of under embargo, but it certainly is fair game now.

    So, Ken, why don’t you share with our audience what was big for Chef at AWS re:Invent?

    Other Great DevOps Chats to listen to:

    DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey
    DevOps Chat: Huw Price, Smart Automation Is Key
    DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps
    DevOps Chats: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    Ken Cheney:                First off, AWS re:Invent, a super-impressive show to go to. So if folks haven’t gone, I’d recommend this next year that they pencil it in. But at re:Invent we announced – actually AWS announced, it’s their offering, a new offering called AWS OpsWorks for Chef Automate. It really brings for the first time the full capabilities of Chef’s commercial platform to AWS as a managed service offering. So they provide support and they backup the offering 100 percent.

    So it’s a new offering that makes that job of configuring, deploying, scaling, both in the cloud as well as on-premise infrastructure simple and secure. We get there by really doing what Chef has done best over the years, which is automating infrastructure as code.

    I think to really highlight what I said, Jassy at re:Invent went out of his way to make the point that hybrid is the new normal in their view. So what’s interesting about what we are doing with AWS is you can manage both in the cloud with AWS as well as your on-premise workloads, and you can have that consistency in how you manage your resources across both.

    Alan Shimel:                Absolutely. Now, Ken, our audience may not be aware, but I happen to have known this, that Chef was sort of the dominant tool in use for AWS customers now for a few years; I mean an outrageous amount. If I’m not mistaken, wasn’t it like 65 or 70 percent of AWS customers who use some CM are using Chef?

    Ken Cheney:                Yes. A large proportion of AWS customers use Chef, and AWS themselves use Chef for many of their core services. It’s a platform that is really well suited to the job of: how do you get your workloads to the cloud, and how do you manage those workloads on an ongoing basis in the cloud?

    Alan Shimel:                Absolutely. And of course, Ken, when we talked about hybrid – I actually had a conversation yesterday, actually with maybe some IBM folks. We were talking about mainframes aren’t going away any time soon, obviously, the mainframe market. It’s probably bigger than ever in terms of dollars.

    But the idea of working with your systems of record and systems of engagement, and one is on a mainframe and one is in the cloud, is becoming more and more the norm for large organizations, right?

    Ken Cheney:                Yeah. It really is.

    Alan Shimel:                Yep. I mean they’re not going to just walk away from billions of dollars invested in mainframes and datacenters, but in order to compete with stuff that lends itself to it, it’s hard to beat the economics of the cloud. So for the foreseeable future anyway, probably the rest of our working lives, Ken, hopefully, hybrid cloud is going to be the dominant form there.

    Ken Cheney:                Right. Then if that is the case, then manageability and that kind of consistency in your manageability becomes front and center, and that’s where Chef plays a big role in being that bridge that really allows you to have a platform where you can store those configurations in one place, where your resources are going to work perfectly every time at scale, and you make changes in that single place and propagate those changes across those environments. So whether you’re running under a mainframe environment or you’re doing dev, test, prod in the cloud you get that repeatability.

    Alan Shimel:                Absolutely. Before we leave the AWS stuff though, Ken, I just want to, for our audience that may be interested, this is available now, today, through the AWS marketplace?

    Ken Cheney:                No. It’s a core AWS offering.

    Alan Shimel:                Okay.

    Ken Cheney:                So if you’re an AWS customer, you login through the AWS console and it’s one of the offerings that you can select. So it bills through AWS. It’s managed by AWS. It’s supported by AWS. So it’s very easy if you’re an AWS customer to get started, and you can get started for free, up to ten nodes for free per month.

    Alan Shimel:                Great.

    Ken Cheney:                Yeah. You can get started and get all those advantages.

    Alan Shimel:                That’s cool. All right, so people can go check it out right now. If you’re using AWS, it’s a core offering. And I guess that kind of makes sense because it is an AWS offering after all, isn’t it?

    Ken Cheney:                That’s right. We’re partnering very heavily with them to make sure it gets the kind of traction and success that we have envisioned.

    Alan Shimel:                You know what? That really is big news, Ken. Great job by the Chef people. Give my kudos to the business development guy. He did a hell of a job there.

    Ken Cheney:                Will do. Thanks, Al.

    Alan Shimel:                Weren’t you the business development guy, Ken?

    Ken Cheney:                I was. I’m weird, so –

    Alan Shimel:                Yeah, I know, just a little inside Chef joke. Ken, we talked a little bit about hybrid cloud and this new offering at AWS. Let’s look at the bigger picture. Here we are in January of 2017 and it’s not too late yet for – where do you see DevOps in 2017? Where do you see Chef in 2017? What big picture item should we be looking at?

    Ken Cheney:                What’s interesting right now in the market is that – you and I both see this, Alan – the market is still very young. I saw some Gartner data where you can extrapolate out that 90 percent of the market is still untouched. Even that 10 percent that has started down the path of adopting is only partially adopting.

    Yet what’s very clear, both at an industry level, if you look at industry data, as well as what we see with our own customers, is that DevOps has a significant impact on the bottom line. Companies that adopt DevOps have been shown again and again to outperform their competitors.

    Alan Shimel:                Yep.

    Ken Cheney:                And I think that DevOps – we’ve been talking about this for some time – but it’s really a full-on move from the early adopters, those organizations who figured out how to be disrupters, to the rest of the market who are being disrupted.

    Alan Shimel:                Yeah. It’s DevOps or die, as I like to say.

    Ken Cheney:                That’s a great statement.

    Alan Shimel:                Yep. Ken, I saw some interesting statistics from a study that CNA had commissioned, 1,700 respondents, and it said something like only 34 percent, so just a third of organizations had adopted DevOps.

    Ken Cheney:                Right.

    Alan Shimel:                Which to me and probably to you too, right, because how many organizations do we talk to that either haven’t adopted DevOps or don’t want to adopt DevOps? We live in a DevOps bubble. We think everyone does, but yet the fact is it’s only about a third, 34 percent. When you look at it that way, it’s barely mainstream, right?

    Ken Cheney:                That’s right. And even those who have adopted it typically adopted it in a small silo.

    Alan Shimel:                Right, the pockets of DevOps, as they call them. I continually refine that, Ken. What I mean by that is you’ll have a team – a team – using DevOps, maybe a team here and a team there, but only when those multiple teams come together under a common DevOps sort of processes, framework, manager, whatever, do I really consider the organization doing DevOps. So for me, an organization that’s doing DevOps is doing it with multiple teams.

    Ken Cheney:                Yeah. I totally agree, and I think this is the year where we start to see organizations really at an executive level begin to put their shoulder into what that means. How do you actually begin to go automated scale?

    And at the same time they’re going through the tech modernization investments around embracing the cloud, embracing microservices, containerization. So I think this is going to be a really interesting year, where I expect many traditional shared services organizations are going to be under a lot of pressure to change.

    Alan Shimel:                I agree 100 percent. It goes back to the DevOps or die thing. All kidding aside, if these organizations don’t change you’re going to start seeing them falling by the wayside.

    But you know what else I think, Ken, and I’m interested in your opinion on this. DevOps tools have to change, too. They have to continue to mature. They have to continue to be enterprise-ready. They have to continue to deliver and meet the challenges that organizations are faced with.

    Ken Cheney:                I totally agree. I think that there’s been a Cambrian explosion of tooling.

    Alan Shimel:                Yes. That’s a great phrase for it, a great way to put it.

    Ken Cheney:                Yeah. And there’s been a rapid kind of organic team level adoption, but what’s happening is that there’s been a lack of standardization, a lack of scale. When you look at the disrupters who have been wildly successful, and many of those are Chef customers, they have been successful automating at scale. Automating at scale means you do drive consistency across the board.

    The path to get there though, from my view, is you have to be thinking about vertical integration. If you look at our strategy, like take what we announced at AWS, that is where we are actually vertically integrating into their platform in a very real, meaningful way. And we feel the same way about the broader ecosystem of _____ capabilities that we need to integrate in with, to make that job of automating at scale easy.

    Alan Shimel:                Yeah, agreed. I do think you’re onto something with that, also vertically integrating, but it’s also integrating into the IT stack. For instance, for me and maybe it’s my own personal bias and history, if you look at 2017 as a year where we have to see security integrating with DevOps and we can call it DevSecOps or Rugged DevOps – I don’t really care what you want to call it – but there has to be that tighter coupling, that tighter integration into the IT stack of security shifting left as part of this DevOps.

    I know Chef obviously has now some history in trying to bring compliance at scale and compliance in security and speed. But I think that has to accelerate.

    Ken Cheney:                Yeah, it does. We are pouring the investment into that set of capabilities. When we look at what our customers are trying to get done, there are things like driving known vulnerabilities down to nothing, being able to remediate in minutes as opposed to days. To get there, that concept of shift left that you put forward is front and center. You have to start thinking about shifting risk to the left.

    So we’ve invested a lot in, one, our InSpec open source framework that people should go check out, as well as the overall compliance capabilities, where you can have broad compliance profiles that ensure that the state of your infrastructure and applications is conforming to policy.

    Alan Shimel:                Got it. You know what, Ken? You mentioned open source and it triggered something. What’s happening with Chef Habitat, anything new you can share with the audience?

    Ken Cheney:                Yes. Chef Habitat has been in the market now for about nine months. We have been seeing a tremendous amount of traction. We’re going to be launching a Habitat road show in a few weeks, visiting multiple cities. So people should go to the Chef website and see if we’re going to be coming to a location near them.

    We are really now moving into the phase where we have large enterprise customers moving workloads into production with Habitat, and they’re really targeting that job of: how do I easily encapsulate my applications and manage those applications, in a way that I don’t have to spend a lot of calories worrying about extraneous services and getting true portability out of it, meaning I can move that application workload anywhere I want?

    So Habitat is definitely getting legs at the moment. We’ve had some new product news that will hit in a couple weeks, Alan, so you and I will be talking about that.

    Alan Shimel:                Fantastic. All right, a little teaser. Ken, to tell you the truth, we’ve gone way over our usual time that we allot for podcasts. We don’t want to take up too much of people’s time, but let me just do a quick recap. For people who want to find out more about Chef Habitat, what’s the URL?

    Ken Cheney:                They go to the website, which is Habitat.sh or they can go to the Chef site, which is Chef.io.

    Alan Shimel:                Right, and it’ll just run through from there and they can find out about the Habitat road show there. The Amazon stuff you can get right through your Amazon portal or dashboard, if you’re an AWS user.

    Ken Cheney:                That’s right. AWS just did a webinar yesterday that was recorded that does a nice walkthrough on it. So they are actively out there promoting it and pushing it for their customers.

    Alan Shimel:                And the open source compliance and security?

    Ken Cheney:                You can get that through the Chef website.

    Alan Shimel:                Also.

    Ken Cheney:                Yep.

    Alan Shimel:                Okay. I just want to make sure people get it, Ken. Ken, we could probably spend hours talking. We’ll have to have you back on soon, maybe in a few weeks when you have your next bit of news. But until then, keep up the great work. Oh, we should mention ChefConf.

    Ken Cheney:                Oh yeah, ChefConf coming up May 20th to 22nd in Austin, Texas. People can go and register today. We’re pretty excited. We just closed the call for papers last night and had a record number of submissions. So it’s going to be a great event.

    Alan Shimel:                Cool. I went last year. It was a great event. I had a great time. It was some great content. The Alaskan Airlines was still my favorite, Ken. Actually it got me to fly Alaskan Airlines watching that guy present.

    Ken Cheney:                It was amazing, yeah.

    Alan Shimel:                It was the first time I ever flew them, and I was counting to see how quickly the door closed and how quickly they opened it, from his whole presentation. It was a great one.

    Anyway, Ken Cheney, CMO Chef, thanks for being our guest on this episode of DevOps Chat. Continued success at Chef and we’ll be watching and listening to find out what’s new.

    Ken Cheney:                Thank you, Alan.

    Alan Shimel:                All right. Okay, everyone, this is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening and we’ll see you on our next DevOps Chat.

    — Alan Shimel

  • Illumio Extends Adaptive Security Platform for More Comprehensive Protection

    Illumio Extends Adaptive Security Platform for More Comprehensive Protection

    Networks often are complex and expansive. It’s easy to think of them as a singular entity, but the array of devices that interconnect, route and segment the network can make monitoring and managing security a challenge. Illumio hopes to address that challenge and help organizations implement security that is simultaneously easier and more comprehensive with changes to its Adaptive Security Platform.

    According to Illumio, the Adaptive Security Platform is being extended to enable companies to embrace network segmentation for data centers and cloud applications without sacrificing security.

    “One of the biggest challenges in security is battling complexity and that’s amplified by increasing heterogeneity that we see in customer data centers and cloud environments. Legacy infrastructure combined with virtualization and cloud means there is opportunity for coordinated points of policy enforcement,” said Eric Hanselman, chief analyst of 451 Research. “We see segmentation in depth addressing a real requirement for customers who are looking to both strengthen security and simplify operations by centralizing and harmonizing policy and enforcement across different environments.”

    “As segmentation becomes the core strategy for data center and cloud security, organizations are now looking at how other elements of their compute environment can be used to enforce these policies,” said PJ Kirner, chief technology officer and founder of Illumio. “Our customers have asked us to efficiently coordinate policy across their data center and cloud environments, simplifying management of the security control plane.”

    Illumio shared some of the big features included in this update:

    • Illumio can now program and control leading data center and cloud infrastructure—including Cisco Systems, Microsoft Azure, AWS and Arista—to deliver the most comprehensive segmentation solution in the market.
    • Customers no longer need firewall chokepoints, SDN deployments or upgrade infrastructure to achieve robust segmentation-based security.
    • The expansion of Illumio’s enforcement point programming gives customers a centralized and automated coordination of policy management between:
      • Hosts: Workloads (bare-metal, VM, containers)
      • Network: Cisco and Arista switches (NEW), F5 LTM & ATM
      • Public Cloud: AWS Security Groups, Azure Network Security Groups
    • Customers can now write uniform security policies for hosts, the network and public cloud, improving security and reducing operational overhead.
    Illumio-ASP-Architecture
    Illumio ASP architecture

    With the extension of Illumio ASP from bare-metal servers, virtual machines and containerized host to include additional security controls for the network and cloud, Illumio states that it reduces the need to manage multiple, disconnected policy models. Illumio claims that it helps eliminate security gaps generated by disparate security policies, reduces the operation overhead created by manual segmentation and stops the need for additional firewall chokepoints or SDN deployments.

    “Despite the rapid increase in cybersecurity spending focused on implementing stronger security controls to limit access to sensitive data and applications—organizations of all sizes don’t always end up with more secure environments,” said Jon Oltsik, ESG’s senior principal analyst and founder of the firm’s cybersercurity service. “The ability to drive segmentation in depth throughout the data center and cloud can be a critical next step in securing data center and cloud environments.”

    — Tony Bradley

  • 3 Key Uses of a DevOps Toolchain

    3 Key Uses of a DevOps Toolchain

    DevOps toolchain infographicThe ultimate goal of DevOps is to streamline development. DevOps doesn’t necessarily require tools and is not defined by its tools, but for most organizations, they play an integral role in automating tasks and ensuring processes run as efficiently as possible. When used together, a combination of DevOps tools form a DevOps toolchain, which enables teams to flow smoothly through the DevOps life cycle.

    While the integration of DevOps is by no means ubiquitous, we’re witnessing its growing presence in the mainstream IT world. A plethora of tools and systems has emerged to facilitate continuous build, test, release and deploy, but constructing an effective DevOps toolchain to run efficiently can be a tricky undertaking. It often requires a good deal of experimentation and continuous refinement to ensure that critical processes and hand-offs are effectively automated.

    While the specific tools and systems you utilize will depend on your organization’s unique needs, it’s helpful to keep three key uses of a DevOps toolchain in mind to guide your planning and organization. Let’s take a closer look at the primary ways that an organization can benefit from a DevOps toolchain.

    1. Resolve Product Defects. The first use for a DevOps toolchain is to help resolve individual product defects more efficiently. Automation enables you to generate dependable, targeted alerts to your team about major IT incidents. This can not only improve the speed with which you resolve issues, but also help to proactively sidestep potential problems from escalating and damaging your customer experience.

    2. Refine Incident Management. The second way to use your toolchain is to further refine your management of major incidents and to facilitate the rapid and automatic progression from pinpointing critical events to escalating targeted communications to the right team members and following through until the issues have been resolved. It’s especially important that communications are delivered only to the appropriate team members—mass notifications, particularly to teams of hundreds or thousands of personnel, are ineffective and don’t do anything to combat alert fatigue.

    3. Innovate Faster. Finally, remember that your toolchain is meant to help you innovate faster by driving continuous build, test, release and deploy. Combining monitoring, diagnostics and continuous testing can help your organization ensure rapid delivery and follow best practices for agile development. Decentralized version control, for instance, is used by 85 percent of software organizations because it can help streamline the development process tremendously.

    Which tools are best for you, and which combination of tools will work best for your DevOps toolchain, is a subjective exercise. Regardless of the tools you use, though, it’s clear that there are benefits for organizations that put together an effective DevOps toolchain that can help streamline and optimize the life cycle from beginning to end.

    — Tony Bradley

  • DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

    DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

    I had a chance to sit down recently with Nigel Kersten, chief technical strategist at Puppet. Besides the fancy title, Nigel is one of the smartest, nicest people you will meet. Always a pleasure catching up with him. We spent most of our time speaking about the Puppet 2017 DevOps survey, which is now open right here.

    We also spoke about some of the findings of the past five annual DevOps surveys and the DevOps space in general. Great, informative conversation. As usual, the streaming audio of the our chat is below, followed by a written transcript. But please remember to take the 2017 DevOps Survey. Enjoy!

    Alan Shimel: Hi, everyone, Alan Shimel, editor in chief, devopsy.kinsta.cloud here, for another DevOps Chat, and today’s DevOps Chat guest is none other than Nigel Kersten, chief technical strategist at Puppet. Nigel, welcome back.

    Kersten: Hey, Alan—thank you. It’s great to be back, and always good to talk to you.

    Shimel: Absolutely. Nigel, you know—well, first of all, it’s always great to have you on the show, and we’d love to have you on as often as we possibly can, but specifically today, I wanted to talk a little bit about—it’s that time of year again where Puppet will be launching their, the annual DevOps survey, and I wanted to spend a little time talking about it and cluing our audience in, into what’s in store for this year.

    Kersten: Absolutely. Always happy to talk about the survey. So I think, you know, this has been—we’ve been running this for quite a while now, this is now the sixth year. And I think one of the things that’s really fascinating about the survey is, we survey generally technical practitioners, but also managers as well. But, in the course of surveying all of these practices and technical behaviors and how teams communicate with each other, we end up coming to a bunch of really great conclusions around the actual business outcomes.

    And this is why I think it’s so important for people to be going out and filling out this survey, because I see customer visit after customer visit, every time I’m out there on the road, so many people come up to me and say, “We’ve been trying to change the way we work inside our company, and your surveys turned out to be a really useful tool for handing to our senior management, and saying, ‘This is the sort of outcomes we can expect if you let us work the way we actually want to work.’”

    Shimel: Yes. And you know what, Nigel, just a little bit of a frame of reference, I got the number while I was at Gene’s last DevOps Enterprise Summit in San Francisco, but I was speaking to Nicole, Dr. Nicole Forsgren. What was the total—you may not know—but the total amount of people who have taken this survey at this point over the past five years?

    Kersten: There are actually over 25,000 people, which I think is fantastic, and particularly even in the first few years, we’re definitely really focused on the sort of North American market. We’ve been seeing this growing more and more in Europe, in Asia, and we’re starting to see that, really, DevOps has become a global movement and is being recognized as such within the enterprise, not just sort of the, you know, webscale hacker groups.

    Shimel: Yeah. Well, that’s certainly for sure. And Nigel, this year, is Dr. Nicole—well, they’ve actually started a company now around DevOps statistics and research.

    Kersten: Yeah, so we’ve been working with Dr. Nicole Forsgren and Gene Kim, who many people know from the author of, “The Phoenix Project,” and ex-CTO of Tripwire, and the inimitable Jez Humble, who many people know from his Lean Enterprise and Continuous Delivery books. We’ve been working with them for about the last four or five years and, yeah, this year they’ve formed a new company called DORA—DevOps Research and Assessment—where they go in and help companies do benchmarking around their actual sort of DevOps practices.

    Shimel: Yep.

    Kersten: And so I think that combination of industry experience, great sets of contacts, and really, the statistical rigor that people like Nicole actually bring to this—

    Shimel: Exactly.

    Kersten: —make this to be much, much more than just a vendor survey. Because it’d be easy for us at Puppet to just survey the Puppet user base and come to a bunch of conclusions. But I think the really interesting fact is when we get to talk to people—more people than are just using Puppet, people across the whole industry, some people who are just coming to DevOps for the first time.

    Shimel: Sure.

    Kersten: So I’d really highly encourage anyone who’s listening, you know, go out and fill out the survey when we launch next week, and don’t just feel like, “I don’t really know very much about DevOps, I shouldn’t fill out the survey.” We’re really looking for input from people all across the spectrum.

    Shimel: Absolutely. And of course, Nigel, by the time people hear this, it will be next week, and we will include the URL in the show notes so that people can click right out of this article to the survey.

    Kersten: Excellent.

    Shimel: Nigel, I don’t know if you would know this, even, but is there sort of a shortened URL that people can look for, to go to?

    Kersten: Yeah, we’ll give you a shorter URL by the time we actually launch this podcast out.

    Shimel: Okay. Not a problem. We’ll put that in there. So Nigel, six years in, though, if you’re not moving forward, you’re dying, right? [Laughter] As they say. What’s different about the survey this year?

    Kersten: Yeah, so I think we’ve really shown, over the last few years, that there’s a couple of practices that have really been formalized when it comes to DevOps enterprise adoption. We’ve seen that things like version control being heavily used in operations teams and that infrastructure being shared with your development groups, we’ve seen the role of continuous delivery and lean product management practices. So we really feel that, over the last four or five years, we’ve really shown a bunch of this stuff, that it really isn’t changing very much.

    So we’ve switched focus a little bit this year. So one of the interesting things we’re really looking at are the role of infrastructure architecture patterns in DevOps environments. And I don’t just mean, you know, “Are you adopting containers, are you doing macroservices, service-oriented architecture?” But we’re really looking for information on, architecture-wise, in terms of the way your application is set up, is your team self-sufficient and autonomous? Can you make changes quickly on your own, without lots of dependencies across the organization, and can you experiment really quickly?

    Because I think we’ve seen from Agile and from all of the DevOps enterprise movements over the last few years that the ability to do small tests and iterate quickly on the results of those tests to set your larger direction is really critical to both advancing your service, but doing so quickly and more reliably. Because I think that’s been one of the really huge sort of new things for senior management who haven’t been so familiar with these practices to realize is, adopting DevOps practices doesn’t actually mean sacrificing quality for speed or vice versa. It actually means you’re producing better, high-quality software more quickly.

    Shimel: Absolutely. So, Nigel, as I think you mentioned, this week, or the time people are listening to this, the survey will be open. Just in terms of time frames, how long will it be open and when do you think people might start getting a look at some of the data in the report?

    Kersten: Yeah, so we should be launching later on in the year as far as the results go. We tend to leave it open for at least a few weeks. Some of that sort of depends upon, you know, making sure we get a sufficiently large statistical base to get the conclusions that we’re actually looking for. So, the faster people want to see the results, the faster we want to see them fill out the survey. So, basically, head off and go and do it now.

    Shimel: Right. [Laughter]

    Kersten: As soon as we get that critical mass of data, we’ll be launching the results. So you’ll see us talking about this at Velocity, at the DevOps Enterprise Summits and a bunch of the different events happening.

    Shimel: Oh, I’m sure, I’m sure—looking forward to it. And being written about on devopsy.kinsta.cloud, I might add. [Laughter]

    Kersten: Absolutely.

    Shimel: For sure. So, Nigel, if you were king for the day, you know—

    Kersten: Okay.

    Shimel: —what would you, you know, and you looked into your crystal ball, what would the headlines be from this year’s survey?

    Kersten: If I looked into the crystal ball, what I would really like to see is that we’ve drawn some really strong conclusions around the benefits of DevOps practices in the public sector and in nonprofit organizations, because that’s been a constant source of feedback for the last few years, that we’ve managed to draw really great conclusions for profit-oriented companies.

    But I think we’ve also seen, with the rise of the U.S. Digital Service in the U.S. and .gov.uk that’s been running for quite a long time in the UK and the Digital Transformation Office in Australia—we’re really starting to see some of these practices start to be applied to the public sector. And, honestly, that’s in all of our interests, for government infrastructure to work more efficiently and deliver better services that progress more rapidly to all of us.

    So that’s something I would really, really love to see, that we can draw those conclusions, which I’m feeling pretty optimistic about. But I think the big headline I would like to see, continuing that thread of, “How do we make sure that the survey and the results in the report that we’ve come out with are useful for practitioners selling upwards in their organization, as well as senior leaders trying to implement change?” is—give your teams more autonomy. Make sure that you’re designing your infrastructure in such a way that they can test on their own, that they can rapidly experiment on their own, and that you can actually progress things much, much faster than we’re you’re needing lots and lots of meetings just to create major changes.

    So the more we can actually absorb the lessons of service-oriented architecture, and not just create a mass of complicated services, but create clusters of services that teams can work on with a high degree of autonomy and flexibility. That’s really the headline I would love to see—teams that are able to experiment and are autonomous will produce better results for the business.

    Shimel: Absolutely. Nigel, let me ask—go off on a little bit of another tangent, here. You know, one of the things that I kinda, I find fascinating and I tend to come back to and I get as much of as I can is the Project Blueshift stuff that you guys do at Puppet. Gareth Rushgrove is deeply involved in it. And while, today, you know, there’s certainly a strong container focus on it, it really is about sort of future-proofing Puppet, right, and making sure that the folks at Puppet are aware of, you know, what’s the next big thing coming down.

    What can we look for in the survey that may give us a clue in terms of what is the next big thing and hence, you know, something for Blueshift to be aware of?

    Kersten: Yeah, so I think we’ve generally tried to stay a little bit away from stuff that’s too vendor-specific research for us. But I agree—so you’ve totally captured what Blueshift is about for Puppet. It’s very much about us making sure that, you know, Puppet’s a highly successful project, you know, and used by tens and tens of thousands of companies across the world.

    But we’re in a very fast-changing technology landscape right now and I think it’s really critical for us as a company to make sure that we’re not just resting on our laurels there. We’re seeing lots and lots of things change. It’s entirely possible that, in 10 years’ time, everyone will be on completely serverless infrastructure, so to speak. And, you know, you might have been able to hear my air quotes somewhat around serverless, because there’s always someone’s servers running that code somewhere.

    Shimel: Right. [Laughter]

    Kersten: That old saying that the cloud is just someone else’s server.

    Shimel: Uh huh.

    Kersten: And I think, really critical for us, we’ve seen that Puppet, the language, has been an incredibly portable model. We started off in the UNIX and Linux space, and it’s proven to be hugely successful in the Windows space for a lot of our enterprise customers, and people really like having that common language describing all of your infrastructure. And we see no reason why, just as you’ve seen the Puppet container build stuff that we’ve done, that we can use the Puppet language to describe and compose containers and maintain that audibility.

    We can also describe all sorts of infrastructure, no matter where things come from. So, for us, Blueshift is very much about keeping that eye on the sort of next level horizon over the next six to 24 months, and just seeing what’s emerging and making sure that Puppet stays agile and that we start baking in the features to Puppet the language and the platform that will enable us to all take advantage of those things.

    Shimel: Sure. And I—

    Kersten: I think it’s really exciting. I don’t think we’ve seen infrastructure technology change as fast as this, ever.

    Shimel: It’s crazy. And, you know, I don’t know if it’s the gadget boy in me or, you know, I’ve lived in tech for so long, but it’s that—it’s not even a Puppet thing to me, Nigel, it’s a thing. What is the next thing? I think it’s a little bit of how I got into DevOps, it’s a little bit of how I got into computers and technology to begin with. So I’m always interested and curious.

    Kersten: Totally.

    Shimel: And sometimes, you know, the nice thing about this survey is, it does cast such a wide net of responses that you—

    Kersten: Yeah. And I wanna make sure that people don’t feel too left out as well. Because, you know, I often talk to people who are in big enterprise environments, managing important legacy applications, and some of them are still struggling with getting relatively basic principles adopted—of just using version control, using infrastructure as code.

    Shimel: Mm-hmm.

    Kersten: And sometimes you talk to them and they get a little demoralized, going, “You know, everyone’s talking about all this cool technology out there, and we’re not actually getting to use it.” But I think the reality is, most enterprise environments, the software they’re running is delivering actual business value, and it’s important to keep making sure that’s as efficient as possible.

    We saw from the “DevOps Handbook” that Gene and Jez and all of those people are involved in that you can apply these principles to mainframes, you know? You can see people taking incredibly legacy technology, applying these modern ways of working to them, and getting really, really huge benefits.

    Shimel: Got it, got it. Nigel, we’re almost out of time, unfortunately. You know, we can talk all day, but people only listen, it’s the curse of the modern, you know, the 10-minute or the 10-second sound bite and the 12-minute podcast—but first of all, good luck with this here survey. You know, I encourage anyone listening to go, please click on the link and fill out the survey. Can’t wait to see what some of the results are this year.

    Continued good luck with Puppet, too, as you guys are really, you know, coming out of Puppet Conference and meeting with Sanjay and some of the exec team, I was very excited about the possibilities, and I’m sure you are more than me—

    Kersten: Absolutely.

    Shimel: —about, you know, what’s on the horizon here for Puppet, so good luck with that as well. And thanks for being our guest on DevOps Chat.

    Kersten: No problem, Alan. It’s always great to catch up with you.

    Shimel: Okay, my friend. Nigel Kersten, chief technical strategist at Puppet, thanks for appearing on this DevOps Chat, and thanks for telling us more about the upcoming devops survey, or sixth annual devops survey from Puppet.

    This is Alan Shimel for devopsy.kinsta.cloud. Have a great day.

    — Alan Shimel