devopsy.kinsta.cloud

Tag: open source

How To Maintain Open Source Code Hygiene
To maintain good open source code hygiene in the development process, you must first establish what you mean by open source code hygiene, including good and bad hygiene. “By hygiene, we just mean is it appropriate? Is it clean for the intended use?” says Mike Pittenger, VP of Strategy at Black Duck Software.

Black Duck suggests three metrics it uses to determine whether it is appropriate to apply a given open source code project to a certain development endeavor:
- For software that will be distributed at large, avoid open source code that the development community has made available through a GPL license.
- For secure software, check your potential open source code for vulnerabilities in general and make sure to use the most secure version available.
- Monitor the code periodically to check for new vulnerabilities or other concerns.
As an example of the third point, Pittenger notes OpenSSL is no longer a viable option because of the vulnerabilities that have come to light in the form of Heartbleed.

Checking Source Code for Open Source Concerns

While the InfoSec Institute recommends at least 14 different open source vulnerability scanners for web applications alone, offerings such as Black Duck’s can serve as a shortcut to discovery of known bad open source components. “Instead of having to load Nessus, Metasploit or Nexpose with a Heartbleed rule and scanning every application, every server that they’ve got, they can just go into their Black Duck console, type in OpenSSL, and it would immediately show them every version they used in their software applications,” says Pittenger. Of course, you should always do your own due diligence to determine whether any scanning product is the best choice for your organization and aligns with your needs and requirements.

Due to the many open source code reuse scenarios active in enterprise DevOps shops, you will want to continually monitor code for newly registered vulnerabilities. Enterprises can view reusing existing assets as a built-in savings by not having to purchase or create new assets. In the case of reusing legacy source code, there is also a time savings, as developers want to shrink time to market for code-based projects.

“Let’s say you have a company that is pulling information from a database to display in pie charts. You have a rendering component that you will reuse. When you’re starting on a new product, do you build a new rendering library from scratch or do you use the existing one?” asks Pittenger.

Even if those components are open source, there can be great savings in reusing the library.

The fact that enterprises do this underlines the importance of continuing to check any code that leverages open source code, as this is how vulnerabilities can spread over time. It’s also important to check open source code, because it may be a form of low-hanging fruit for attackers. Open source code is fully viewable by attackers who build malware and launch attacks, whereas proprietary code is closed.

Since people constantly discover new vulnerabilities in open source code components that previously had tested free of such holes, it’s important to monitor those components for newly uncovered weaknesses, even as you reuse open software in new projects.

Containers are a great example. You may want to dismantle an image in varying degrees to build a new application. “If I have a base image and it’s built using a LAMP stack (i.e., a Linux OS, an Apache HTTP server, a MySQL RDBMS and PHP), I can strip down my base image, take away the existing app and take it all the way down to the Linux component, then build it up for the new application,” Pittenger said. “That is a typical, consistent reuse of open source components.”

During the process, recheck every component for vulnerabilities. Even if everything checks out doesn’t mean you have the best assurance of security for those components going forward. By monitoring those components, you can stay on top of updates to fix any newly discovered security holes.
February 24, 2016
February is Open Technology Month at devopsy.kinsta.cloud

As part of our continued evolution here at devopsy.kinsta.cloud for 2016 we have designed an editorial calendar. Each month we will feature a particular topic of interest to our readers. For February the topic is open technology. This means we will have a feature section on all things open; this will include open source, open enterprises, open methods, etc.

You will be able to find this featured section off of our front page right under the newsletter sign up. Every month this will change to reflect that months theme.

There are a few good articles already in there and there will be more added the rest of the month. I would also point you to a good DevOps Chat I had on open technology with Dan Berg in the InterConnect@IBM section.

In addition to content related to the featured theme, we will also have special content regarding the theme. For open technology month we will have a report by Tony Bradley on open technology, open source and the open enterprise. Look for that later this month.

The open theme also dovetails nicely with our coverage of IBM’s InterConnect conference, coming February 21-25 in Las Vegas. Open is a major theme for this years event. We will feature interviews and coverage with some of the presenters at this years event. There is also a special sponsored section “DevOps@InterConnect” where all of the InterConnect related content can be found. With something approaching 300 sessions regarding DevOps there is a DevOps related session for everyone.

BTW, you can get a copy of our editorial calendar within our media kit. If you would like to contribute content on a future monthly theme, we welcome the input and look forward to sharing it with our readers. Also if there are topics you think we missed in our editorial calendar write me at editor@devops.com with your ideas.

So enjoy open technology month at devopsy.kinsta.cloud. Next month is Rugged DevOps, so there is more to come!

February 12, 2016
DevOps Chat: Dan Berg on Open Technologies and the Open Enterprise

I had a chance to speak with Dan Berg, distinguished engineer at IBM. Dan and I discussed open technologies, open enterprise and open tool chains. A whole lot of open there. We also talked about how open technologies will be part of the upcoming IBM InterConnect event. Below is the stream of our conversation and below that is the transcript if you would like to read along.

Enjoy!

Alan Shimel:                Hi everyone, this is Alan Shimel, Editor and Chief of devopsy.kinsta.cloud, and welcome to another DevOps chat. Today, our guest on DevOps chat is Dan Berg of IBM, and we will be talking about DevOps and open technologies. Dan, welcome to DevOps chat.

Dan Berg:                   Thank you, Alan.

Alan Shimel:                So Dan, before we jump into the whole open technologies, open enterprise subject, can you give our listeners just a little bit of background of who you are, what you do and why you’re here today?

Dan Berg:                   Sure. So as you pointed out, my name is Dan Berg. I do work for IBM. I’m a distinguished engineer, working in our cloud platform organization, which fundamentally means I’m responsible for working with a set of very energetic teams that are building out services in our cloud foundation. So the IBM cloud platform, specifically in IBM Bluemix, things like our container service, log-in and monitoring services, several DevOps based services. So services such as things like we call active deploy that help deploy microservices within a cloud architecture. So I do a lot in that space, helping the teams identify the strategy and the architecture that we’ll use. I’m also very much involved in our DevOps organization within IBM cloud, focusing on both cloud native applications, as well as hybrid cloud applications.

Alan Shimel:                That’s fantastic, and Dan, you know, we talk about DevOps, and certainly when we talk about cloud, one could say we’d have no DevOps or no cloud without open source. What do you think about that statement?

Dan Berg:                   I think that’s a pretty profound statement. Open source is a strong component of cloud strategies.

I think almost all customers are looking at cloud as a direction. I talk to a lot of our customers, and I can’t say any of them that do not have a cloud strategy or at least pursuing a cloud strategy.

And one of the areas that comes up quite often is this notion of being able to have the flexibility of choice. I want to be able to choose my cloud provider and I might want multiple cloud providers.

And the only way to really achieve that is to have an open community and open standards that allow you to develop your workloads, develop your applications in such a way that you can move them from one provider to the next in their run, as you would expect them across multiple providers.

