Category: Features

  • Building a Bridge from Agile to DevOps, Scrum.org Partners with the DevOps Institute

    Building a Bridge from Agile to DevOps, Scrum.org Partners with the DevOps Institute

    Scrum.org, which is dedicated to improving the profession of software delivery, and the DevOps Institute, which is dedicated to fostering a community around emerging practices in Continuous Delivery and DevOps, today announced an alliance that seeks to build a bridge from agile to DevOps. It will include scrum teams, agile practices and DevOps. I think this partnership could have huge implications for both the Agile/Scrum and DevOps communities.

    Let me say from the outset that I am a co-founder of the DevOps Institute, so feel free to take what I am saying (or writing) with a grain of salt. I also have been involved in the formation of this partnership since its initiation. From then until now, I remain convinced that this is a critical step in making software development and delivery better for us all.

    My fellow co-founder at the DevOps Institute, Jayne Groll, perhaps says it better: “There is an inherent organic relationship between Scrum and DevOps. By demonstrating how to improve the collaboration, integration and communication between IT’s roles, frameworks, practices and automation, we pave the way for end-to-end organizational agility and a faster flow from idea to value.”

    While formulating this partnership, I have had the chance to meet and work with some incredible people over at Scrum.org. One of them is Dave West, CEO of Scrum.org. When I first met Dave (you can hear a podcast of that here), he was just formulating his ideas around Agile/Scrum and DevOps being intrinsically linked. Since then, Dave has seen a clear path for this linking and has embraced and enunciated it well. “Scrum without DevOps is impossible to scale. Work needs to flow seamlessly from the Scrum team to production and back again,” Dave says. “It is funny that great Scrum teams have to do DevOps to be great and great DevOps teams use an agile approach like Scrum to enable better collaboration.”

    For me, the real value of this partnership is, as Dave so eloquently states: “I am always shocked that the DevOps community are often seen as different from the agile and Scrum communities, when the reality is that agile and DevOps encourage breaking down those barriers to deliver customer value.”

    At the end of the day that is really what this is all about. The partnership is not just about Scrum.org and the DOI as institutions & organizations—the partnership really has to be about the community of IT professionals who adhere to and practice Agile/Scrum and DevOps.

    As I like to tell people, there is only one truth. There is not a separate set of facts that apply to Agile/Scrum and another set that apply to DevOps. There is not a separate truth that applies to enterprises and another truth that applies only to startups. There is only one truth. If it is truth, it is true. I look forward to this partnership illuminating and standardizing on this one truth.

    By the way, this alliance is just the beginning. I believe that this “one truth” philosophy applies beyond Scrum and DevOps. I think it also applies to ITSM, security and other IT disciplines. Bringing together a common set of best practices and way of doing things across these is inevitable.

    We have crossed a boundary in IT. As I write this, I am at the InfoSec World conference in Orlando. My friend Rich Mogull is delivering a keynote where he is talking about how infrastructure as a service, software as a service and the new reality of ubiquitous, safer endpoints and connectivity are changing the mission of the security professional. These same factors are changing the mission of the Agile/Scrum developer and the DevOps team member. It is a great time to be in IT.

    But it also calls for forward-thinking organizations to recognize, adopt, adapt and evolve. I think this is a great opportunity for organizations like Scrum.org and the DevOps Institute to help lay out a path for common learning and uniting communities. That is what really gets me so excited about this partnership.

    So what are ways for you to find out more and be involved in this? Well, it starts  April 26 in Dallas at the DevOps Connect conference. Dave and Jayne will be delivering a joint keynote and a full afternoon workshop. These sessions will be listed under the “ScrumOps” moniker. If you are in Dallas or can get there to attend DevOps Connect, please do so.

    Dave’s blog lists some other ways this partnership will work together:

    • Consistently describe the ideas of each body of knowledge through Scrum.org and DevOps Institute classes and certifications – providing consistent words and concepts to help ensure that both groups can share a common dialogue.
    • Shared events that bring together the two audiences to create an environment that allows ideas to be exchanged and new ones to grow. It has always seemed odd that DevOps and Scrum/Agile events are separate. It is crucial that the two groups work together and that we as one.
    • Invest in a growing body of thought leadership. Scrum has a very precise, documented body of knowledge with the Scrum Guide, but there is much ‘mystic’ in the DevOps and agile community about certain terms and ideas. DevOps Institute is already working with DevOps Express on building standard patterns and terminology. By working with the DevOps Institute, we can start bringing in the concepts of professional Scrum so that the entire software delivery team can work together as one.

    So stay tuned for more info on this partnership in the coming weeks and months. In the meantime, today is the first day of Scrum/DevOps working together in ScrumOps.

    — Alan Shimel

  • BrowserStack Offers Free Microsoft Edge Browser Testing

    BrowserStack Offers Free Microsoft Edge Browser Testing

    Testing is a major element of development. Without effective testing, you’re essentially releasing beta software and forcing your customers to be the guinea pigs in discovering any flaws or issues. But Microsoft is making it easier for developers to test how things behave and execute within the Edge browser, thanks to a new partnership with BrowserStack.

    BrowserStack provides live, web-based browser testing with access to all variations of mobile and desktop browsers across all operating systems and platforms. The company claims to offer more than 1,100 desktop browser variants, including the latest versions of Internet Explorer, Edge, Chrome and Firefox on its cloud-based infrastructure.

    BrowserStack is free to open source projects, but commercial use of BrowserStack generally requires a subscription. It offers plans as low as $12.50 per month for freelancers and $2,499 per month or more for larger enterprise teams. However, for the Edge browser, BrowserStack testing is now available for free, thanks to Microsoft.

    “Until now, developers who need to test against a specific version of Microsoft Edge have been limited to local virtual machines, or PCs with Windows 10 installed. However, there are many developers that don’t have easy access to Microsoft Edge for testing purposes,” Microsoft wrote in a blog post announcing the partnership.

    As a result, developers now can sign in to BrowserStack and test Microsoft Edge for free. Developers can test sites and apps in the cloud-based Edge browser as if it were a locally installed instance, even if they’re working from macOS, Linux or another operating system that doesn’t natively support Edge.

    To enable faster, automated testing, Microsoft is also offering BrowserStack’s Automate testing service for free. Microsoft describes it in the blog post, “This method of testing allows you to run up to 10 Microsoft Edge test sessions via script, which can integrate with your local test runners via the standardized WebDriver API. You can even configure your machine so that the cloud-based browser can see your local development environment.”

    Developers will have access to three versions of Microsoft Edge within BrowserStack—the two most recent stable releases, and the most recent “Preview” release (the version available in the most current Windows Insider Preview Fast ring build). Testing for Microsoft Edge on the Windows 10 Anniversary Update is available now. EdgeHTML 15 will be available in the Windows 10 Creators Update—which will start rolling out to users on April 11. That version will be available on BrowserStack shortly after release.

    I hope the developers of Tweetdeck will take advantage of this service. I use Edge as my primary browser. It worked fine up until the Anniversary Update, but since then it has suffered from memory leaks, lags and crashes—but it seems to be related almost exclusively to Tweetdeck. I’ve never been sure whether the blame should be placed on Microsoft or Tweetdeck, but now that this service is being offered for free, hopefully the Tweetdeck developers can use it to identify and resolve whatever issues are causing the problem.

    — Tony Bradley

  • DevOps Chat: Purpose Built Appliances for Containerized Applications with Diamanti’s Mark Balch

    DevOps Chat: Purpose Built Appliances for Containerized Applications with Diamanti’s Mark Balch

    Back in my StillSecure days, building purpose-built appliances for security was all the rage. Over time, though, security-as-a-service captured much of the market (although security appliances are still a big seller). For containerized applications, you may think cloud is the way to go. But the folks at Diamanti say that purpose-built appliances for containerized applications are a superior option.

    I spoke with Mark Balch, their VP of product and marketing about this, and he gives us Diamanti’s views here and, frankly, makes a good case. It is early in the containerized application market and the winners are yet to be crowned. Mark tells it better than I can. Have a listen and let us know what you think.

    As usual, the streaming audio of our conversation is below and the transcript of our conversation is below that.

    Streaming Audio

    Written Transcript

    Alan Shimel: Hey, everyone. Alan Shimel, devopsy.kinsta.cloud here for another episode of DevOps Chat. Very happy to be joined today on DevOps Chat with Mark Balch, VP of products and marketing at Diamanti. Mark, welcome to DevOps Chat.

    Balch: Hey, Alan. Thanks for having me. It’s great to talk to you.

    Shimel: Thank you, Mark. So, Mark, let us first start off with Diamanti. I think that’s a fairly new company to our audience or at least to us here at devopsy.kinsta.cloud, although the company itself is not new, but, for those of our listeners who may not be familiar, why don’t you give us a little background?

    Balch: Yeah, definitely. We’ve been around since 2013, and Diamanti spent the first couple of years in stealth mode, as you may say, building our product. And we launched the company last year. We just launched our GA product this past week, in February.

    And just a very quick background or why are we here. Well, we saw the container revolution occurring. We believe that containers are the next mainstream application platform for new cloud-native applications, moving forward. And we’ve seen that users are spending a tremendous amount of time and money trying to custom-engineer their own infrastructure and figure out how to make cloud-native applications operate at scale, with reliability and performance. And we said that, “You know, we wanna make sure that users can do this out of the box, very simply, get control of their costs and be able to focus their time, instead of reinventing the wheel and infrastructure, on building the unique business applications that they’re being measured on.” So that’s why we’re here.

    Shimel: Excellent. And, you know, Mark, what was interesting is, at a time when we’re seeing software-defined everything, right, Diamanti’s out here with a purpose-built appliance for containerized applications. And I would imagine there are many people who say, “Oh, no, we don’t wanna sell hardware.” But, really, if you want control over your environment, you don’t have much of a choice.

    Balch: It’s a real tricky situation for a lot of users, right, because just go out there and spend a little bit of time searching on the web and going to meetups and looking at user testimonials about the challenge of being able to get reliable performance at a reasonable cost point in the traditional model. It’s really very difficult. People spend a lot of time custom-engineering, and that’s time that they can’t spend building their unique services. So, for us, really, it’s a very simple value proposition.

    We’re not saying that you have to customize your application or do anything proprietary; what we’re saying is that, “Continue to go with your open-source approach—standard Docker images, standard Kubernetes orchestration, standard Linux—but operate on a platform that is going to give you the automation of getting that entire application deployed properly, that’s gonna give you predictable performance and outcomes and that’s gonna let you run at a reasonable cost point.” I mean, people have massive bills, whether it’s public cloud, whether it’s looking at virtualized traditional infrastructure that was built for a different type of application. People spend a tremendous amount of time and money trying to get cloud-native applications working, and our goal is to make sure that people can get those applications working within minutes, not within weeks or months.

    Shimel: Sure. And that is the advantage of having that sort of purpose-built platform. Mark, I wanted to, first of all—you know what? Shame on me. I didn’t even ask. Can you give our audience a little bit of the background of who you are, though? And I’ve said your title, but who’s Mark Balch and how did you come to Diamanti?

    Balch: Yeah. That’s a good question. So I’ve been in the IT and application industry for 20 years. I started off my career as an engineer. I love doing development work. I love to build things. I love to deliver great products that have an impact. And then, somewhere along the way, I got into product management because I wanted to figure out whose job was it to make sure that we’re building the right products at the right time, that it could solve real needs. And so, for the last more than 10 years, I’ve been focused on product management and product marketing, doing everything from data center automation and application provisioning software to cloud automation software, and, now here at Diamanti, focused on the open-source side of application development and, again, focusing more on the outcome. Whether we’re talking about an appliance, whether we’re talking about software you can deploy, at the end of the day what I care about, as a product manager, is making sure that there’s a value at the end that’s gonna make someone’s life better, that’s going to give them a greater experience in being able to be personally successful in getting their applications into people’s hands. So that’s what motivates me.

    Shimel: Great. Appreciate that. Mark, if I may, I wanted to take a moment and talk a little bit about Kubernetes. There are obviously choices for container orchestration and container management out there, and it seems like Diamanti has clearly put their chips in the Kubernetes market. As I said, there are other choices. Can you give us a little bit of the background on why Kubernetes and—or maybe I’m wrong. Can Diamanti customers choose other container orchestration options as well?

    Balch: Yeah, you know, I think, when it comes to talking about container formats and orchestration, I think we all have to be a little humble, in that the market is still very early and very dynamic. There’ve been so many changes. Kubernetes is doing a great job. Mesos is doing a great job. Docker’s doing a great job. You’ve got now standardization happening in the Cloud Native Computing Foundation for the Open Container Initiative. So I think, honestly, it is too early to call a winner, and I think all of us have to make sure that we’re giving users choice in working with an open ecosystem. It’s not about forcing people down a particular path; it’s about giving people options. Right? So we can work with a variety of different options, but let me tell you why we have been doing a lot of work with Kubernetes. And we’ve been doing this work with Kubernetes for the last couple of years.

    Kubernetes, from a governance perspective, has been a great ecosystem to work with. Obviously, Google contributed that code to The Linux Foundation last year, and you’ve got large and small contributors from all over the ecosystem, including Diamanti, contributing to make Kubernetes bigger and better and more extensible. So what attracted us to work with Kubernetes early on was that governance, where, really, anyone could come to the table. Everyone has been welcome to pitch in and to take leadership roles, frankly. For example, Diamanti contributed something called “FlexVolume” into Kubernetes. It was upstream; it was a year ago. And we were welcomed with open arms, and now there are, literally, more than two dozen members in the storage SIG who we work with. Same thing around scheduling for Kubernetes—we upstream contributions there. Working with CNI, container network interfaces, is another example.

    So we’ve just seen a lot of great governance and a lot of extensibility, where the Kubernetes community seems very focused on this concept of extensibility, where it’s not that my solution is better than yours; it’s that we have APIs that we can use to extend different options and then users can pick and choose what’s gonna work for them, but it’s supported with a common framework. So that’s what we love about Kubernetes.

    Shimel: Got it. Interestingly, Mark, in our several studies, surveys on this with our audience, overwhelmingly—well, not overwhelmingly ’cause, actually, Mesio was pretty close, but Kubernetes clearly was the choice among our audience for container management and orchestration, so probably not a bad move there. Mark, what about people who have invested in public cloud infrastructure for containers? What’s the Diamanti value proposition to them?

    Balch: That’s a really good question, Alan, and people ask us that a lot. And, by the way, I’ll say that Diamanti is gonna be at the Google Cloud Next Conference next week, so we—

    Shimel: Really?

    Balch: Yeah, so we actually do a lot in terms of public cloud, okay? So I think the first thing is that it’s back to that concept of choice and no vendor lock-in. We need to make sure that we’re all offering users capability—we’re not trying to force them down a path with something that is proprietary—so everything we do at Diamanti is standard Docker runtime, and, as that evolves and maybe we have more standardization around runtime, that’s gonna evolve into making sure that everyone participates in the standard format. So, if you develop an application and you’re using Google Cloud or using Amazon or Azure or someone else, one of your goals, probably, should be to do it in a way where you can be portable, where you’re not locked in, where you can bring it to another provider if that provider offers you better economics, better performance, better reliability, data governance, things like that.

    And that’s where we come in. You could think of Diamanti as a provider, but we are an on-premises provider. We allow users, like MEMSQL or NBCUniversal, to be able to build an on-premises private cloud that is fully open source and you can take your existing containers, you can move them onto Diamanti, you can get all the great performance and automation benefits that we talk about. If, for some reason, you wanna go elsewhere, you wanna go to Google, to Amazon, somewhere else, we don’t stop you. You can do that. You can go back and forth, right? So we wanna make sure it’s very easy to go back and forth so that the user is in control of deciding what’s more important to them, in terms of all those things like governance, data sovereignty, performance, and economics.

    Shimel: Sure. Do you envision a time when people sort of have hybrid Diamanti-public-cloud containerized applications?

    Balch: Yeah, that’s a good question and actually brings up a really—another good wrinkle around Kubernetes. Kubernetes has an emerging project called “Ubernetes,” or its formal name, “cross-cluster federated services.” Now one thing I will say—I love the Kubernetes community, but sometimes, from a marketing perspective, we could do a little better. “Cross-cluster federated services” doesn’t really roll off the tongue very quickly, but what it means is, essentially, it can mean hybrid cloud or multiple availability zones.

    And so, just like Diamanti has made upstream contributions to the community around scheduling, we can now extend those scheduling capabilities, using Ubernetes, so we can move that across the availability zones and into hybrid cloud scenario. Right? So I definitely envision a scenario like you’re talking about, where you can have multiple Diamanti clusters in different data centers, you can have availability zones up in Google or Amazon or Azure, and you can, basically, allow the cross-cluster federated services to figure out where to deploy that application based on your performance requirements, on your sovereignty requirements, on your compliance requirements, or you can say, “Hey, I wanna make sure this thing goes into public cloud,” or, “I wanna make sure it goes into my Los Angeles data center with Diamanti.” You’re in control of that, from a policy perspective, and that’s, I think, what’s really interesting about the cross-cluster federated services road map, moving forward.

    Shimel: Absolutely. And you’re right; that does just roll right off the tongue. But, look, they’re engineers; they’re not marketing people. Mark, let me ask another question, and, not to hold your feet to the fire, but, for people who may be interested at home, can you give us sort of a ballpark pricing on Diamanti?

    Balch: Yeah, absolutely. So we’ve announced our pricing. Each Diamanti appliance has a list price of about $40,000, slightly under that, in fact. Obviously, discounts apply. So we are highly competitive with all alternatives, whether you look at commodity, whether you look at converged infrastructure, hyper-converged infrastructure. We are highly competitive from a price perspective. And then, when you look at the consolidation and the time savings, frankly, there is no competition there. So, certainly, love to chat with any of your listeners who are interested, and I pretty much guarantee, from an economic perspective, it’s gonna work out great.

    Shimel: So that brings up—you opened that box, Mark. For any of our listeners who may be interested in finding out more about Diamanti or speaking to someone, is there an e-mail address or a web address where they can check it out or contact someone?

    Balch: Yeah, definitely. So please check out our website, it’s www.diamanti.com, or just send us an e-mail, info@diamanti.com. We can get you set up really quickly.

    Shimel: Okay. Mark, we’re running low on time, but I did want to just mention that Diamanti is sort of riding the wave, if you will, of this tremendous momentum building up behind containers and micro-services and Docker, Kubernetes, etc. Where in the adoption cycle do you think all of this is? Has it really gone mainstream yet or are we still at the early-adopter stage?

    Balch: That’s the multibillion-dollar question, so we are seeing adoption all over in different kinda fits and starts, to be honest with you. So the industries we see the most adoption, Alan—we see media moving quickly. We actually do see financial services moving quickly. We see web infrastructure. We even see service methods moving ahead, wanting to offer containerized services and competing with the large public-cloud vendors. So where we see containers happening is developers are downloading Docker on their laptop; they’re able to accelerate their application lifecycle and development processes. Operations is a little slower. To be honest with you, it is lagging a little bit behind. That’s where we come in—we’re working with ops teams to help them get off the ground—and, just like always, developers ultimately have the influence where they’re defining application architecture, and then they work with their ops teams to figure out how to get those architectures deployed successfully into production.

    So there are lots of different numbers out there—451 Group had some good numbers; I’ve seen numbers from Forrester and from Gartner. The industry’s still early, maybe at only about 10 percent of adoption, and that’s a very anecdotal number, but it’s growing really quickly and we’re seeing a lot more inbound requests now because everyone’s trying to learn about it. The cat’s out of the bag; it’s not a secret anymore. And I think either people are doing it today or they see it coming quickly and they wanna figure out, when it comes down the pipe from their development team, how do they be successful with containers and actually make it work for their business.

    Shimel: Got it. Got it. Sounds great. Mark, we’re actually way over time. I apologize to our listeners and to you, but I thought we had some good information here and I didn’t wanna cut it off, but we need to wrap up. Mark Balch, thanks so much for being our guest today. Continued success with Diamanti. It sounds great. And, obviously, through Container Journal and devopsy.kinsta.cloud, this is a space we watch pretty closely, and I’m sure we’ll be hearing more from Diamanti soon.

    Balch: Thank you so much, Alan. This has been a great conversation. I appreciate it.

    Shimel: You know, one last thing. Mark, I forgot to mention. You mentioned you were going to be at the Google Cloud conference, which is the week of March 9th, something like that, right?

    Balch: Yep.

    Shimel: In March 8th and 9th?

    Balch: Yeah.

    Shimel: And then –

    Balch: March 8th through 9th.

    Shimel: – DockerCon is next month in August – in Austin.

    Balch: April.

    Shimel: In April.

    Balch: Yes. We will _____.

    Shimel: You’ll be there as well.

    Balch: Yep. Definitely gonna be there, yep, and we’ll also see you at OpenStack Summit, so we’ll be at Google Cloud Next in March, DockerCon in April, and Open Stack Summit in May.

    Shimel: And I think that one was in Boston?

    Balch: It is in Boston this year. That’s right.

    Shimel: Yes. Okay. Hey, we actually have some DevOps Connect events going on in Boston, Austin, and Chicago, but for another day. Mark Balch, Diamanti, thanks for being this episode’s guest on DevOps Chat and we’ll speak to you soon.

    Balch: Thanks a lot, Alan.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we hope to see you soon on another DevOps Chats.

    — Alan Shimel

  • DevOps Chat: The Evolution of APM with Jonah Kowall, AppDynamics

    DevOps Chat: The Evolution of APM with Jonah Kowall, AppDynamics

    In this DevOps Chat we speak with Jonah Kowall, VP of Market Developments and Insights at AppDynamics. Of course prior to that Jonah was a VP of Research IT Operations at Gartner. Jonah actually gave us a great overview of the evolution of APM  and how the market has evolved. He also tells where we might be heading now.

    It is not often you can get the lay of the land from an expert like Kowall, so I highly recommend you give this a listen.

    As usual, immediately below is the streaming audio of our discussion and below that is the transcript of our conversation.

    Streaming Audio

    Transcript of the Conversation

    Alan Shimel:                Hi, everyone. Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Our guest on this episode of DevOps Chat is Jonah Kowall of App Dynamics. Jonah, welcome to DevOps Chat.

    Jonah Kowall:             Thanks, Alan. Happy to be here—great to speak with you and everyone else listening.

    Alan Shimel:                Thank you. So Jonah, before we jump into App Dynamics, you have a—you’ve had a bit of a career already. Why don’t you share with our audience a little bit about kinda your journey to how you got here today?

    Jonah Kowall:             Yeah, definitely. Well, I always knew I wanted to be a technologist and, for many years, I worked at about six or seven different startups. I co-founded one of the first content filtering companies back in the early 2000s and, you know, got acquired a couple of times.

    And I kinda shifted careers a few years ago, about seven years ago, and moved into the analyst world and kinda moved away from running ops and security and infrastructure and application performance and decided to take the analyst path, and did that for about four years, which was very interesting and different, learned a lot of new skills, a lot of new muscles were built.

    And I joined App Dynamics a little bit over two years ago, and I work with our       co-founder and CTO running product strategy. I do a little bit of marketing, but quite a bit of product management and kind of looking into where we’re going as a company to solve the next generation of problems that we’re starting to see in our customer base.

    So that’s a little summary of where I came from and however you’d like to take it is great.

    Alan Shimel:                Sure. I guess the real question is, do you know where you’re going, but we’ll come back to that in a second.

    Jonah, as I spoke to you offline about, I wanted to talk to you a little bit about what I have seen, you know, as an observer of the market at devopsy.kinsta.cloud. In terms of the evolution of what used to be just a few years ago, a very kinda stable space called APM, right? We had, the APM space had a handful of players—App Dynamics was certainly one of them—who were, by the way, all doing pretty well, it seemed.

    And what we’ve seen in the last few years is, you know, in the—first of all, more people joining the fray, but more than that, in the race to distinguish one from the other, many players within this space are kinda rephrasing their mission, their—not running away from APM, but their APM plus, maybe. And so we’ve seen, you know, alphabet soups of ARAs and a whole bunch of different combinations.

    What’s your take on that, Jonah?

    Jonah Kowall:             So, when you look back—and, you know, when I started at Gartner, there was a lot of confusion around application performance and application monitoring. And there was like a general belief that anything that monitored some kind of application or even monitored the network and tried to extract application information was, in fact, APM.

    And what I kind of tried to do in my time at Gartner, and I think it sort of changed some things, was really focus APM on instrumentation of applications. So, how do we see the code, how do we get inside the application, how do we trace from end to end and really provide that visibility and the diagnostic capabilities that are really gonna be needed in today’s applications, which are incredibly complex and diverse, and consist of a lot of new technologies?

    So, building that kind of visibility is really hard to do. I mean, if an APM company—and there are plenty of them that have started over the last couple years—they have many, many years before their instrumentation becomes decent, if they’re even going down that path. And the ability to extract information from a running application, without breaking it, is very, very difficult to solve. It takes a lot of time, a lot of experimentation, a lot of work with customers.

    And so this market is very hard to enter into and compete with the three leaders in the space. It’s just a big challenge, and you’re looking at five to six years before these things mature, if they continue to pursue them. So what you’re kind of seeing, and what you alluded to, is that companies are trying to take a different angle and avoiding the deep instrumentation and just trying to provide SVKs and tools for developers to build those, you know, that visibility. But it’s a big challenge, because in enterprise and packaged applications, those products don’t work, and that’s really the challenge that I continually see out there when I observe the industry.

    Alan Shimel:                Got it. So, you know, certain—I’m sorry, Jonah, I have a little tickle. App Dynamics, you know, in, let’s call it an immature industry, rapidly become an 800 pound gorilla, and I think we’ve all seen the proof of that in recent news around acquisitions and so forth. But I’m not gonna go there, Jonah—suffice to say, App Dynamics is a market leader in its space.

    How does this evolution, if you will, changing dynamics, you know, you said you’re working on future problems—how do you think this plays into the future of App Dynamics?

    Jonah Kowall:             Yeah. Well, I think that applications and technologies will continue to evolve, and you know, we’re already starting to see a lot of new application paradigms that we’re gonna have to shift a lot of our core technology to support and to essentially leapfrog what the rest of the market is able to do, and we’re hard at work doing that.

    But aside from the deep, you know, introspection of software, there is also a big push for us to really understand the business, because today’s enterprises, regardless of what they do, whether it’s extracting natural resources from the earth or building cars or providing mortgages—these companies are all software companies, and their businesses depend and are driven by their software. And our goal is really to understand the business execution and the user experience of those transactions that are critical. And, in kind of taking that to the next level is really, how do we look at the outcome of software and of these business transactions as they come together.

    So, our vision is not only to increase our capabilities of the core of what we do in APM, but also to really provide a lens into the business that really provides that IT business alignment that everyone talks about and everyone struggles with today. So we really see that as the differentiator in these large enterprises that are really challenged with a lot of legacy and a huge amount of demand to change their businesses.

    Alan Shimel:                Got it. Got it, got it. So, Jonah, let me pivot a little bit to, there was another area I wanted to touch on with you, and that is this whole area of containers, micro-services—but containerization. Virtually every call, every briefing that I’m on, somehow or another containers make their way into the conversation. How big a focus is it over in the, in terms of product and in terms of the strategy at App Dynamics?

    Jonah Kowall:             Yeah, I mean, micro-services and containers are definitely the peak hype, let’s say, of the day—there’s no question about that. And they provide a lot of benefit, but a lot of people really feel that containers and micro-services are the answer to every problem. And this is something that we’ve seen over and over in our industry where, you know, there’s a new kind of angle to an existing set of technologies that we feel is really gonna make the biggest difference. And although containers and micro-services are both important paradigms, they’re not the answer to everything.

    Our customers are clearly retooling some of their applications around a micro-services architecture, and they’re definitely running workloads on containers, and these things are important for us to support, but are they more important than, you know, building core functionality to support new languages and new frameworks and really helping our customers with their more core business problems. It’s hard to say. I mean, both are clearly critical, but a lot of it is hype, and you know, the hype obviously fades as people become disillusioned with the fact that containers and micro-services don’t solve all your problems. They create a lot of new problems, and that’s just the reality of technology.

    So, as an industry, we’re very over rotated to containers, micro-services, and public cloud, and you know, we’ll soon realize those aren’t the answer to all of our problems—and oftentimes, they create new problems, as well. So, you know, I think it continues to be a cycle and, you know, I really think the evolution of cloud into a decentralized model will be a pretty interesting trend over the next, you know, 5 to 10 years as well.

    Alan Shimel:                Got it. I think we’ve barely scratched the surface. You know, Jonah, I was on a call previous to this and it was around software defined storage and networking and stuff, and it just—listening to it, I had such a déjà vu of sitting back in on the VMware stuff, you know, back in, I guess mid-2005, around then.

    Jonah Kowall:             Yep.

    Alan Shimel:                It just seems to promise so much change for us here; it’s crazy.

    Jonah Kowall:             [Laughter] It always does, and you know, it comes with challenges, always, and people become kind of disillusioned, but there are benefits to those that embrace it, do it well, and you know, have the types of problems that those technologies can solve.

    Alan Shimel:                Yep. Excellent. Well, Jonah, we’re just about up on our time. I’m gonna give you a surprise question here, if you don’t mind—if you can’t answer, that’s okay.

    Jonah Kowall:             Sure.

    Alan Shimel:                But I usually ask, the last question I always ask my guest is—recommend one book to our audience that you really think they should read to help them with their careers.

    Jonah Kowall:             That is an interesting one. I actually tend to, I do a lot of traveling. I actually flew over 200,000 miles in 2016.

    Alan Shimel:                Wow.

    Jonah Kowall:             So, when I actually get to read, I tend to read lighter materials, or I read very deep, technical materials that kind of help with some of the product work that I’m doing. So a lot of the books I read tend to not be too inspirational, but I do really enjoy participating in some of the open Slack communities. I enjoy reading a lot of blogs and other content that tends to be fresher.

    Alan Shimel:                Mm-hmm.

    Jonah Kowall:             You know, I read probably about 500 blogs in my RSS feed regularly, so that tends to really be how I get information, and I do really enjoy reading some of the Google Scholar, if you set some interesting alerts up, you can get some great research papers coming out from universities that are very interesting and forthcoming, just kind of highlighting some of the next generation thinking from the educational institutions all over the world.

    So that really tends to be more what I tend to read versus, you know, something that’s more career focused, I would say, or inspirational in that manner. So sorry I don’t have the best answer, but that’s what I tend to do.

    Alan Shimel:                No, no—that’s fine, and that works for us. Well, Jonah, I think we—well, we are out of time, but I want to thank you for joining us today on DevOps Chat, and I look forward to perhaps having you on again in the future.

    Jonah Kowall:             Sounds great. Thanks for your time, Alan, and thanks, everyone, for tuning in

    Alan Shimel:                Thank you. Jonah Kowall, App Dynamics, our guest today on DevOps Chat. 

                                        This is Alan Shimel for devopsy.kinsta.cloud, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel

  • Chef Report: DevOps Feeds the Need for Speed

    Chef Report: DevOps Feeds the Need for Speed

    “I feel the need … the need for speed!” ~ Maverick

    According to a recent report from Chef, one of the driving motivations for companies is based on this Maverick quote from the movie “Top Gun”: The need for speed. Getting better products to market faster is a competitive advantage that gives companies an edge over rivals—and DevOps, microservices and containers provide the fuel to speed things up.

    Chef conducted a survey to gain a better understanding of trends and technology adoption within the Chef customer community. A Chef blog post explains, “In the first few weeks of January we received over 1,500 responses. While that’s a small slice of our user base, we received responses from around the world, across all industry verticals. This varied sample pool allows us to get a pulse on the challenges most directly impacting the Chef community.”

    In a nutshell, the Chef survey found that DevOps is having a fundamental impact on the shape and practices of IT organizations. Companies are embracing DevOps, cloud infrastructure, virtualization, microservices and containers—all in an effort to streamline development and deploy faster.

    Here are a few of the highlights from the Chef report:

    • The majority of teams surveyed are releasing changes to production not monthly, weekly or even daily, but on demand. Likewise, teams overwhelmingly report reducing the time it takes between an initial software commit and running code in production to mere hours from weeks and days.
    • Cross-functional teams are 17 percent more likely than application teams to release changes to production on a continuous, on-demand basis. Further, cross-functional teams are 23 percent and 24 percent more likely than infrastructure and security teams, respectively, to release changes to production on demand.
    • When a failure occurs in production, the majority of respondents (55 percent) are able to recover in one hour, the shortest possible recovery time in the survey. One-third of respondents (33 percent) are able to recover in the next window of four hours.
    • The overwhelming majority (86 percent) of respondents have completed or are in progress of managing a project to migrate infrastructure from physical to virtual.
    • Three quarters of all respondents are running cloud-based apps in a public or hybrid cloud and only 25 percent are running them purely in a private cloud.
    • More than two-thirds of respondents (67 percent) are already running or plan to run containers in their infrastructure.

    Chef sums up with an analysis of the survey results. The report states that building and maintaining a continuous enterprise requires teams to embrace emerging technologies to increase velocity.

    Virtualization and automation drive speed. Chef also suggests, however, that teams should embrace the preferred services and tools of developers, and adopt those across other teams. The report also stresses that organizations should strive to integrate security and compliance earlier in the production cycle.

    These tidbits only scratch the surface of the report. I recommend that you download the report and read it in full. The bottom line, basically, is that speed provides a competitive edge, and that technologies and practices such as DevOps, virtualization, microservices and containers enable organizations to produce better products faster.

    — Tony Bradley

  • IoT Forcing the Coming DevOps Deluge

    IoT Forcing the Coming DevOps Deluge

    We can look back over the last few years and easily pick out the organizations that picked up DevOps and ran with it, forwarding the science of DevOps while benefitting the most from it. They were the large-scale, high frequency-of-change organizations. One place I worked readily called them the webmonsters, and that is not too far off the mark. Think of those that left a mark on DevOps: Google, Amazon, Netflix, Facebook. High rate of change in a high-volume environment. The key is high volume—they had hundreds or thousands of servers to manage and a shifting ground on which to manage it. So they adapted, picking up DevOps and applying it with passion.

    What Sounds Familiar Here?

    While DevOps adoption has certainly grown and offered benefits beyond these high-volume environments, their need for DevOps is still relevant. Where else are their a huge number of deployed servers that might need to be managed? The internet of things. A successful IoT product will have thousands to millions of installed devices, and those devices will be communicating back with centralized or cloud systems. Those devices no doubt also will have an update mechanism, which implies a shifting need for updates.

    ‘No, There is Too Much. Let Me Sum Up’

    Inigo Montoya said that in “The Princess Bride,” and he didn’t even realize he was talking about IoT and DevOps. Of course, a successful IoT rollout is not hiring staff to manage each and every device deployed by a customer, any more than Apple or Cisco Systems hires staff to manage devices owned by their customers. But the ability to manage all of these devices must exist, and that’s why IoT and DevOps are destined to become inseparable. IoT vendors will need all that automation to stay on top of those devices. And it would be foolhardy for developers to believe they didn’t need to stay on top of devices. If a serious vulnerability is exposed in an IoT device (think wireless Barbie vulnerabilities from 2015), it will have to be patched, or legal responsibility will no doubt follow.

    Expect More to Come in IoT

    As IoT heats up, and things such as IoT botnets become more worrisome, expect that DevOps for IoT will become more of the norm. As long as we require these devices to report in (and that’s kind of the point) and we have access to perform updates, it will require systems to know when/how/what version the updates should be. While many existing DevOps tools will work, expect more development in the IoT-specific space in the near future. And with luck, some of those developments will be applicable to the broader DevOps audience.

    Some companies, such as Mocana and Tempered Networks, are already working on the security issues, but that’s not all there is to work on. Inevitably, those devices—in a year or five—will need to be updated. When IoT includes things such as cars and refrigerators, “upgrade your device” isn’t an option, so onsite upgrades will have to be, which will mean some form of DevOps to deploy new images. Of course, eventually the hardware will be outdated, but that’s beyond the point of this blog—although something that IoT devs need to be considering also, particularly in long-lasting deployment scenarios.

    — Don Macvittie

  • DevSecOps @RSAC, My 2 Favorite Presentations

    DevSecOps @RSAC, My 2 Favorite Presentations

    For the third year, devopsy.kinsta.cloud hosted a DevSecOps/Rugged DevOps event at RSA Conference. As with years before,  we smashed attendance records. We had just shy of 900 people stop in on Monday of RSA Week to hear from the 11 presentations we hosted. Taken in total, the presentations presented a wide range of DevSecOps issues. I wanted to draw your attention, though, to two of the presentations that I really enjoyed.

    First of my favorite presentations

    The first was from someone I had not met before who came to our attention via our call for speakers. Duane Schleen presented, “Implementing DevOps in a Regulated Environment: The Aetna Experience.” His presentation is below:

    Why did I love this presentation? Good question. First of all it is rare that we get such an open peak behind the kimono at the actual inner workings of an enterprise, especially in such a regulated industry as insurance.

    More than that though I am telling you that Duane Schleen or DJ as he is called is going to be a DevSecOps rock star. Can’t wait for him to write a few articles for us here at devopsy.kinsta.cloud. If you get a chance to see him speak at a conference near you, jump at it. Can you tell I am a fan?

    On top of this the look Schleen gives us into DevSecOps at Aetna shows that despite the naysayers, you can go faster, with higher quality and be more secure!

    The Second Presentation I loved

    The second presentation I wanted to bring to your attention was the opening keynote by John Willis. Most of you have probably seen John present before either live (if you are lucky) or on line. John is of course a co-author of the DevOps Handbook as well.

    John’s presentation is entitled, “Breaking Bad Equilibrium”.  It is about cooperation in DevOps, technical debt and uses some game theory to explain some of the John’s thoughts.

    My favorite part is when John uses some clips from the UK game show “Golden Ball” to discuss Nash Equilibrium (or prisoners dilemma )  and game theory. Both clips really grab you and make you think (as many of John’s presentations do). I will let his presentation speak for itself though.

    Beyond, these two excellent presentations, you can see the rest of the presentations from our DevSecOps event at RSA Conference this year on our DevOpsTV channel on YouTube. The link takes you to the playlist with all 11 presentations.

    This years DevSecOps event at RSAC was a smashing success with almost 900 people stoping in to hear some of the excellent presentations. It did this authors heart good to see this great mixing of the DevOps and security tribes coming together.

    — Alan Shimel

  • When DevOps Disrupts DevOps

    When DevOps Disrupts DevOps

    As longtime readers of my blogs will know, one of my hobbies—when not writing about or playing with technology—is modeling. There is a similarity between quality tech work and quality modeling, but the brain power involved in modeling is much less, leaving me time to think about tech issues or listen to audiobooks (when I’m not listening to music, anyway).

    In modeling, as in tech, there is a process. The process varies based upon what you’re working on, but is largely the same, with some steps slightly different or skipped altogether and others taking longer. At the moment, I’m building the first day of Gettysburg from the American Civil War, but I simply enjoy modeling—and wargaming with the models, but that’s a separate story for a hobby-focused blog.

    The thing is, that process is nailed down, and to the extent it can be, is automated. One step leads reasonably to the next, and while one step is completing on a given model (glue or paint drying, etc.), there is an opportunity to advance a separate project.

    Sounds a lot like DevOps, doesn’t it?

    The thing is, every once in a while, you will get something that is so different, it totally interferes with the carefully planned flow. My current primary project is a little over 300 figures. While one unit is getting the final two coats of finish (that are basically the same or every model), the next unit is getting primed. Assembly of all the figures came first, so there is only the priming step before painting can commence.

    Picture, but you missed it.
    Piper Millin and Lord Lovat cross Pegasus Bridge.

    But here is a work-in-progress picture of Pegasus Bridge. This came as a complete set, and took a large chunk of time to get together, find the correct water for, get placed on foundation boards, etc. This is outside the normal process of assemble/paint/base figures and vehicles. The set is beautiful, and even this picture, which was taken well before completion and only to study color and weathering effects versus reality, shows how truly nice the model was. But it totally disrupted the process flow.

    DevOps and Multisystem Installations

    That’s what complex system installations such as Hadoop or OpenStack do. You’re installing across multiple systems, configuring them for load-sharing and communication, and doing it by hand is a long process that interrupts the normal DevOps flow. Crafting scripts to install them is possible but highly complex and frustrating, simply because of the complexity and interrelationship of the nodes in the system.

    Having installed both by hand, and installed both with tools designed to make it easier, I will happily tell you that yes, you will understand more if you do it by hand, and no, that immediate understanding is not necessarily worth the cost of weeks or months figuring it out and getting it installed.

    You see, to operate these systems, you will need much of the knowledge you would gain hand-installing, so you’re going to learn it either way. Your choice is a simple one: Get a working system and learn by tweaking settings or swapping nodes in and out, or have no working system and learn by the frustrating process of trying to figure out what you’re supposed to do next, and why that step is failing for your specific hardware.

    DevOps and Multisystem Maintenance

    The only real problem is that it is painful to maintain these systems. It’s not as simple as

    yum update [[packagename]]

    because that would only upgrade one package on one system. But these tools span multiple systems, and even just dependencies generates a massive list for each system in the cluster. Seeing the need, most of the traditional application provisioning tools (Puppet, Ansible, et al) have built or cobbled together solutions that will get the job done. But custom solutions exist for these products, too. The problem is that, like Pegasus Bridge, as beautiful as they are they disrupt the DevOps flow. No system goes without exceptions, and I’ll go out on a limb and say that custom solutions to install and maintain solutions such as Hadoop and OpenStack are worth having yet another tool in the DevOps tool chain. The trend is multipurpose tools to be used on many projects, but the importance of a cloud or big data cluster in your IT operations makes them worth the extra tool. As long as the extra tool reduces the amount of work and the chances for human error (which, in my opinion they do—it is kind of their selling point).

    That Leaves Time

    These tools (a good example, though in general I won’t be talking about the competing vendors here, is the Mitaka-based release of Mirantis) allow not just installation but also ongoing management of the OpenStack cloud or big data cluster. That means there is less nitty-gritty for DevOps (or operations for that matter) teams to worry about, freeing time for working on what actually gets built on top of these powerful platforms. Cloud and big data both are just enablers for more functionality when looked at in the right light, which means more work (and often more meaningful work) for DevOps teams.

    When you consider either of these technologies, check out what’s available for installation and maintenance, even if it is outside your normal DevOps tool chain. Like Pegasus Bridge, the change is likely to disrupt you for a bit, but once you have a tool and process in place, it will just be something that happened—and was going to happen with or without the tools. They just make it less painful.

    — Don Macvittie

  • Help Us Understand CI/CD, DevOps & Job Scheduling

    Help Us Understand CI/CD, DevOps & Job Scheduling

    While plenty of vendors tell us what they think is happening in the market, the only way to really learn is from you, our readers. So we are asking you to take a few minutes to take this important survey on the adoption of CI/CD, DevOps and job scheduling.

    We will be giving a $50 Amazon gift card to one out of every 50 respondents. More importantly we will be publishing the results here on devopsy.kinsta.cloud to share with everyone. The survey is sponsored by BMC and co-produced with devopsy.kinsta.cloud.

    You can take the survey right here:
    Create your own user feedback survey
    Thanks for taking the time and helping us help us all.

    — Alan Shimel

  • DevOps Security: Stop Discussing, Start Implementing

    DevOps Security: Stop Discussing, Start Implementing

    Is it Strong DevOps? DevOps Security? Secure DevOps? DevSecOps? DevSecQAMktSalesOMGBBQOps?

    Who cares?

    Like a ton of people with an interest in information security, I was appalled when I read “The Phoenix Project.” Here was a book that portrayed DevOps, why it was required, how it could help and the benefits very well. But it served security terribly. Worse than terribly. While it did accurately portray the predominant feelings of developers and Operations toward security, it utterly failed to adequately consider the correct usage of DevOps to attain InfoSec goals. Indeed, while it is a light treatment, it certainly comes across as, “Give up on InfoSec and you’ll be happier, healthier and more popular!”

    Clearly it was not a book written by information security staff.

    The Point Is …

    Don’t get me wrong, those who follow me know that I’m a developer that learned operations and has always found himself doing security bits, because no one else was, or because I was teamed with them (as an enterprise architect, our team was EA + Infosec, so we did a lot together). But that abiding interest in InfoSec has made it easy for me to see that the bulk of the problem between Security, Dev and Operations really is communication. An example might be in order.

    When SQL injection first hit the scene in a big way, it came with simple examples and was easy (for a developer) to understand the danger. Nearly immediately, developers had worked up solutions, were sharing them and tools were being developed to scan for injection weaknesses. Things moved very quickly, because developers understood the danger and agreed that it was a big deal.

    Meanwhile, using page data—hidden fields, hard-coded values (like from a list), etc.—pose the same level of risk. Copying the page, modifying those values and submitting the page—or using any of a dozen easy to use tools to mock up the data—makes them equivalent to user input, particularly in cases where they are used directly in queries. Yet even today, many many developers still use them without user-input error checking.

    Why? Because they don’t believe the risk is equivalent. For SQL injection, all a bad actor has to do is hit a vulnerable webpage and enter the right (and, I might add, well-documented) characters to open themselves to free querying of the database—at least one table, possibly much more. They see that as a much greater risk than someone having to modify HTML to get the right field to have the correct data and submit it.

    The fact that both attackers and tools are advanced enough to make the difference negligible doesn’t change the belief unless security convinces developers through education.

    ‘Faster’ has Challenges

    By the same token, both agile and DevOps move fast. They are designed to move fast. Security is more concerned with “protected” than fast, and is designed that way. Security staff (and this is the real source of a lot of burnout) hires on with “Protect Our Systems” as a job title, with the subnote, “But don’t get in the way.” This is a set of core principals that are at odds before the InfoSec person even sits down to interview. Agile and DevOps aggravate this tension, because, “Wait, there is a problem here, give us until tomorrow to get details,” now violates “but don’t get in the way.” “The developers in question have a stand-up coming and really short, really tight deadlines to meet. And InfoSec is interfering—again,” will likely be added to that statement by Dev. The same is true in Ops. Stopping an entire deployment because InfoSec is worried about security of private keys inside the private network violates the “but don’t get in the way” rule.

    But Solutions are Available

    So how can these tensions be brought together to resolve your problems? I’ve got some suggestions (they probably aren’t in the order you would expect, so I’ll explain as I go), but honestly  they are just a starting point. Entire books have been written on these topics, and more are about to be, if the state of the DevOps/InfoSec union is any indication. We can’t even agree what to call it, so we clearly aren’t agreed as to how to achieve it. Take these as what they are—suggestions—and start moving forward with what your org needs to be successful.

    1. Automate all of the things. Yep. Go download the various OWASP security tools, or your other favorite open-source tool, or call up your preferred vendor and get the automation of security checking—from source code analysis to penetration testing—going. Do those tools have weaknesses when compared to manual security evaluation? Most of them, yes. But here’s the thing. There is a quality staffing shortage in both InfoSec and DevOps. It is time to lean a little more on those tools, even contribute to make them better. Because the security checking they can do is better than nothing, and frankly is better than spending limited resources checking by hand. And that is why this step is first on my list. You need those resources. You need them to handle the rest of the steps. Once you have a tool like Jenkins auto-running these tools, and output review being just part of the job, then you can start to consider using those freed up resources more productively, or reporting that you’ve got more testing with DevOps than you had, whichever is true.
    2. Embrace and enhance education. Because of the rate of movement in an agile-plus-DevOps world, this must become a partnership with both Dev and Ops. Focus on helping developers and admins with the why as much as the how. People are more quick to adapt if they understand the reason for doing so. And for InfoSec to keep pace, they will need to adapt quickly.
    3. Look for ways to automate beyond implementing simple tools and reviewing results. The more repetitive work is built into the process, the more InfoSec is available to tackle bigger, less scriptable problem-solving. I’ve been talking a lot with CloudCoreo, for example, and its auditing tools can help InfoSec understand the state of cloud deployments with both alerting and reporting. Infrastructure monitoring tools make a lot of sense in a world of frequent infrastructure changes initiated by both auto-scaling and more frequent deployments.
    4. Shift automation of InfoSec to the DevOps team. Security is normally a relatively small function, and open positions can sit there or bring in people who need training in an organization’s tools and processes. So once automation is in place and reliable, shift responsibility to maintaining it (software updates, etc.) to the DevOps team, because it is a part of the DevOps process. Security can continue to monitor output and validate automated security testing results, but maintaining that piece of the DevOps infrastructure should not be InfoSec’s job.
    5. Rank what’s left that’s manual. Give each an importance. If there is potential impact to the business, ask business people to help you. Then assign work based on severity rankings. We do this stuff with risk management and threat assessment; this is no different, except you have to be willing to drop low-priority things—not to let them slide because you never get to them, but to publicly say, “This is a risk we are willing to take.” Let the team know that they’re not the only ones adapting.

    Will these basic starting steps solve all of InfoSec’s problems and make security never seem to “get in the way”? Of course not. Don’t aim for hanging around the campfire singing “Kumbayah”; aim for working as a team to turn out quality secure compliant code in a more predictable (and if you are an org that needs it, much faster) manner.

    A Rose by Any Other Name

    What, then, we should call it?

    Frankly, I suggest we call it DevOps. We’re not going to add every team that is subsumed into the DevOps umbrella into the name, so just call it DevOps and have a security piece in the process.

    Because it really doesn’t matter what you call it—it matters that it is compliant and protected.

    — Don Macvittie