And as I pointed out, you’re not gonna get that unless you’re focusing on a strong open community that is driving open standards.

Alan Shimel:                Yeah, you know Dan, so I’m old and I remember when I first got into IT and technology, there was a time where there was tremendous pushback about open sourcing the enterprise.

We’ve all read the books and we’ve listened to Richard Stallman and the book is escaping me now. What’s the great book about open source? Something about the bazaar and the – oh, whatever.

Gosh, I’ll find it but the more important thing is you know we’ve – and what was the pushback?

How can the enterprise rely on open source without support, without vetting and all of that?

And really it’s been companies like IBM and dare I say, even Microsoft now that have kind of helped pave the way for open source into the enterprise. What do you – what’s your thoughts on that?

Dan Berg:                   Well, so it’s interesting to see how the open source has evolved, how developing in the open has really changed the way in which developers learn, and how they adopt technologies.

You first and foremost look to the open communities as a way to understand new technologies and to join a community in which those technologies are evolving and you’re right.

Enterprises often look at or have in the past looked at open source as, okay, that’s cheap software that people are doing on the side. They’re not part of any company. How can we trust this?

Is it enterprise ready? We’d better not touch it. Right, we’d better develop our own. I think that mentality has changed dramatically for a number of reasons.

One, the communities have become extremely large. I mean look at things like the open stack community or the cloud foundry community, the Docker community.

These communities have established a base set of users and contributors, and have grown substantially over the last several years, and what they’re developing is being developed with an enterprise mindset. I mean it’s not just for kicking the tires or playing around.

We’re developing enterprise grade solutions in the open, and the reason why it’s being done in the open is because with the community around these initiatives, you end up getting more input from various stakeholders and ultimately at the end, you get better solutions that cater to a larger set of stakeholders.

I know within IBM, I mean we’ve been developing in the open for many years. I can remember way back, 15 years ago, working in the open.

While it may be difficult initially, when you’re thinking oh, I’ve got to work with a community of people and get agreement, that is true to some degree.

But what you find is that as more people start working together and collaborating across the globe on a set of technologies, an open set of technologies, it actually picks up pace and you can innovate much faster, because you just have a larger pool of resources and developers working on that code base.

And that’s what we’ve been seeing, and adopting that back into an enterprise and using it has become easier because you’ve got enterprises like IBM, like Microsoft, like others that are contributing to these open communities and ensuring that enterprise requirements are added into those code bases, so that they can be consumed by an enterprise.

So it is shifting. I think more and more, enterprises are adopting open source capabilities because of the innovation and the enterprise grade quality that’s coming out of those communities.

Alan Shimel:                Absolutely. By the way, Dan, the book was The Cathedral and the Bazaar.

Dan Berg:                   Yeah.

Alan Shimel:                By Eric Raymond, and I’m sure you read it too. It’s – you know what, at this point, I’m ashamed to tell you. It’s like 15, 20 years old but, whatever, it’s still good.

So Dan, let me pivot a little bit with you and let’s quickly turn. This month we have the IBM interconnect show, which is sort of IBM’s big cloud in mobile and I like to say DevOps event as well.

And the open enterprise and open source is front and center, and rightfully so, in light of what you’ve just told us.

What can you highlight for us a little bit maybe about the open source, open enterprise at Interconnect this year?

Dan Berg:                   Yeah, so there’s gonna be a number of exciting things. I mean we do really drive the notion of open source and open technologies.

We’re gonna be discussing obviously some of our core initiatives around open stack, around node and JavaScript, Docker as well.

We’ve got a number of exciting sessions and activities that we’re driving within those communities.

The open container initiative, another big one that we’re involved with and discussing the direction that we’re helping to forge in that community to drive where we see containers going.

So that’s Docker based containers and other containers, really driving a stronger community around the container movement. Even around DevOps, the great, great thing that we’ll be showing off there is some of the work that we’ve done with the IBM garage method.

So it’s an open set of processes and practices that we announced late last year, and then moving into this year in the envelope a little bit further, and what we’re doing is associating with the practices, a set of tools.

And these tools are obviously some tools that we provide, services that we provide, but a lot of them are open tools as well that are being developed and made available in the open communities.

But one of the exciting things in this area that we’re driving is something we call the open tool chain, and open tool chains are a set of capabilities that allow organizations to define their best of breed practices and DevOps capabilities in a tool chain.

An integrated set of practices and tools that can be instantiated by other parties.

So we’re pretty excited about that initiative. It’s still early days but we do see the potential there and the flexibility that’s being achieved by bringing together these open technologies into a unified tool chain that drives cloud native deployment and delivery mechanisms.

So we’re very excited; lots going on in these communities and we’re really excited about sharing that information at Interconnect in about two and a half, three weeks.

Alan Shimel:                Absolutely, you know, Dan, I think I might have been out with you in San Francisco when they announced the open garage method at – I forgot what conference it was but in any event, it was a DevOps enterprise summit.

Dan Berg:                   That’s right.

Alan Shimel:                As you mentioned.

Dan Berg:                   That’s right.

Alan Shimel:                And you know, to me that was a little different, especially for an IBM in that it wasn’t an open source project. Right, it wasn’t a particular tool.

This was really more of an open methodology with tools tied into it and you talk about a supply chain.

It is a sort of that software supply chain where the software or the app you’re developing, not all of it is going to be open source.

But there are open source components that make it easier for us to develop apps in real time continuously, with continuous delivery and integration, and all of this goodness we see in DevOps.

And to me that was sort of the power of the garage method, right, was this software supply chain, if you will, with open source components, making up a lot of it, wrapped around IBM’s experience and know-how in bringing this together. I think it’s powerful.

Dan Berg:                I definitely agree, and as I pointed out it’s still early days but it’s showing the promise. I mean we all know how difficult it is sometimes to piecemeal together your delivery tool chain with the various open source tools as well as third party vendor specific tools.

It can be quite complex and what’s really nice about the open tool chain is it takes some of that complexity out of your way and really helps you focus in on your key initiative, and that is deliver high quality code as quickly as possible.

So I’m really excited about it. It does build upon some of our core technologies, but I’m really excited about how it brings in some of these key open technologies and open communities to drive better DevOps experience overall.

Alan Shimel:                Yeah, agreed. You know, Dan, unfortunately we’re coming up on the clock but this is – you know, the whole subject of open source of software supply chains, of the open enterprise.

And how enterprises are incorporating open source components into their supply chain is one that fascinates me and one that I think you’ll see more of on devopsy.kinsta.cloud, as well as it sounds like quite a bit of it at Interconnect later this month.

Dan Berg:                   Absolutely, and if anyone’s gonna be out at Interconnect, definitely look me up. You can find me. I’m doing a number of different sessions, and you can grab me on Twitter at DanCBerg.

Alan Shimel:                Yeah, well and they could also look for you on the Interconnect site, Dan and probably search by speaker.

Dan Berg:                   Absolutely.

Alan Shimel:                Just we don’t have any time but which of your talks or sessions are you most looking forward to?

Dan Berg:                   Oh gosh, there’s a number of sessions but there is one, and I’d have to look. I forget the name but it’s a DevOps panel that I’m looking forward to.

And there’s a number of us on there including myself and Gene Kim are gonna be on the panel. I believe it’s on Tuesday, if I’m not mistaken.

Alan Shimel:                I believe that would be my panel.

Dan Berg:                   I’ll have to look in my —

Alan Shimel:                What does DevOps look like in the next five years?

Dan Berg:                   Ah, that’s right, it’s yours

Alan Shimel:                Thanks for the plug, Dan

Dan Berg:                   Not a problem.

Alan Shimel:                I welcome people to come out and check it out. We’re looking forward to a great panel. What a way to end our conversation.

Dan Berg, distinguished engineer for IBM, thank you so much for joining us today on DevOps chat, and I’ll see you later this month at Interconnect.

Dan Berg:                   Absolutely, looking forward to it.

Alan Shimel:    Okay, bye bye. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you on another DevOps chat.

February 11, 2016
Lexumo Funded to Secure IoT and Embedded Devices, Critical Infrastructure, and Enterprise Applications from Widespread Open Source Vulnerabilities

New cloud platform leverages “Big Code” analytics to continuously search, index and monitor code for open source vulnerabilities such as Heartbleed and Shellshock.

Cambridge, Massachusetts – February 1, 2016 – Lexumo, developer of the world’s first automated cloud-based service for continuously monitoring software for vulnerable open source components, has closed $4.89M in seed funding from Accomplice, .406 Ventures, and Draper. Lexumo continuously searches and indexes software to immediately identify publicly-known open source vulnerabilities that can cause theft of sensitive data, failure of critical systems, and brand damage. Lexumo’s cloud-based service integrates transparently with existing software development workflows, does not require access to source code, and provides specific, actionable recommendations for remediation. Lexumo’s new funding will be used to further develop and commercialize the platform and build the company’s sales and marketing teams.

“To gain speed and agility, the vast majority of development organizations today assemble software from reusable software ‘building blocks’ which are downloaded from open source repositories. Yet many of these components contain published vulnerabilities which are extensively described in public forums and vulnerability databases – providing cyber attackers with a clear roadmap to attack critical systems, devices, and enterprise applications,” said Brad Gaynor, Ph.D., CEO and co-founder of Lexumo. “The funding is a validation of our scalable, cloud-based approach to identifying and eliminating open source vulnerabilities in a new and innovative way.”

According to industry analysts, open source software (OSS) is now used for mission-critical IT by 95 percent of all mainstream IT organizations, as well as in 85 percent of all commercial software packages. Yet, in 2014, there were approximately 52 million downloads of vulnerable components from the Central Repository, which supplies widely-used shareable components developed by open source organizations such as The Apache Software Foundation, Atlassian, RedHat (JBoss), and Oracle (Java). When these vulnerable components are integrated into a company’s software, their products and applications are at risk.

Originally developed at Draper with DARPA funding, Lexumo’s “Big Code” technology combines big data analytics with software analysis techniques for the first time. This unique approach uses indexed search techniques to continuously identify deep commonalities between the hundreds of millions of lines of open source code available today and the software used in a particular system, device or application. It then identifies exactly which open source components and versions are present in the code – with a high level of granularity and accuracy. Drill-downs provide detailed information about each vulnerability and its location in the code, along with automatically-generated instructions to patch them.

Lexumo’s cloud-based service is easy to use and does not slow down development because it integrates with existing build and ticketing systems, and no developer interaction is required to analyze the code.

“The premise of Lexumo’s Big Code technology is ambitious and its implementation is both elegant and impressive, which is a reflection of the team’s deep domain expertise and passion for solving security-related problems,” said Jeff Fagnan, General Partner at Accomplice. “The Lexumo platform makes it incredibly simple for software developers to securely use open source software, raising the bar for application security.”

“Security for the Internet of Things has been largely overlooked and, given the pace of IoT deployments, it presents a massive risk to technology developers, businesses and consumers,” said Maria Cirino, Managing Partner at .406 Ventures. “Recent research cites that security solutions for IoT are at least two years away, but Lexumo has the right technology and business model to tackle this problem today.”

“The IoT is vulnerable because humans are fallible,” said Kaigham J. Gabriel, president and CEO of Draper and former acting director of DARPA. “The Lexumo team applied automated big data analysis to eliminate open-source security vulnerabilities across all sectors of critical national infrastructure and commercial enterprises. The team built the first implementation of the initial concept at Draper, and we are thrilled to spin out Lexumo.”

About Accomplice

Accomplice (FKA Atlas Venture) is an early-stage venture capital firm that invests in technology startup companies, with specialties in cybersecurity, eSports, data analytics, SMB class software, emerging hardware platforms, and marketplaces. Our partners are Jeff Fagnan, Christopher P. Lynch, and Ryan Moore. For more information, visit www.accomplice.co.

About 406 Ventures

.406 Ventures is an early stage technology venture capital firm investing in enterprise technology companies founded by visionary entrepreneurs. .406 Ventures was founded in 2005 and has ~$600M under management. The .406 Ventures team is comprised of entrepreneurs and operators who became investors to apply real world experience and strong company-building skills to create value for entrepreneurs and LPs. The firm leads, or co-leads, first institutional investment rounds in market-changing Enterprise IT companies and world-class operators, who move quickly and embody successful entrepreneurial DNA with their passion, creativity and endurance. www.406ventures.com

About Draper

As a not-for-profit engineering research and development company, Draper focuses on the design, development and deployment of advanced technological solutions for the world’s most challenging and important problems. We provide engineering services directly to government, industry, and academia; work on teams as prime contractor or subcontractor; and participate as a collaborator in consortia. We provide unbiased assessments of technology or systems designed or recommended by other organizations — custom designed, as well as commercial-off-the-shelf. www.draper.com

About Lexumo

Lexumo protects the world’s open source software. Originally developed with DARPA funding, Lexumo’s Big Code technology combines big data analytics, machine learning and software analysis to detect vulnerabilities in software built with open source. Lexumo’s automated cloud-based service continuously searches, indexes and monitors open source code and known vulnerabilities to provide the fastest, most effective way for identifying and patching even the most recently discovered security threats. For more information about how Lexumo secures open source software used in IoT and embedded devices, critical infrastructure, and enterprise applications, visit https://lexumo.com.

February 3, 2016
To Be Continuous Podcast: The Clash in Open Source

Welcome to To Be Continuous, a show about Continuous Delivery and software development hosted by Paul Biggar, Founder of CircleCI, and Edith Harbaugh, CEO of LaunchDarkly. In this episode, Edith and Paul talk about the clash in OSS between developers looking to get paid and software companies looking for things for free.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

[soundcloud url=”https://api.soundcloud.com/tracks/244279037?secret_token=s-oeBCP” params=”auto_play=false&hide_related=true&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=’166′ iframe=”true” /]

Edith: So Paul, what do you like about open source?

Paul: So I guess that depends on whether we’re talking about writing open source or using open sources as part of a company. Writing open source, I like just having all my code out there.

And I’ll do that as often as possible. Anytime I start a little bit of code, a little library, I’m looking to open-source it and have a readme and have it out there for other people to use. I had a very long discussion, which I eventually won, about the …

Edith: I like the way you think of all discussions as win or loss.

Paul: Well, yeah, yeah. It was more on the argumentative side of discussion. But with the other co-authors of the PHP compiler I wrote, which was originally GPL. And I argued very strongly that I actually don’t care if people give back, I just want people using my software. So to me, open source is a way of having people using my software.

Edith: That’s really interesting. So, I liked what you said at the beginning about, like, you liked open source ’cause it meant getting stuff out sooner. ‘Cause I’m a big fan of that.

Like, I always say you should just publish stuff. Like, my co-founder John said something really good at our team meeting last week. He’s like, if it’s 90 percent done and you don’t publish it, it’s actually 0 percent done.

Paul: It’s 0 percent done, yeah.

Edith: Yeah, and that’s a hard lesson, ’cause you always try for perfection lately.

Paul: Right, right, right. Well, I think there’s also some really hard downsides about that. So when you publish something before it’s ready, before you really —

Edith: Well, ready.

Paul: Well, there’s ready ready, but let’s say ready is, let’s say you publish it before you clarify what the software is to do, or the values or the mission of the software.

And then you get contributors who are saying, ‘Oh, this is great, but I really want it to do this other thing,’ and you’re like, ‘Well, that’s not exactly what I was going for here.’

Edith: Well, I’d say most open source projects are so lucky as to get contributors at all.

Paul: True, true, true. So I’ll give you an example. I wrote the V8 bindings for Closure. So a binding that allows you to write JavaScript and run it in Closure. And I did that for a purely selfish thing, for another, for a nascent pipeline that I was building called Stefan.

And then people came along and they wanted to do other things with it. They’re like, ‘Okay, let’s add a binding for this other thing.’ I was like—

Edith: Well, that’s kind of like a pivot.

Paul: It is, it is, but I really was not interested in it.

I’d rather someone took it over, took over the project and actually ran with it where they wanted to go, and I can stick on the old version, or I can see if the new version solves it for me, but I wasn’t interested in becoming a maintainer in this thing, I was interested in solving my itch.

And I just happened to open-source it, because I felt it might be useful for other people.

Edith: So Paul, I hate to say this, but I agree with you.

Paul: No, not again.

Edith: Not again. No, I mean, I think what you said is exactly right, that you said, I did this for this reason, and I want somebody else to take it over now.

I think where open source runs into issues where people are like, it’s only this purpose and you can’t do anything with it besides my original thing.

Paul: So you think that’s a good thing, or you think that’s a problem? Or it causes problems in the community?

Edith: I think open source is so misused for so many different purposes that it’s hard to even say. Like, so, in Europe, people say open source is good because it means free software.

Paul: Libre or gratuit?

Edith: I’m sorry?

Paul: Free as in beer or free as in, what’s the other side of that?

Edith: There’s no such thing as a free lunch, is that what you’re talking about?

Paul: No no no, like people say open source software, it’s like free-as-in-beer software, as in software that has no cost vs. software that has no price tag vs. software that is, they use the French word libre for—

Edith: Oh yeah, that’s what I was talking about. So I remember I went to Europe in, I think it was like 2004 or 2005, and they just had this big push for open source, ’cause they thought it meant free.

Paul: Oh, this is like the German government and that sort of thing.

Edith: So literally like, so I went to this customer and they’re like, ‘So it doesn’t cost you any more to give us an extra copy.’ So why shouldn’t just everything be free?

Paul: Oh, right, yeah, well.

Edith: And so I think open source has been misused by many businesses who think of it as just like, hey, we get all these developers working for free.

Paul: So I think that the main advantage to business of open source is not that it’s free, but it’s that it’s low-risk.

Edith: Low-risk?

Paul: Lower risk. So it removes—

Edith: Ah, I would argue—

Paul: Well, so, what I mean is that it removes a certain element of risk from it. So there’s, Joss Belsky wrote a blog post about how you shouldn’t use, I think it was a database that you didn’t have the source code to.

Edith: Well, so I’ll argue the reverse, and I think open source is sometimes more risky. ‘Cause I talk to people now who are like, nobody’s maintained this open source project that I depend on.

Paul: Right, right, right. But that vs. a closed-source version.

Edith: Well, so the opposite risk is that you end up that you are responsible for this open source project, and you’re like, well, actually, I just wanted to use this thing. I didn’t want to do the maintaining.

Paul: So absolutely, you don’t wanna end up the only person that, well, it’s actually fine to end up the only person which is using this thing.

Edith: Well, no, it’s not—

Paul: It’s not ideal.

Edith: It’s that many people are using it, but nobody is paying money, and then you’re stuck.

Paul: Because no one is maintaining it.

Edith: No one is maintaining it, and you depend on it.

Paul: Right, so, but imagine that no one maintained it and all that you could get was like a binary block. That’s the real problem. The company goes out of business. You have random database version seven, the binary, that only runs on 32-bit, that you’re maintaining, like, companies are literally maintaining COBOL—

Fortran things from 30 years ago. It sits in a machine, you can’t touch it, you can’t fix it, you can’t apply security updates to it.

Edith: Yeah, that’s fair. So Tim Chou, who is, he’s an awesome guy, he was early Oracle, he said that people don’t buy, when they buy software, they’re not buying it what it is today.

Paul: Right.

Edith: ‘Cause basically, anything that you’re buying today, you could just hire 20 engineers that could build it. What they’re buying—

Paul: Yeah, you could just copy it.

Edith: Yeah, what they’re buying is the promise of stability, that it will continue to be maintained. That there is a vision. And that’s actually, I went over to a big customer who won’t let us use their name yet, but they said they love LaunchDarkly because we thought every day about feature flags.

Paul: Right, right, exactly. This is why people buy SAS, because, because people think all day about CI, about QA as a service, about queues, or whatever it is from various Heavybit companies that I just shilled for, they’re, you can probably figure out yourself which ones they are by looking at the homepage.

Edith: Well, and Paul, by the way, thank you very much for wearing your LaunchDarkly t-shirt today. It looks very handsome.

Paul: The, I definitely agree that the benefit of the thing is that you use it every day. But you can do that with open source as well. You can have open source software that, so, for example, our front end is open-sourced.

Edith: Oh, I’m absolutely a fan of open source. Like, we use open source every day. Our client libraries are open source. I’m not saying that it’s, I don’t think it’s a religious thing vs. open source vs. not, I just think that many times people assume open source is something that it’s not.

Paul: Yeah, fair enough, fair enough.

Edith: I mean that if you have open source, that just means that developers spring out of the ground willing and happy to update your software every day.

Paul: A mixed blessing, definitely. If it even happens.

Edith: Like, I remember, so I remember when Sun, so I used to work on a, I used to be at Epicentric, and we had a portal server, and we were killing Sun. Absolutely killing Sun. And this was in 2003, so what they said is, ‘Oh, we’re gonna make our portal server open source.’

Paul: Right.

Edith: And so somehow this whole thing, we’re like, everything will be open source, and like, developers will spring out of the ground, and it’s like, well, no, developers, they don’t wake up every day like, ‘I’m gonna work on your thing.’

Paul: Right, right. They will if it’s sexy or exciting. There’s lots of developers who are showing up at Mozilla just to contribute. And in fact, they’ve fought through incredibly large hurdles to contribute to Mozilla’s software.

Edith: Well, that’s fascinating, ’cause I see so often the reverse, where people, so what do you think about Mozilla made people want to contribute?

Paul: I think the fact that it was an open-source-first company, and that it was a nonprofit, and it was all about the free and the open web and that sort of thing. Also, people had had very good experiences with Firefox for, like, a decade at this point by the time I was there. Well, maybe seven years, but, you know.

Edith: It’s fascinating, ’cause I went to dinner last night with the CEO of MySQL, and I don’t know if I should say this, but he said—

Paul: This is Marten Mickos?

Edith: Yep. So he gave a talk—

Paul: He has a new startup?

Edith: Called HackerOne?

Paul: Oh, he joined HackerOne.

Edith: Yeah, he’s the new CEO. So the dinner was kind of like a debutante ball for him.

Paul: Nice, nice.

Edith: So what he said was that somebody had asked him flat out how much of MySQL was actually from contributors. He said 1 percent.

Paul: Seems about right.

Edith: He said the open source was more just a branding thing. Like it wasn’t actually like a productivity thing. It was more just a branding thing.

Paul: So you have this in Mozilla as well, that any time that there’s a really avid contributor, that Mozilla would hire them.

Edith: Yeah, that’s what he said.

Paul: Right, and if Mozilla didn’t hire them, very often they stopped being a contributor. Like, it was a real sort of a double-edged sword.

So someone who did it for six months, they were doing it for the love of the game. They weren’t doing it to be hired at, at least I think for the most part, they weren’t doing it to be hired at Mozilla. And then six months in, someone’s like, well, you know, you’re doing a really great job, wouldn’t you love to work on this full-time? They’re like, yeah, that’s so exciting. They’re flown out for an interview. And then it’s like, you know, actually, I don’t think so.

Edith: Wait, they didn’t wanna work for Mozilla, or Mozilla didn’t wanna hire them?

Paul: Mozilla didn’t wanna hire them. I mean, this isn’t a particular case. But you know, some subset of people, Mozilla didn’t wanna hire. And then what happens? Well, you kind of don’t wanna keep contributing to the company that just told you to f*ck off.

Edith: Yeah, I mean, it’s so true. I mean, I think there’s a very human thing about volunteering.

Paul: Right, right.

Edith: I volunteer, I was the moderator for a long time for the Lean Startup Circle, and somebody new came on, and they’re like, yeah, I’d love to raise some money so that we can get paid, and I’m like, they cannot afford to pay me.

Like, I don’t do this to get paid, ’cause—

Paul: Yeah, it’s like, it’s an altruism that people are trying to do.

Edith: Yeah, I was contributing like 10 to 15 hours a week, and at my going rate, it’s not, it’s like, I’m not doing this to get paid, I’m doing it ’cause I like giving back.

Paul: So there’s this thing that we were talking about earlier, about the current discussion around people getting paid in open source.

Edith: Yeah, and I think a lot of what has fueled open source is the whole 20 percent time. Like, that Google will give their engineers 20 percent for open source, and I know that other big companies, like Twitter and so on, do that too. So these people are, in essence, getting paid.

Paul: Right, right, there’s a, in most companies, in most startups at least, there’s an unspoken rule that you’re expected to contribute to the libraries that are in your application, and that sort of thing. If you’re spending time upstreaming paths that you’ve deployed, that’s work.

Edith: Yeah, so I think we’re agreeing, which, I thought we agreed that we were not gonna agree. It’s funny, ’cause I’m Twitter friends with a guy I’ve never met, who’s, he started Jango, and right now what he tweets a lot about is—

Paul: This is Jacob Kaplan-Moss?

Edith: Yeah.

Paul: Okay.

Edith: That people are working their nights and weekends, and contributing to open source, and then just, people are kind of, for lack of a better word, jerks. People are like—

Paul: People are jerks.

Edith: Yeah, like—

Paul: Even when you’re paid, people are jerks.

Edith: But it’s more aggravating.

Paul: Right, right, because you’re doing it for free, or whatever.

Edith: Yeah, and so people will, like, they’ll be like, ‘I have this pull request and it’s been open for two hours. Why haven’t you reviewed it?’

Paul: Right, right. I mean, we get the exact same thing. We get customers who email us, or more often it’s the people who get, who are using the free version, who send us a support request and then, 30 minutes later they’re on Twitter going, I can’t believe Circle hasn’t solved my problem yet. It’s been 30 minutes.

Edith: What do you think drives that?

Paul: There’s a pattern across the population in general, that people are jerks.

Thanks for listening to this episode of To Be Continuous, brought to you by Heavybit and hosted by me, Paul Biggar of Circle CI, and Edith Harvaugh of LaunchDarkly.

You can find the full episode of this podcast here. For more on Continuous Delivery and to hear other Heavybit podcasts, copy this link into your favorite podcast player. We’ll have show-specific RSS and iTunes subscription options soon. You can also follow To Be Continuous on Twitter at @continuouscast.

January 29, 2016
Dev loves Open Source. Ops needs Scale. Now What?
Crossing the divide from Dev-Ops to DevOps:

At the heart of the divide between Dev and Ops are the very different needs and constraints of each organization. Traditionally their day-to-day lives are very different. So are their war stories. And so are the metrics that are traditionally used to judge Dev and Ops. Predictably, the two organizations can end up internally competing with one another over (among other things) resources and IT automation tool selection. Part of the driving force behind the DevOps movement is to reduce this unproductive internal competition. Even with the increased levels of trust and communication that DevOps fosters, IT Operations teams will still have different criteria for IT automation than their colleagues in Dev.

My company is considering implementing (or has just implemented) an open source configuration management tool. That’s great for Dev. But as far as I can tell my job, and my team’s job, is about to get a LOT harder

~ VP IT Operations

Dev loves Open Source:

Take configuration and release automation as example. Like so many other areas of enterprise software, many developers naturally gravitate to open source options. It’s no wonder that 90% of code in modern applications is open source – after all, open source provides developers with
- Immediate gratification: Just Google it! Choose the right key words to describe your situation and you might find a good match.
- Community: Don’t reinvent! Find out what have others done. Opinions and suggestions might be plentiful across your favorite user groups. Maybe someone has solid sounding advice. Maybe someone even has specific settings or scripts that they have used. If so, you might be in luck.
- Free: Enough said.
But while Dev is drawn to prebuilt open source components that they can then modify,

Ops has completely different needs including scale, stability, support, security and speed.

Let’s look at each of these in turn:
- Scale: It’s great that the code works in Dev and in Test. In Operations, I need it to work everywhere, all the time. And we need to add 10s of thousands of servers with no new resources.
- Stability: Don’t force me to rebuild my infrastructure to be stable in a production environment.
- Support: Someone, somewhere needs to be on the hook for this software, with enforceable SLAs. This cannot be left to chance. I need a phone number. Now.
- Security: Failure is not an option. Our financial future and reputation is on the line. We cannot allow our customers to become vulnerable due to security issues. According to a study by Forrester Research, consider:
  - “One out of every 16 downloads of open source component requests are for a component with a known vulnerability.”*
  - “31% of companies have had or suspect a breach in an open source component, gaining control over open source risks is essential to improving security.”*
- Speed: We need quick time to market and low total cost of ownership that comes from quick learning curves.
In the context of configuration and release automation, can we satisfy both Dev and Ops?

Yes. Here’s why:

A new generation of application configuration automation solutions have been introduced in recent years. (To be transparent my company, OrcaConfig is one of these). These solutions cater to Ops’ need for fully supported, central, secure control, ecosystem visibility, workflow automation and compliance enforcement – all at enterprise scale and without relying on open source, community driven scripts.

But what about Dev’s needs?

I will answer a question with two questions.
1. Does Dev need open source?
2. Or do they want the benefit that open source often brings?
If those sound like product requirements document (PRD) type questions, they should. In an era with tightening constraints on budgets and headcount, selecting the wrong tool based on incorrect assumptions is a major self-inflicted wound.

These next generation DevOps solutions provide Dev with application-centric modeling (after all it is all about the application), templated workflows (immediate gratification) and versioned full stack configurations (time and money savings) while providing accountable, knowledgeable support (community is great. Community and support is even better.)

While there are no silver bullets in the drive to DevOps success, my hope is that we can dispense with the open source “requirement” and instead focus on needs and results.
December 9, 2015
9 more open source DevOps tools we love
A while back we ran an article by Tomer Levy of Logz.io about 9 open source DevOps Tools that we loved. Of course how can you pick just 9 among so many worthy choices? So we wanted to revisit the open source DevOps tools space and add another 9 tools to the list. In a few months we will be adding more open source DevOps Tools to the list as well. In the meantime here are 9 more must have open source DevOps Tools that we love:

1. Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. Using the concepts of “labels” and “pods”, it groups the containers which make up an application into logical units for easy management and discovery.Originally developed and owned by Google,Kubernetes was offered to the Cloud Native Computing Foundation to seed other complementary technologies to enable a set of common container technologies. It is an integral part of CoreOS’s Tectonic product, in addition to being tightly coupled with Mesos and the Mesosphere DCOS.Kubernetes offers the promise of Google-like container usage for everyone. It seems no matter what the basic container technology we use, it is being used with many of the container-based PaaS stacks today

2. Chef – From the official what is: “Chef is a systems and cloud infrastructure automation framework that makes it easy to deploy servers and applications to any physical, virtual, or cloud location, no matter the size of the infrastructure. Each organization is comprised of one (or more) workstations, a single server, and every node that will be configured and maintained by the chef-client. Cookbooks (and recipes) are used to tell the chef-client how each node in your organization should be configured. The chef-client (which is installed on every node) does the actual configuration.

More than the above though, for many Chef along with Puppet Labs and Jenkins are the heart and soul of DevOps tools. Moving beyond its original configuration management mission today Chef represents the move to “everything as code” while still maintaining its open source commitment. Chef Delivery, Chef Compliance move Chef into the realm of a tool that is involved in the entire DevOps workflow.

3. Puppet – The Romulus to Chef’s Remus, Puppet Labs is one of the founding members of the DevOps movement. Built on open source and still fully supporting its open source heritage going forward, Puppet like Chef has moved beyond its original mission of configuration management and automation of single machines or instances to orchestration of your entire stack.

From Puppet’s open source doc, Why Puppet

Puppet has been developed to help the sysadmin community move to building and sharing mature tools that avoid the duplication of everyone solving the same problem. It does so in two ways:
- It provides a powerful framework to simplify the majority of the technical tasks that sysadmins need to perform
- The sysadmin work is written as code in Puppet’s custom language which is shareable just like any other code.
This means that your work as a sysadmin can get done much faster, because you can have Puppet handle most or all of the details, and you can download code from other sysadmins to help you get done even faster. The majority of Puppet implementations use at least one or two modules developed by someone else, and there are already hundreds of modules developed and shared by the community.

4. Maven – a Yiddish word meaning accumulator of knowledge, Maven was originally started as an attempt to simplify the build processes in the Jakarta Turbine project. There were several projects each with their own Ant build files that were all slightly different and JARs were checked into CVS. We wanted a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects.

The result is a tool that can now be used for building and managing any Java-based project. We hope that we have created something that will make the day-to-day work of Java developers easier and generally help with the comprehension of any Java-based project.
Maven’s primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with:
- Making the build process easy
- Providing a uniform build system
- Providing quality project information
- Providing guidelines for best practices development
- Allowing transparent migration to new features
5. Gradle – the yin to Maven’s yang, Gradle and Maven are much like Puppet and Chef. In this case though Gradle was born out of frustration with Maven and other tools. From the Gradle, Inc. site:

Gradle was founded by Hans Dockter who was working in Enterprise software development and ran into an intractable build problem. At the time he was using Apache Maven. After three days and nights of exhaustive research, he discovered that the problem could not be fixed with the tool at all. Hans vowed to cure this problem for himself, for his team, his company, and for developers everywhere. He was joined in this mission by founder CTO Adam Murdoch. After releasing Gradle the open source project out into the wild in April of 2008, Hans and Adam then hired all of the key contributors whom they met along the way. These included world renown Gradle experts from companies like Thoughtworks, Typesafe, and Pivotal.

Many developers and shops today use one or the other of these open source tools.

6. Mattermost (& Zulip) Today is all about ChatOps. In many organizations it is replacing email as the primary communication method between teams and even outside members now. While there are plenty of commercial solutions in this space like HipChat and Slack, there are some worthy open source tools available as well. One of the biggest advantages to these open source solutions is you don’t have to use a hosted version if you are worried about control, governance or security issues. You can install these on your own server and maintain yourself if that is your preference. Here are two of the leading open source ChatOps tools:

Mattermost – is an open source Slack alternative. The company behind it is a Y Combinator funded startup with founders who come from Microsoft Office engineering. Frustrated that in using a SaaS hosted chat program they were locked out of their own data unless they paid to use the app they set out to create their own self-hosted app and so Mattermost was born. Not sure where the commercial element ill join this, perhaps open core type premium features? Support? Time will tell.

Zulip – Acquired and then released as open source under an Apache license by DropBox, Zulip is a modern take on ChatOps. Not based on IRC and XMPP, Zulip features: Threaded group conversations, One-on-one and group private conversations, Persistence, History, Full-history search, Team presence and buddy list, Inline image, video, and tweet previews, Drag-and-drop file uploads, Stream-wide announcements, Emails for important missed messages, Desktop notifications, Audible notifications, Hotkeys, Emoji, Code, Lightweight markup, Message editing, Invite-only streams, Starred messages, Integrations, API, Mobile apps, Desktop apps

7. OWASP – A developers and DevOps best security friend, OWASP has become the place for web application security. Their mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks. OWASP is actually an umbrella for a number of different projects including tools, lists (OWASP top 10) and groups. Their website says it best:

The OWASP Foundation came online on December 1st 2001 it was established as a not-for-profit charitable organization in the United States on April 21, 2004 to ensure the ongoing availability and support for our work at OWASP. OWASP is an international organization and the OWASP Foundation supports OWASP efforts around the world. OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas. We can be found at www.owasp.org.

OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative and open way. The OWASP Foundation is a not-for-profit entity that ensures the project’s long-term success.

8. Zabbix (& Observium) – OK so lots of people have grown to hate Nagios. There are still lot of people who use Nagios too. That being said, we wanted to highlight some open source options in the network and application monitoring space. Two we like are Zabbix and Observium.

Zabbix – The basic work sphere of Zabbix LLC is development of open source software for monitoring of networks and applications. Apart from that the company offers a wide range of professional services designed to fit every customer’s unique business demands including implementation, integration, custom development and consulting services as well as various training programs.

Zabbix team’s mission is to make a superior monitoring solution available and affordable for all.

The company’s flagship product is Zabbix, one of the most popular open source monitoring software in the world. It is already used by a vast number of companies, who have chosen it due to real scalability, high and robust performance, ease of use and extremely low costs of ownership.

Observium – is a low-maintenance auto-discovering network monitoring platform supporting a wide range of device types, platforms and operating systems including Cisco, Windows, Linux, HP, Juniper, Dell, FreeBSD, Brocade, Netscaler, NetApp and many more. Observium focuses on providing a beautiful and powerful yet simple and intuitive interface to the health and status of your network.

Professionally developed and maintained by a team of experienced network engineers and systems administrators, Observium is a platform designed and built by its users. Observium Community is available free to everyone and recieves updates and features twice annually. Observium Professional adds priority access to daily updates and new features for a small yearly fee.

9. Cucumber – OK raise your hand if you use Cucumber. It is one of the best kept secrets in the business. I am constantly amazed out how many developers and DevOps folks mention this open source tool. It’s actually several tools as their are different versions for different languages with each one having a slightly different feature set.

For those of you who don’t know, “Cucumber has revolutionalized the software development lifecycle by melding requirements, automated testing and documentation into a cohesive one: Plain text executable specifications that validate the software.”

So those are our latest 9 open source DevOps tools we love. We know there are more. Leave comments with worthy choices for our next article.
November 9, 2015
The Myth of “Do It Yourself” DevOps Tools
DevOps is an approach and methodology (even a philosophy) for developing and testing new applications and deploying them into a production environment. Because DevOps is first and foremost a methodology, tools to implement DevOps should be used as a way to implement the desired methodology, rather than being an end in and of themselves.

Of course, many tools exist for automating parts of the DevOps methodology, and many are widely adopted. For example, few development teams would operate without source code control and versioning software. Yet I continue to be amazed at the number of enterprises that think that the best approach to implementing their DevOps methodology is to write some of the automation tools themselves.

The DevOps methodology is a common methodology, based on longstanding principles first espoused by W. Edwards Deming, through Six Sigma quality processes, and later popularized by “Lean” programming practices. Nothing is new in DevOps. So, what would be the advantage for an organization to implement their own DevOps tools?

We hear some common justifications for “Do It Yourself” solutions. Let’s review these justifications to see if they hold water:
- I can implement exactly the processes I want with less effort and cost.
This justification is based on some common misconceptions. For example, it is often difficult to do a good side-by-side comparison of cost between a commercial tool, an open source tool and writing the code yourself. Clearly the commercial tool has the most concrete and well established cost. When comparing to an open source tool, it is very important for enterprises to take into consideration the ongoing maintenance and upgrade costs that they will undertake themselves.

Early in 2015, Qualisystems interviewed its enterprise customers and asked them if they thought that the cost of open source tools was lower than commercial tools. They unanimously agreed that the cost was about the same from a total cost of ownership perspective. Other factors were the key influencers in whether to use an open source tool or a commercial tool. Estimating the cost of an internal development effort is even more difficult. One would have to consider the upfront development effort, and the ongoing maintenance and upkeep. A number of other intangible factors include the likelihood that the project will run over time (and therefore cost); how well the code will be understood in the future by new developers; the risk of loss of the key developers, etc.
Finally, there is the interesting question of how efficiently teams will implement their own DevOps tools if they aren’t yet already using DevOps methodologies and tools. (This is a little bit like a Catch-22).

Another hidden assumption behind this statement is that your enterprise doesn’t need all of the features provided by commercial tools, so therefore the cost to implement will be lower. Of course, most commercial and open source software has been vetted already by customers and the list of features is usually a result of extensive customer use and feedback. Often this feedback is not obvious to a new team just starting out with DevOps tools. And, then there is the fact that commercial and open source tools spread the cost of development across their entire customer base, so no one customer is bearing the cost of actual development.
- Why would we, as developers, pay other developers to write any code that we could easily write ourselves?
Well, that is like saying that since I have a driver’s license, I should be able to drive a semi-truck. Designers of software applications require specific knowledge of the problem space and solution space. This knowledge and expertise yields Intellectual Property. If we extend this concept to DevOps tools, we would conclude that creating DevOps tools also requires specific knowledge and expertise and it is different from the knowledge and expertise of most enterprise software developers.

There is also an opportunity cost to writing your own code to implement tools. That time and effort is taken away from developing applications and solutions that would directly benefit the business of the enterprise. That opportunity cost could be quite high. The simplest way to do this assessment is to ask yourself, “Is a DevOps automation tool going to add to the relevant IP of my company in a way that increases our revenue?”
- Rather than implement tools like automation that will help us to share equipment, it is cheaper and easier for me to just buy more equipment.
This argument also falls prey to the difficulties of accurately comparing the costs between automation and equipment. Purchasing more equipment to eliminate sharing will be an ongoing activity. The extra cost will be replicated every time equipment is upgraded or replaced. The extra cost will also grow linearly with the size of the software development and test teams. And, any equipment cost will be doubled by the cost of management, operations, power and cooling, etc.

Even with completely dedicated equipment, software tools will be required to properly configure that equipment to replicate different operating environments, a common requirement in testing and QA. If these software tools also implement sharing of equipment, then the overhead cost is low.
- If I write my own tools for some DevOps processes, I will be able to easily connect to any other tool of my choice through their APIs.
This is true but will also require that you maintain these plug-ins yourself over time, including staying current with API changes in third-party tools. Typically, commercial tools will carry this burden for you.
- The market is still early and there are many, many tools. Writing my tools myself will allow me to control my own destiny.
Well, it is hard to argue with fear and uncertainty. On the other hand, if the tool is just a means to an end, then switching tools should not require massive changes in process or methodology. If enterprises keep their focus on acquiring tools that match their methodology and processes, then they really can’t lose, even if they end up switching tools over time.

So, what is the answer? Perhaps there is a “best of both worlds” solution. After all, DevOps is a process and it is possible and even likely that each enterprise will want to implement that process in a way that best optimizes their own internal pipeline from development to production. Furthermore, each enterprise has its own mix of infrastructure in production and must optimize their testing to that infrastructure. Each enterprise has their own mix of legal and compliance requirements that they also must test against.

Perhaps the right answer is to provide a commercial (or open source) software solution that is more of a platform that enables easy customization (even in the form of code) to support unique process requirements, unique infrastructure, and unique testing requirements. At the same time, a common framework for implementing process orchestration, and for describing and controlling infrastructure would address the other cost issues of “do it yourself” development and make it easy to integrate in a standard way with other DevOps tools.

The time for “do it yourself” tools for DevOps is over. In the same way that no one would consider writing their own backup tool today (remember the good ole days when people did their own backups with tar files?), writing your own DevOps automation tools is usually not the best approach.

About the Author/Joan Wrabetz

Joan Wrabetz is the CTO for QualiSystems. Most recently, she was theVP and CTO for the Emerging Product Division of EMC. Joan received her MBA at the University of California, Berkley, and MSEE at Stanford, and a BSEE at Yale. She has held teaching positions at the University of St. Thomas, St. Mary’s University and the University of St. Thomas, St. Mary’s University. Joan holds patents in load balancing, distributed systems, and machine learning classification and analytics. Her experience inclues: founder and CEO of Aumni Data, CEO of Tricord Systems, Vice President and General Manager for SAN operations at StorageTek, Founder and CEO of Aggregate Computing, Management and senior technical positions at Control Data Corporation and SRI International, Partner with BlueStream Ventures.
October 26, 2015
Open Source software license and security management with WhiteSource
With the growing speed and availability of open source components, it becomes easy to add features and integration of software with other components which makes software development easier. But there are a few points to be remembered while using any open source component.
- Security vulnerabilities
- Licensing risks of open source component.
- Outdated open source components.
The above are a very important part of the the software development life cycle to eliminate any discrepancies related to security or legal issues.

WhiteSource provides one fine platform to solve such issues without putting in much effort by developers, They can concentrate on core development instead of spending time on finding these issues which can be easily handled by WhiteSource.

WhiteSource is an open source management solution which does
- Open source licensing and compliance management
- Open Source security vulnerabilities alerts and management
- Executive dashboards, policy enforcement, and reporting
WhiteSource checks your software and generates open source inventory report, including detail from open source. The WhiteSource gathers information on open source components and they keep the inventory updated.

WhiteSource covers almost all commonly used languages and provide detail report, This tool can track all your open source components used knowing or unknowingly within your software.

It sends alerts for any potential issue observed in open source component used by software. It does check for outdated/expired component, It provides detail on security issues found in any opensource component.

WhiteSource does not store (keep track of) any software component which is not open source, this means it’s safe and your code will not be touched.

CI tool Integration (Jenkins)

The best part of the tool is that it has plugin available for the widely used CI tool – Jenkins.

WhiteSource Jenkins plugin is the best and easy way to integrate with WhiteSource to run the checks during build and integration phase in an automatic way.

Its very easy to use, not even just for Maven project also for free style projects.

Easy to configure and use within project. Only token needs to be added and plugin automatically takes care of everything.

Multiple options are available at job level to define the project and modules to be included.

Logs are pretty descriptive when plugin start processing in Jenkins job.

WhiteSource basic principle talks about

Managing the component vs governing the component.

Developers can leave the managing part up to WhiteSource and only concentrate on the issue of governance at the component level in software.
September 18, 2015
Tool Development – In-House or Ready made
Tool development and adoption

The current pace of software development cannot manage its speed without the automation.

Automation is the most important element in order to achieve agility in delivery of the product. Every part of the software development life cycle needs tools to perform their action automatically. These phases could be coding, code review, build & deployment, environment management, resource assignment, notification and many others.

There could be 2 options, which a team can opt for:
- Use a third party tool
  - One can select the tools, which are available in market, either open-sourced or free. You can even buy enterprise solution if needed.
- Build an in-house tool
  - Tool can be built or developed in-house for the consumption as well.
Lets take look different aspects of choosing options
- Features
Each organization and team may have different features for different use cases. Some time it makes more sense to build your own tool just for your need rather adaption of a third-party one for which most of the features are not going to be used.
- Time for on-boarding
Time is definitely a big factor here, if one thinks of developing in-house tool and use it then this will definitely take time. If, need of tool is not urgent or critical, in house development option could be considered.

Third-party tool can be immediately on boarded and there won’t be much delay other then some logistics reason.
- Effort and Resource
If the tool is complex, its not easy to build, one will need resources and lots of time to build it and then next challenge is implementation.

Above effort can be reduced by adaption the tools which is available in the market. There are chances that other users are aware of the tools and training time could be reduced.
- Cost
Lets discuss one more important part, which is the cost. Yes, money is also one of the biggest factors on deciding what to opt for. There may be good options to choose from free and open source tools. But if enterprise tools selected, then cost may incur.

You will need a dedicated team and resources to build the tool with in organization.

Its hard to decide if in-house tools will be costly or enterprise. Decision has be to taken by considering long term investment and return.
- Support
Enterprise tools usually come with a proper support. This is really important factor if tool is very critical. Open source tools may not have enough support, as it is community driven effort. In-house tools may need resource to provide support and training in the team/organization. Even bug fix needs to be taken care under support category.
- Adaption/Expertise
In-House tools are highly customize as per use case and will need proper training for adaption with in organization. In case of thirdparty tool, as I mentioned earlier there are chances that other users are aware of the tools and training time could be reduced.

So, Adaption of tool is not an easy task. Decision has to be taken with a very strategic thought process.

If tool is complex then it is definitely not a part time task.

One more important thing to consider is if the team is trying to build in-house tool, which is going to be major business for somebody else then it has to be developed with proper planning and priorities, otherwise there are high chances of failure.

Please Note- I am not considering or referring to any tooling like script or some simple UI dashboard.
September 9, 2015