devopsy.kinsta.cloud

Tag: open source

  • 5 DevOps Techniques to Improve Software Hygiene

    5 DevOps Techniques to Improve Software Hygiene

    Thinking about frequent food contamination outbreaks, perhaps the old adage, “You are what you eat,” should be modified to, “You are what you eat—as assembled across an unknown supply chain.” Even foods advertised as fresh and healthy can be quite the opposite. And it could be because of just a single unhygienic practice hidden within the food production life cycle.

    It’s not unlike the issues facing modern software development. Now with the advent of open-source, cloud computing and component-based designs, the succulent software morsels we deliver can be fouled by a range of contaminates. And while not as a physically debilitating as a case of gastric flu, the impact on business can be extremely severe, such as major security incidents and compliance breaches—the E. coli of digital software production.

    The good news is that IT organizations can take effective steps to mitigate the risks. Much like food processing, software contaminates can be introduced anywhere code and data is handled and stored—from requirements and coding to testing, release and operations. This means all stakeholders must take responsibility and be held accountable for software quality. To that end, here are five good practices DevOps practitioners can use to improve software hygiene:

    Thoroughly wash test data before handling – Creating, maintaining and provisioning accurate test data is one of the most time-consuming and resource-intensive challenges in continuous delivery. It’s also fraught with business health hazards if teams fail to protect personally identifiable information or continually rely on data that’s well past its use-by date. With public cloud services providing convenient platforms for testing, ignoring these issues will only increase the risk of major compliance breaches. It’s important, therefore, to supplement data migration with fully automated methods to mask and subset sensitive data. Additionally, by continually enriching virtualized or emulated services with realistic test data, teams have a repeatable method for improving the quality and efficiency of testing.

    Pay special attention to open source freshness – Open-source software has become a large contributor to the portfolios of many organizations. But just because something is “free” doesn’t negate an organization’s responsibility for due diligence, including understanding total cost of ownership and mitigating security risks. Even though open-source projects have active communities, that hasn’t stopped code pathogens lying dormant for years (for example, Heartbleed went unnoticed for 2.5 years).  With open source, the onus is on development to retain code “freshness”—something that might be difficult if teams are constantly being pulled onto different projects, or if thorough risk control management isn’t a core competency.

    Don’t leave software lying around for too long – Just as many foods spoil quickly, software release bottlenecks can quickly leave a sour taste for business. Like a truffle imbues a marvelous aroma, modern digital business must be flavored with a continuous stream of application updates. And, since windows of business opportunity close quickly and application lifespans are as short as days, it’s critical any deployment delays are removed. Letting software linger in the release queue also introduces other hygiene issues—for example, teams putting off documentation or code-refactoring because they know they can always get back to it later. Inevitably they never do, and when the code finally gets deployed it’s unclean or laden with defects and bugs.

    Set up a “health inspection” SWAT team – In the traditional “software factory,” application performance management, security auditing and compliance checking often comes late in the software development cycle—leading to delays and conflict. DevOps, with its focus on team collaboration and continuous feedback, aims to rectify this by embedding these practices much earlier. But when resources are limited, it’s not practical to assign a security or operations professional to every agile team; it just won’t scale. What’s key, therefore, is to take a more pragmatic approach; developing teams of specialists and repeatable automated practices others can leverage to remove “bad smells” from code. This could involve:

    • Regular education on web application cross-contamination issues and modern API security techniques
    • Moving application performance management into pre-production to improve quality
    • Auditing services to regularly check composite applications assembled from third parties and open-source software
    • Automatically invoking application security testing before and after release and deployment
    • Methods to automate testing as requirements are modeled and changed—immediately linked to correct data and expected results
    • Scoring mechanisms to highlight security and risk problem areas—all bubbling up to a team and divisional level

    Work with your suppliers – In the rush to embrace modern cloud architectures for application scale and resilience, teams often forget that even the most robust platforms can succumb to problems. Savvy teams understand this, working with their cloud partners using modern monitoring and analytical methods to quickly detect and respond to many complex issues well beyond the scope of traditional rules-based methods and slioed tools. By using a design-for-failure approach, DevOps teams understand that no platform is infallible, preferring instead techniques that quickly anticipate and contain inevitable failures to keep the digital business running.

    Even the tastiest of food can be toxic, and it’s the same with software. However functionally rich our software creations appear to be, contaminates lurk everywhere within the software pipeline. Use DevOps techniques to pinpoint and eradicate “digital spoilage” quickly, and avoid making the business and customers ill.

  • 3 Simple Steps to Rugged DevOps 101

    3 Simple Steps to Rugged DevOps 101

    As the CEO of WhiteSource, I regularly consult enterprises about building and enforcing their open-source security policies.

    In the course of my consultations, I discuss open-source security protocol with many software companies and enterprises, and I’m often baffled by the fact that many organization aren’t boosting their software development performance and speed by bringing their development and operations teams together via DevOps. In fact, only 25 percent of enterprises are currently doing DevOps. I mean, if you were a CTO and someone said you could make your software development 200 times faster and reduce unplanned work/rework by 22 percent, wouldn’t you jump at the chance?

    Now, I know DevOps still is not being implemented even though it has proven to improve deployment rates, so I shouldn’t be surprised that security isn’t joining the DevOps party. But I am. Just imagine the benefits of giving security the DevOps treatment. There’d be no more (or, at least, significantly fewer) last-minute security issues, no more unrealistic security policies, and engineers, IT and security professionals who actually understand each other and improve their own processes to work better together. This is the essence of rugged DevOps.

    Implementing rugged DevOps is a huge decision for any enterprise, and it requires a lot of planning and time to implement. However, you don’t need to completely remodel your organization to start enjoying some of what rugged DevOps has to offer.

    So, what can you start doing today?

    Shift Left Your Security

    DevOps is all about shifting left security to find security issues as early in the software development life cycle (SDLC) as possible. The earlier you find an issue, the cheaper and easier it is to fix.

    So, how can you shift left your security? Start by integrating security tools into your continuous integration (CI) process to find vulnerabilities as soon as they’re added to your build and sometimes even your repositories. Tools exist that can integrate with your build tools and identify potential issues in your build.

    Also available is a browser plug-in that allows developers to detect security vulnerabilities while they are searching for open-source components online. This tool helps developers say no to vulnerable components long before downloading or integrating them with their code.

    Shifting left security is the hardest part of any enterprise’s rugged DevOps journey. Yet by taking some small steps, you can start to enjoy the benefits of DevOps with a twist of security.

    Adopting a Micro Approach to Security

    Just as operations has adopted a DevOps mindset to understand and become involved in development, it’s now security’s turn.

    Security needs to stop being on the outside of development, looking to control it through detailed security policies. Instead, it needs to take an active part in it, steering it toward security. Security can do this by focusing on understanding development and deployment processes, and searching for possible quick wins.

    From my own experience, every time a security team takes the time to understand the peer code review process, small changes are made with significant contribution to code security.

    I also often notice that security teams are unaware that some developers may still use the old “copy and paste” method in using open-source components. This makes it impossible to track known open-source vulnerabilities. Once security teams understand this, they can improve guidelines to ensure they are not blindsided.

    The good news is you don’t have to overhaul your whole organization to give security a micro-makeover. Your security team simply needs to start getting into the finer details rather than planning long-term security programs and road maps.

    Speaking the Same Language

    A good sign that an enterprise is doing DevOps is when developers and operations call software issues by the same name. This means the two teams have defined their issues and objectives together, and are working toward joint goals. The same is 100 percent true for rugged DevOps.

    If development sees a problem in terms of unplanned work, operations sees a glitch and security sees a vulnerability, collaboration will be very difficult. Introducing a shared vocabulary for issues throughout software development is an effective way to get your professionals on the same page.

    With this shared vocabulary, development and security can sit together and define shared key performance indicators (KPIs). For example, development’s goal of faster deployments can be linked with security’s aim of reducing mean time to release (MTTR). Once each team knows what the other wants to achieve, they can understand how to help each other.

    At the end of the day, security is more likely to be taken seriously if it is understood. And this is key. With the typical enterprise ratio of 100:10:1 development, operations and security professionals, security needs all the friends it can get.

    Ready to Try Rugged DevOps on for Size?

    As you can see, you don’t need to turn your enterprise upside down or even have a rugged DevOps team to start getting some of its benefits. Just follow these three steps, and your enterprise can get a taste of what rugged DevOps has to offer.

    So what about you? Are you ready to take rugged DevOps for a test drive?

    About the Author / Rami Sass

    Rami SassRami Sass is an experienced entrepreneur with deep background in R&D and product management. At Eurekify. and later CA, became an expert in designing and implementing complex security management and compliance software systems, and in delivering them to the market. Currently he is co-founder and CEO of WhiteSource.

  • To Be Continuous Podcast: Have We Forgotten How To Code?

    To Be Continuous Podcast: Have We Forgotten How To Code?

    Welcome to To Be Continuous, a show about continuous delivery and software development, hosted by Heavybit members Paul Biggar, founder of CircleCI, and Edith Harbaugh, CEO of LaunchDarkly.

    In this episode, Paul and Edith discuss the fallout after the widely covered “left-pad” incident, and while they agree that these sorts of moments move the entire open source community forward, they wonder: Have we forgotten how to code?

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

    Edith: Hey, Paul. So, somebody unpublished a module called left-pad and the internet basically exploded. And now it’s been a couple weeks since then, so there’s a lot of different topics to cover in terms of what this means for open source, whether it means that people have forgotten how to program.

    Paul: So LaunchDarkly. Or, I’m sorry, the left-pad. I’m obviously looking at my own t-shirt.

    Edith: You’re looking at your LaunchDarkly t-shirt?

    Paul: The left-pad incident was pretty interesting and one of the things that we did when coming up to this was just, like, looking at all the Hacker News discussions and comments on it.

    And there’s wildly varying positions on what this means for open source, what it means for whether people can program, what it means for, like, about the Node ecosystem. So to kick this off, why don’t you give us a recap of the entire incident?

    Edith: Yeah. So, in short, a programmer had a module called Kik, K-I-K. Which is also [the name of] a very popular messaging app. I mean, even I’ve heard of it and I’m not a teenager.

    Paul: The Kik lawyers contacted the dude. Said, “Please take down your module, change it.” And the programmer said, “No. I basically don’t believe in copyright laws.” So then, the Kik people contacted NPM. The NPM people took down the module called Kik. And the guy, in I’d say, kind of a fit of pique, said, “Okay, you took down my one module, I’m gonna take down all my modules.” Basically, I’m taking my marbles and going home.

    So, he took down all of his modules. One of which turned out to be an incredibly popular module called left-pad, which did basically what the name implied. It sorted left pads. And without this in NPM, the quote I read was, “Builds all over the world started to fail very quickly.”

    Paul: So as I understand it, left-pad was used by another module, which was used by another module, which was used by something core, or like, this incredibly popular module—

    Edith: Yeah, it was basically turtles on top of turtles on top of turtles, and at the bottom turtle was this guy who—

    Paul: Took his marbles and went home.

    Edith: Yeah, or yank the bottom Jenga, basically.

    Paul: Gotcha. And so all the builds started to fail. People’s deploy started to fail. And people got pissed.

    Edith: People got pissed because they didn’t even realize that they had this dependency. So what happened was NPM basically republished it. They said that, even though you’re the original publisher—

    Paul: So there was a lot of outcry on the internet and then they republished it.

    Edith: Just basically said, “You don’t have the right to un-publish this.”

    Paul: Gotcha. So, um, but they had an Unpublish button, as I understand it. So he did something that was built into NPM to remove a module.

    Edith: Yeah, and since then they have tightened their rules a lot. They basically said that this should be something that’s used extremely rarely, if at all, and not something you can just do capriciously.

    Paul: So one thing that’s interesting about the NPM ecosystem, and the Node ecosystem in general, is they’ve had a bunch of things like this. Things that are security-related, or that are drama-related.

    And people have repeatedly come out and say, “Oh, no, JS is a tar pit, or ghetto,” or whatever it is that people use to describe poor ecosystems, that normal programmers don’t know how to code, and so on, so on.

    And what it looks to me like is, you know, each of these incidences brings the Node ecosystem quite a bit forward. To the point that, I mean Node is relatively new, it hasn’t had 15 years before prime time in the way that Ruby or Python did, or 20 years before it got big, and it’s a real, kind of bottom-up thing.

    I mean, if someone built it and there were some steroids and then someone else took over, and then NPM took over, and then. It’s this sort of weird language from the ecosystem perspective. It didn’t have the same advantages that, like, Java had, or that C or C++ had, in order to get to maturity. And so each of these incidences propels it closer to maturity.

    Edith: Yeah, I compare it somewhat to when electricity first started coming out. And then you were just working through all the issues that could happen. Like, for example, when a power line went down or a transformer blew.

    Like, you work through, Okay, what are our points of failure? Let’s not make that a point of failure again.

    Paul: Hmm. So, NPM changed their policies on this basis, right?

    Edith: Yep, so now you can’t have an individual contributor be able to unpublish, even if they originally published. Now you have to contact them, and it’s much more stringent.

    Paul: Gotcha. The response, despite people being … Well, people were annoyed at their response.

    Edith: It seems perfectly rational to me.

    Paul: Oh, I think it seems perfectly rational. This is the thing about the in trend. There’s always some set of people who are annoyed at everything you do.

    Edith: Well you know, the internet is full of billions of people. I mean, there’s gotta be some sort of standard deviation, or otherwise it would be a very boring internet.

    Paul: Right, right, and this is why there’s always haters on Hacker News. No matter what you do. If you do it one way, there’ll be one group of haters, if you do it another way, there’ll be a different group of haters.

    And so, with left-pad, there were people who were annoyed that NPM retroactively decided that they had ownership over their namespace, which previously, they had sort of gifted to people in the community, the first people to take the namespace.

    Edith: You mean the original thing about Kik?

    Paul: So there’s that, but there’s also the left-pad. They took away the sort of autonomy of the left-pad offer.

    Edith: I read a good article that basically says part of open source is, if it truly is open source, do you maintain the rights to it? Or is it a community project?

    Paul: Hmm. The traditional way of deciding that sort of ownership was the fork. That you could go, and you could fork, and when you forked, you weren’t necessarily entitled to the same name, you weren’t entitled to the same trademarks. When Debian forked Firefox, they called it Iceweasel.

    When Jenkins was forked, or Hudson was forked, it became Jenkins. GCC got forked. They all got new names. But what was the fork here, it wasn’t even a fork. It was a republish of the same thing, the same software, in a namespace that the original author didn’t control.

    So typically you’d own the URL, you know, if you have a software library, you’d own the URL. And they did own, in some sense, the URL within NPM, or the name within NPM’s space, and NPM, the sort of owners of that namespace, overrode it.

    Edith: I think they did what was necessary for good order.

    Paul: Sure. I completely agree, I think that was a good decision.

    Edith: I mean, so to take this to the logical conclusion, what if you had a module named left-pad, and you decided that, like, as a prank you were going rewrite it to be right-pad? Like, sure, that’s … Is that within your rights? Kind of, but it’s a real jerk thing to do that you probably want to prevent.

    Paul: This is kind of one of the dangers of the whole ecosystem around centralized package managers, of sorta trusted package managers, where there’s no actual trust involved. So, what I mean by that is what is published does not have any gatekeepers.

    Edith: Yeah, exactly.

    Paul: I mean, it’s great, it allows an ecosystem to grow much faster, but it has safety concerns because people generally don’t pin their packages to an exact version.

    Edith: You’re basically pinning it to a floating value.

    Paul: You’re pinning it to a floating value. And that floating value could change. There’s no guarantee of what a minor number means or what a major number means or what a patch number means or what a patch even means. There’s some sort of, like, general community guidelines in semantic versioning, but there’s no enforcement of that.

    Edith: Yeah, and I mean this basically goes back to the whole Cathedral versus Bazaar thing.

    Paul: Right, right. It’s very Bazaar. And intentionally so. It’s the thing that allows a community to grow, and is there a point at which open source communities need to, like, batten down the hatches to prevent that sort of behavior? Or prevent that sort of risk?

    Edith: Yeah, and it’s really interesting. I think this goes back to something we’ve talked about with Nadia Eghbal and Sean Byrnes a couple episodes ago about when you buy from a corporation, you have some sort of guarantee of standards that they publish somewhere. You know, this is our guarantees versus with open source, you don’t normally have those same sort of guarantees.

    Paul: Even when you do, it tends to be—

    Edith: There’s no enforcement mechanism.

    Paul: Right. So there’s no enforcement mechanism in the Bazaar.

    Edith: Well, there’s no, um … Like, so with a company, if a company has said, “Okay, we’re gonna release twice a year and it’s gonna have this level of quality,” and they break that, you can walk with your feet or your money. If an open source project stops or does something that you don’t like, there’s very little enforcement end.

    Paul: Theoretically, you could walk. You know, you could fork the thing, but when you end up in an ecosystem that has massive network effects, and in the way that NPM does, you can’t walk with it. Because the pends is all transitive. The left-pad was, you know, a turtle way at the bottom of the stack.

    Edith: It was almost like a turtle hatchling.

    Paul: So, to fork left-pad, you would have to fork the entire NPM ecosystem.

    Edith: Yeah, and it’s not even. The fork is not the issue, though. The issue was that people were depending on it being in a certain place in a certain way. It wasn’t that it wasn’t forked, it was just like this entire structure at the bottom was gone.

    Paul: I guess what I’m saying is that if you get pissed off with a certain set of developers or a certain set of practices within the NPM community, because they’re so interlinked, you don’t have the traditional open source option of forking.

    Edith: Absolutely. Absolutely.

    Paul: You could rename it. You could pick a different library, but because of the way—I’m not sure if they still do this, ’cause I read something about it, but in NPM, it used to be that the version of the software that your library took was the version that library got. Do you know what I mean by that, okay. So let’s say there’s some software, let’s call it left-pad.

    Edith: Let’s call it right-pad.

    Paul: Right-pad. So, right-pad version one is being used by library A. And right-pad version two is being used by library B. In the Java ecosystem, and many, many other ecosystems, only one version of right-pad would be used.

    And I believe in NPM, both versions of right-pad would be used. So library A will use version one, and library B will use version two. Now that’s definitely the way that it used to be, I’m not sure if they’ve actually changed that.

    Edith: Yeah, I don’t know, but that sounds very messy, very quickly.

    Paul: So both options are terrible. And there isn’t a right way to do it.

    So, really, what it depends on. So, the NPM way of doing it, every library get its own version of the dependencies, is fantastic. Because it lets that library do what it actually intended to do under the covers.

    If, however, you start having an object that gets sent around, or that two modules are, let’s say it receives a, I think, an HTTP packet or something like that would be a good example. Let’s say you take an HTTP packet from one module and just hand it to another module, and they have different understandings of the shape of that object, or what functions you can run on that object, then that’s messy.

    But, on the other hand, if you override the version of right-pad that some other library’s using, you end up with all sorts of problems. This is a major problem in the, sort of the Maven ecosystem. And at CircleCI, we used Clojure, and Clojure is built on top of the Maven ecosystem, and we would have bugs where the library that we used.

    One library that we used had a dependency, and that was in the package file for another thing. And so, that’s the version of the packets that we used. So we would have to pick. And as a result of that, we have to pick the library that works. And, often, there isn’t a library that works for both, or there isn’t a, sort of subdependency that worked for both. So those are close to forked no matter which way you do it.

    Edith: Yeah, I mean, we ran into the same issues with our STKs. I mean, ’cause we have dependencies on other libraries that sometimes conflict.

    Paul: Right, disaster.

    Edith: On the other hand, I mean, the bigger point, I think, was. So there was an interesting backlash, I think, that everybody kinda projected what they wanted on the NPM thing.

    People said, Oh, people don’t know how to program anymore. You know, why do you even use what they called left-pad? You know, why don’t you just grind your own wheat and make your own bread from scratch and eat it at lunch also?

    Paul: I have no sympathy at all for this view of the world.

    Edith: Uh, that you should make everything from scratch? Or—

    Paul: That, “Oh, we’ve forgotten how to program because we need left-pad.”

    Edith: Yeah. The fact that we have modules available that make it easier and easier and easier to program is a good thing.

    Paul: I think it’s kinda different to that. I think it’s more of a curmudgeon view of the world. It’s a get-off-my-lawn—

    Edith: Wait, that you’re the curmudgeon?

    Paul: No, the people who complain, “Have we forgotten to program anymore?” I think it’s a no true Scotsman kind of argument. Real programmers know how to write their own left-pad, real programmers write in statically typed languages, real programmers write in C, real programmers, and I’m going back in time here, real programmers write in Assembly, real programmers hand-code their. Tweak the needles on the.

    Edith: They do their own garbage collection.

    Paul: Oh, and it’s garbage collection, what is this? Garbage collection is for amateur coders, right? I mean, you could just as easily have written, have we forgotten how to manually allocate memory?

    Edith: Or, you might as well say, like, nobody knows how to make their own transistors anymore. I mean, like, the entire computing revolution has been that you no longer have to assemble a computer by hand.

    Paul: Right. And each layer of the ecosystem allows a vastly larger number of people to take part in it. So I think the thing that we’re seeing now. This has been happening for five or 10 years, but what’s getting really, really big now is people who only know how to front-type program.

    People who only know Javascript and HTML/CSS, and they go to boot camps and they come out, they maybe have some, like, vague real understanding.

    And they call themselves coders, and we, the real programmers, who know how to write a quick sort, and who know how to write left-pad, we don’t welcome them to our community. And frankly, I mean, I have felt this in the past, I have since changed my mind, but it’s a very, very common perspective.

    This podcast is brought to you by Heavybit, a program that helps startups turn products loved by developers into successful businesses. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

  • Open Source Is the Secret Sauce of DevOps

    Open Source Is the Secret Sauce of DevOps

    DevOps is a relatively recent phenomenon—especially compared to the world of open source. While DevOps and open source are two entirely separate things, though, the reality is that it’s difficult to separate the two at this point. Many open source projects rely on DevOps tools and principles, and DevOps depends heavily on open source applications as both the glue that binds it all together and the engine that keeps everything moving. A new report from devopsy.kinsta.cloud, “DevOps and Open Source,” digs in to understand the symbiotic relationship driving the next generation of IT.

    “DevOps and Open Source” examines the role of open source in DevOps, whether DevOps can succeed without open source, the unique challenges of leveraging open source tools, and the benefits of open source partnerships with large corporations such as Microsoft and IBM. The report also includes a list of some of the most widely used open source tools for DevOps, including Chef, Puppet and Docker.

    Leveraging open source tools gives organizations and developers much more flexibility and control. Because the underlying code is available, it provides an opportunity to customize it to fit unique scenarios or to create the necessary APIs to integrate the open source software with other tools. The fact that there is no single vendor that “owns” the software also means that organizations and developers can build on open source tools with the confidence that the apps will not arbitrarily disappear one day.

    You can definitely develop or use open source applications without embracing DevOps, but is it possible to do DevOps effectively without using open source? “Maybe,” says Randy Kilmon, vice president of Engineering at Black Duck. “But who would want to do it that way? With so many great open source tools and components out there, deliberately shunning them would be a mistake. Besides, there is a piece of open source somewhere in your stack, whether you know it or not.”

    That statement seems to be more true with each passing day. The growing momentum of DevOps and the mainstream acceptance of open source software form a powerful partnership that is transforming how applications are developed, deployed, monitored and maintained.

    “Organizations want to advance their technology practices and stay ahead in very competitive industries, and do so in a mindful way,” explains Jose Miguel Parrella, senior product marketing manager of Cloud Platform Marketing for Microsoft, in the report. “DevOps can help reconcile the organizational needs, add value to the business, streamline the IT value delivery process and leverage open source innovation.”

    The report sums up with this: “The simple fact is that the fundamental concept of DevOps—the culture shift organizations embrace to change how teams cooperate and collaborate so that projects can be delivered more effectively and efficiently—more or less requires a dependence on open source tools. A DevOps environment is too fluid and evolving to sit idly, waiting for a commercial vendor to develop a product with just the right set of features and capabilities.”

    The report is available for download here.

  • Enterprise Cassandra Deployments

    Enterprise Cassandra Deployments

    Successful Cassandra deployment in the cloud takes a certain amount of skill and knowledge. In this blog I will share best practices for a successful Cassandra deployment in the cloud such as Amazon Web Services (AWS) and Google Cloud Platform (GCP). I will also discuss how you can protect and recover the data in your Cassandra cluster when deployed in the public cloud.

    Cassandra Deployments in the Public Cloud

    There are two main ways to have successful enterprise Cassandra deployments in AWS:

    • Use a ‘managed’ Cassandra deployment. This is a reasonable approach; the only downside is the inability to customize data placement beyond what is typically provided by the vendor.
    • Manage the cluster yourself, if you want to have full control over your Cassandra deployment and customize it to scale and perform according your business needs.

    Please refer documentation from Datastax or Apache Cassandra for detailed best practices for Cassandra deployments. The following best practices are reiterated here to simplify deployment of a scalable Cassandra cluster in AWS.

    Storage

    Both AWS and GCP offer two types of local storage options for their compute instances. For AWS, the options are Elastic Block Storage (EBS) and Ephemeral Storage. In GCP, the options are Persistent Disks and Local SSD. Both options have their own trade-offs. Pick the one that best suits your deployment.

    Persistent Storage

    EBS volumes have performance characteristics similar to network storage such as a NAS or SAN. Because storage from EBS volumes is multitenant in nature, it is not suitable for distributed, log structured databases such as Cassandra. If you want to ensure reliable performance through EBS volumes, use “EBS optimized instances” with “provisioned IOPS.” Since the IO traffic to EBS volumes goes over the instance network, EBS optimized will provide reliable performance, but does not guarantee any increased performance. To get the most performance out of EBS volumes, use instances with multiple disks and separate the volumes used for “Data” and “Commitlog.”

    If you have to use EBS Volumes, go with “EBS Optimized Instances,” with “Provisioned IOPS” and split data and Commit Log on different volumes.

    Ephemeral Storage

    Ephemeral storage is a great option to use for downstream Cassandra environments such as test/dev and staging. Since ephemeral volumes are typically SSDs, there is no need to separate the data and commitlog into separate drives. To optimize performance, choose EC2 instances with multiple ephemeral storage drives and stripe them together into one logical volume. Send data and commitlog to the logical volume. Remember that when you stop the EC2 instance, the data in Ephemeral storage will be deleted.

    Stripe all Ephemeral drives into a single volume to get maximum performance.

    Data Distribution

    Cassandra uses Snitch to determine the topology of the cluster. The Snitch is also used to determine the data center and rack for each node in the cluster. Replication strategy is used to determine the placement of data across the different nodes in the cluster.

    AWS

    1. EC2Snitch works well for single region deployments.
    1. Ec2MultiRegionSnitch works well for cluster distributed across multiple AWS regions. Please note, Multi-DC, Active-Active configuration makes your cluster resilient to region failures and for multi-dc cluster, use “local quorum” to improve performance.

    Google Cloud Platform (GCP)

    1. Use GoogleCloudSnitch for Cassandra deployments in GCP.
    1. GoogleCloudSnitch treats regions as Cassandra data centers and availability zones as racks.

    Other Features

    Both AWS and GCP offer a series of operational capabilities that seem to make it easier to maintain high uptime on Apache Cassandra cluster. These capabilities have to be chosen carefully depending your deployment needs.

    1. Load Balancing: Network-level load balancing service is offered by both AWS (Elastic Load Balancer) and GCP. It is not recommended to put a load balancer in front of Cassandra. It is better to use a client connector that can handle this, consider open source utilities such Presto and Astyanax
    1. Autoscaling: Both AWS and GCP offer Autoscaling facility for compute instances. However, although this functionality looks very enticing, putting all C* nodes in an autoscaling group will not produce the desired result. Instead, create a separate autoscaling group of ‘1 node’ for every node in your cluster. This will ensure that anytime a node goes down, it is automatically brought back up. This will ensure the cluster data placement is not disturbed when nodes go down and nodes coming up do not cause excessive data movement.

    Scalable Backups and Reliable Point-in-Time Recovery

    Backing up your data is a must-have for enterprise organizations. The impact of data loss is so high that no enterprise wants to risk relying alone on replication. Protecting data in a public cloud environment may seem daunting, but there are several options available that can make this easier compared to an on-premise deployment. A simple option may look like one of the native snapshots:

    Storage Snapshots

    I have seen few customers use snapshots of EBS volumes as a way to protect the data in their cluster against logical and/or operational errors. This solution will work but with some severe limitations. On top of the overhead of maintaining the scripts to take snapshots, there is a large overhead in storage costs. Taking a snapshot of volumes does not allow for incremental backups of your data. This causes an exponential bloat in the amount of data stored in snapshots, leading to high cost of the backup solution.

    Amazon S3 or Google Cloud Storage

    Using an S3 bucket as the secondary storage enables enterprises to use low-cost, highthroughput storage, while reducing overall operating costs for storing backup data. Here are a few recommendations when using S3:

    1. S3 Region: Amazon S3 buckets are region-specific. A bucket created in one region will provide better performance characteristics to other infrastructure in the same region. Subsequently, it is important to ensure the S3 bucket used as the secondary storage is in the same region as the production database being protected and the Datos IO cluster.
    1. Storage Class and Lifecycle Policy: Amazon S3 allows users to create lifecycle policies on buckets. These policies dictate the performance and response time characteristics of objects in the bucket. STANDARD_1A is more suitable for longer lived and less frequently access data, and is not suitable as secondary storage. Additionally, do not turn on any lifecycle policies on the buckets used for the secondary storage. All buckets should be in the standard storage class.

    Conclusion

    As enterprises leverage the agility provided by public cloud environments, it’s important to understand the various facets of Cassandra deployments to ensure the efficient use of your money and time.

  • DevOps Chat: Mike Pittenger, Black Duck Software on Open Source and DevOps

    DevOps Chat: Mike Pittenger, Black Duck Software on Open Source and DevOps

    I recently had a chance to speak with Mike Pittenger, Vice President of Strategy for Black Duck Software. Black Duck is a company that I have been following for many years. They pioneered the idea of auditing open source usage to ensure compliance with licenses and such. Of course over the years they have expanded into other areas as well, including security, DevOps, containers and more. Mike and I discuss Open Source and DevOps.

    Mike and I had a good conversation I hope you will enjoy. You can listen below or follow along with the transcript below that.

    Alan Shimel:               Hi, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest on the chat is Mike Pittenger of Black Duck Software. Mike, welcome.

    Mike Pittenger:            Thanks very much, Alan. Nice to be here.

    Alan Shimel:                So, Mike, our audience, you know, I’m sure many people in our audience have not met you before, unless you’ve invited your relatives. But can you give us a little background on who you are, Mike, and your role with Black Duck?

    Mike Pittenger:            Sure, sure. So I’ve been in the software security space for about 16 years. I started with @stake back when it was a leading software security consultancy. I ran the product team there, and then when Symantec acquired @stake I spun off that team to form a company called Veracode. I stayed there for a couple of years and then started consulting work with Bit9, Digital Guardian, BeyondTrust, Coralogix.

    And Black Duck was a customer of mine – a client of mine – about two years ago and we were involved in a discussion of product enhancements and so on. And I came back to them about a year ago. They called me back in for another project and I found the opportunity so interesting that we – I came on full time to head up their security strategy.

    Alan Shimel:                Very good. And Mike, believe it or not there may be some folks in our audience who aren’t familiar even with Black Duck.

    Mike Pittenger:            That would be hard to believe, Alan. [Laughs] We’ve been around since –

    Alan Shimel:                A long time, I know. I’ve been writing about you all for a long time. But that being said, just in case let’s give them a little background.

    Mike Pittenger:            Sure. The company is about 13 years old and what we’re very good at is looking at source code or binaries to identify the open-source components that are used in that. Once we’ve identified those we can tell the customer anything they want to know about because we track over open-source projects and we’ve been doing it for about 13 years.

    For the first 10 or 12 years of the company’s life, the primary interest in this was the people would run our software internally in order to determine the open source, but they were interested in it because of license compliance. They wanted to make sure that they weren’t using reciprocal or restrictive licenses like GLP code and _____ distributing; something that might put their own IT at risk.

    About five years ago we started adding security information from the National Vulnerability Database and a year ago we came out with a product specifically focused on security. It’s a big deal because while license compliance is still an issue for risk managers, open-source software, because it’s become so ubiquitous, is also a concern to security people.

    There are – there have been over 4,000 new vulnerabilities – excuse me, over 6,000 new vulnerabilities reported in the National Vulnerability Database just in the last two years. So unless people are aware of the software they’re using and the components they’re using in that software, they’re unable to protect themselves from these vulnerabilities and that’s where we come in.

    Alan Shimel:                Excellent. So Mike, I wanted to talk to you a little bit today about open source. And certainly open source vulnerabilities and scanning are big topics today, especially when we talk about that in the context of containers. And I know Black Duck is actually doing some work around container security and vulnerability scanning, etc. But I wanted to just take it up another 50,000 feet and talk overall open source’s – open source’s role in this whole DevOps revolution/evolution, if you will. Can you talk about that?

    Mike Pittenger:            Sure. Yeah, so I mean the big thing, of course, is that a lot of these particular – with the popularity of containers, a lot of those are running on a lightweight version of Linux, and of course that’s open source. Where we see the risk with that is not in using Linux, it’s whether an open-source operating system or component is more or less secure than a commercial component. It becomes a religious argument and you can argue it until the end of the day.

    The fact is you just need to have awareness of what you’re using and monitor that closely. So we did an informal study of the containers on Docker Hub and found that most of them, the majority of those, had security issues with them. And it was easy to see how this happens because containers are constructed just like software is constructed. People are pulling in often open-source components and they build a LAMP stack and add their application to it.

    If they’re going to deploy a new application they may strip off the application layer, maybe strip is right down to the Linux core again, and then build it back up. But if they’re reusing these components and a vulnerability happens to be in there from the beginning, or one is disclosed after you’ve built that initial container, it’s just going to propagate itself. So people are justifiably concerned, I guess is the right word, about the security of these.

    And from our position, it’s really more about understanding the hygiene of the container, understanding what you’re using, and then monitoring that closely because with 6,000 new vulnerabilities in a two-year period, clearly your security posture can change without you doing anything.

    Alan Shimel:                Absolutely. Mike, what we’ve seen in – you know, it’s funny. I was just going over the results of a survey we’re going to be releasing soon about DevOps tools adoption. And it was split between large organizations, over 10,000, and then about an equal number of under 200. So sort of dumb-belled with not a lot in the middle. But fully 25 percent or more, of all of the tools that these people were bringing in, whether they be – let’s call it a legitimate software supply chain or in through the back door, if you will, shadow – 25 percent of them or more were open source.

    Mike Pittenger:            That’s actually lower than what we see.

    Alan Shimel:                Really?

    Mike Pittenger:            So we have a portion of our business, Black Duck On-Demand. So we’re often brought in during an M&A transaction. So if I’m going to buy your software company, I’m going to “Black Duck it.” They use it as a verb. I’m going to Black Duck it to understand the risk associated or whatever risks there might be. And so these are commercial applications. You assume they have plenty of proprietary value because somebody else is interested in acquiring that company.

    And even in those cases we’re seeing that the code base, 35 percent is open source. If you’re talking about an in-house application that, say, a bank is running, they’re building the applications, consuming them themselves, it’s not unusual to see those applications comprised of 70-80 percent open source. And it only makes sense that they’re doing that.

    I mean, open source is saving them from having to build this functionality from scratch, so it’s providing critical functionality without an acquisition cost. So it’s shortening the time to market and it’s lowering the development cost. It makes perfect sense that they’re doing this.

    Alan Shimel:                Got it. I’m surprised to hear. I thought 25 was a big number. You’re saying it’s a small number and it’s pretty significant.

    Mike Pittenger:            Yeah. It is a small – so if you look at those commercial applications – and we’re going to be publishing a report of our own pretty soon on those – but the average number of discrete open-source components in those applications is over 100.

    Alan Shimel:                Got it. Hmm…crazy. Mike, I want to just – believe it or not, as I told you before we started recording, our time here goes so quickly and we’re eight-nine minutes into our recording. I wanted to just quickly pivot into the whole container and open source and security around it and some of the things Black Duck is doing. Again, people in our audience may not be familiar. Would you give them a little – just a little taste of it?

    Mike Pittenger:            Sure. So we have partnerships with both Red Hat and Docker. In the Red Hat world we’re partnering with them for security on their open shift platform as a service and their container platform Red Hat Atomic. And the idea there is simply to be able to quickly assess the security of a container before you deploy it. So we can run our scan client as a container, pull in a Docker image from a repository and scan it before it’s deployed. Very simple.

    From our world, you can point Black Duck at a container, you can point it at typically a development process that’s integrated with a build server. But you could point it at a repository if you wanted to, and to us, a container is simply another code location _____ scanning. And when we’re looking at that, we’re not just looking at the components, we’re also looking at what makes up those components and are able to identify these down to the patch level.

    So instead of saying you’re using a bad version of _____ and Linux, we can actually look at each of the components and tell if those have been patched for reported vulnerabilities just to make the DevOps manager’s job faster, understanding what they need to worry about and what they don’t need to worry about.

    Alan Shimel:                Got it. Excellent. And you know, Mike, we only have about a minute or two left here, but obviously it’s a dynamic situation – the whole container thing, the whole what’s happening with DevOps and open source and all of this. If you can gaze into a crystal ball, where do you see us going in the next three to five years with this? Where do you see it heading?

    Mike Pittenger:            Well, I think the containers are going to obviously grow rapidly. We see some – it’s a hesitation in deploying, to switching over to containers in some worlds, but I think it’s simply trying to understand it better. An analogy might be people switching over to cloud computing a number of years ago. They want to understand both the benefits and the risks before they throw in all of their chips on it.

    So we see some of the very large companies embracing it aggressively, but a lot of the, say in the financial services industries, still testing it, playing with it, seeing – trying to decide when they’re going to jump in and whether they’re going to start in the shallow end of the pool or go right to the deep end.

    Alan Shimel:                Got it. Got it. Believe it or not, Mike, we’re at our time limit. I know it seems to go so quick. But I wanted to thank you for appearing today, and you know what? If people want to find out more about Black Duck, quick plug for their web site?

    Mike Pittenger:            Yeah, sure. It’s BlackDuckSoftware.com. We do provide a – there’s a free trial that will work on an application or on a container and you can sign up for it right on the web site. It’s www.BlackDuckSoftware.com.

    Alan Shimel:                Perfect. Mike Pittenger, Black Duck Software. Thanks for being today’s guest on DevOps Chat.

    Mike Pittenger:            Thanks very much, Alan. Nice to be here.

    Alan Shimel:                Okay. This is Alan Shimel for devopsy.kinsta.cloud.

  • Red Hat Launches Red Hat Open Innovation Labs, Introducing Collaborative Open Source Cloud and DevOps Residency Program

    Red Hat Open Innovation Labs is designed to enable customers to jumpstart innovation and software development initiatives the open source way

    AUSTIN, Texas–(BUSINESS WIRE)–Red Hat, Inc. (NYSE: RHT), the world’s leading provider of open source solutions, today announced the creation of Red Hat Open Innovation Labs, a consulting service that helps companies integrate people, methodology, and technology to solve business challenges in an accelerated fashion. As part of an Open Innovation Labs consulting engagement, customers will work collaboratively in a residency-oriented lab environment with Red Hat experts to jumpstart innovation and software development initiatives using open source technology and DevOps methods.

    Digitalization is increasingly connecting people, process, data and devices and enabling new business innovation platforms. Software is powering this shift and enabling companies to build innovation-driven advantages. The Red Hat Open Innovation Labs service helps customers rapidly develop and integrate applications using microservices, deploy them in containers, and deliver them using DevOps methodologies across physical, cloud and mobile environments that can quickly scale up or down on-demand. With Red Hat, customers can innovate with speed, agility, scalability and increased security.

    Red Hat Open Innovation Labs aims to help customers achieve this transformation, enabling them to:

    • Work on real business problems from day one, using Red Hat’s push-button infrastructure and automated development environments, teams can more quickly start development once the residency begins, enabling quicker time to value.
    • Learn how to take advantage of modern application development technologies and methodologies, including migrations, microservice architectures, container application platforms, DevOps, application and data integration, mobile and hybrid cloud strategies.
    • Re-platform existing applications for scale-out with OpenStack and public cloud infrastructures.
    • Bridge legacy and new application development efforts on one platform, helping teams design and develop solutions to modernize applications, or take on entirely new challenges.
    • Learn to innovate the Red Hat way by engaging with the Open Source community and collaborating in upstream projects.
    • Innovate onsite and virtually, meeting new requirements as a result of digital transformations, offering distributed teams access to environments in different locations. Red Hat provides a more secure cloud environment so authorized team members can work together, and development can happen on your site, in a Red Hat lab environment, or virtually.

    Availability

    Red Hat Open Innovation Labs is available immediately in North America, with full global availability planned within the year.

    Supporting Quote

    John Allessio, vice president, Global Services, Red Hat

    “We’ve heard from customers around the globe who want to get new initiatives off the ground quickly – whether they are talking about application modernization, or cloud, mobile and microservices – to help them meet their goals and stay ahead of competitors. To these customers, Red Hat Open Innovation Labs offers the ability to innovate faster and to solve business problems alongside Red Hat experts, and the open source way – through collaboration, and using DevOps methodologies and open source technologies.”

    Additional Resources

    Connect with Red Hat

    About Red Hat, Inc.

    Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As a connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT. Learn more at http://www.redhat.com.

    Forward-Looking Statements

    Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to the ability of the Company to compete effectively; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; delays or reductions in information technology spending; the effects of industry consolidation; the integration of acquisitions and the ability to market successfully acquired technologies and products; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; and changes in and a dependence on key personnel, as well as other factors contained in our most recent filings with the Securities and Exchange Commission (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations.” In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

    Red Hat is a trademark of Red Hat, Inc., registered in the U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. The OpenStack Word Mark is either a registered trademark/service mark or trademark/service mark of the OpenStack Foundation, in the United States and other countries and is used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

    Contacts

    Red Hat, Inc.
    Stephanie Wonderlick, +1 571-421-8169
    swonderl@redhat.com

  • To Be Continuous Podcast: Open Source Economics

    To Be Continuous Podcast: Open Source Economics

    Welcome to To Be Continuous, a show about continuous delivery and software development, hosted by Heavybit members Paul Biggar, founder of CircleCI and Edith Harbaugh, CEO of LaunchDarkly.

    In this episode of To Be Continuous, Edith and Paul are joined by Sean Byrnes, CEO of Outlier.ai, and Nadia Eghbal. The group discusses open-source economics and examines several potential evolutions of adding money to the open-source equation.

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

     

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

    Nadia: I like that open source is where I feel I spend time with a lot of creative people. It’s sort of like creative talent at its best. And it feeds directly back into the rest of startups and technology and everything else that I love.

    But it seems like everything starts with open source. Which makes it really magical.

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

    Sean: It’s the community. I enjoy learning from other people. I enjoy being able to find people I would never connect with that I have interests in common with. And a community that helps, because I consider open source to extend beyond just writing lines of code to sharing ideas, and sharing concepts and sharing solutions to problems, and while I might not always use those same solutions, I’m always inspired for new ways to solve other problems.

    Paul: So that’s super interesting, because nobody said that they like how it supports their Silicon Valley startup through sharecropping. Or … nobody said, I like how I get paid to work.

    Edith: Well, Paul, that comes later in the episode, but this would be a great time for our guests to introduce themselves.

    Nadia: I’m Nadia Eghbal. I’ve been writing recently and thinking a lot about how to support open source infrastructure.

    Originally, I have background in nonprofits and impact investing and working with foundations but most recently I was a founder of a startup and then I went into venture capital. And have sort of seen the system from all different sides and would love to marry together all those different interests and topics in which seems to happen in open source.

    Sean: Hey, I’m Sean Byrnes. I’ve been writing software most of my life. I’ve also been a founder of companies and an investor.  I would not consider myself an expert on open source and I don’t wanna claim that pedestal but I have, am, the maintainer of some open source libraries which seem to be pretty popular and I have contributed to others and I think that I’ve been lucky enough to know a lot of open source developers in my life which is, by no means, a majority of them but enough that I feel part of the community, at least.

    Paul: So, one of the topics that we were discussing just before the show started, is this idea of how open source developers get paid. Or, if open source developers should get paid.

    Nadia, sounds like you’ve been talking about this for a while or thinking about this for a while. Can you kick us off?

    Nadia: Yeah, actually, have a new thought on this topic from Michael Rogers whose, who runs Node.js Foundation. And he said recently, I think, on the last post I had written that everybody gets paid for open source. And I think that’s a really great way to start thinking about it vs. saying that nobody gets paid. Because in the end we’re contributing time to open source, right and in the end, somebody is paying you to have the time to work on open source.

    Whether it’s your employer and then you can work on open source full-time at your job. Or you’re full-time employed and that gives you the bandwidth to be able to work on open source on the weekends or whatever.

    So when I think about paying people to work on open source, I think people sort of like, bristle at the idea because they think that money is not involved in open source at all. And what I really liked about Michael’s point is that, in the end, money is actually really closely tied to open source and we’re just not talking about it.

    Sean: I get it. It’s interesting because my point of view is that it’s actually more nuanced, I agree with you 100 percent but I think that it’s very nuanced and that a lot of people do get paid for open source, it’s not even that we aspire to wanting them to get paid, right. ‘Cause there’s lots of kinds of open source. It’s funny ’cause on Medium, Nadia and I had an exchange.

    I kind of quantified it into the four categories of open source the way I see them. Which is by no means the universal standard but at least, how I see the world there, there are places where open source is part of your, a corporate product. It’s part of a whole.

    Like, LaunchDarkly. Edith’s company, has open source SDKs. It’s not because they’re doing anything grand, it reduced their sales friction if their customers can see the code before they integrate it into their app, right. So that’s one kind of open source.

    A second is what I call corporate open source, where there’s an open source project but there’s a company that sells services and products and stuff around it, right. So Confluence does that for Kafka. And Databricks does that for Spark. And MySQL was, I think, one of the first companies to really make a good model out of it. Red Hat, you could argue, had mixed success but that’s another kind where there’s a company whose corporate goal and sales is towards this project.

    There’s the third kind which I call, kinda like corporate marketing, which is you take a project out of a company and you roll it out like LinkedIn did with Kafka, where they’re actually, the company’s maintaining it they just make it available. So Google, the Angular and Facebook work react. And again there, I think, that it’s. You could argue why companies do this, some of ’em do it for recruiting, some of ’em do it for marketing. Some of ’em do it for because they’re very nice people.

    I think that the fourth category is where it’s a little bit weirder, where it’s like, what I call the community where somebody started a project. Maybe it’s an individual, maybe a few people, to solve a problem. And a lot of the most important open source products today started that way. Even Linux started that way, right. And it grew, and it got bigger, and eventually, then it became unclear because other people were using that project to build other companies and build other products, and make more money.

    And I think in that fourth category is where I think it’s less, because the first three categories is usually pretty clear who’s getting paid to do what and where the money’s coming from, but in the fourth category it gets very muddied and very quickly. Because if I start something, and the metaphor I like to use is, the open source library that I wrote was something called Likely.js which is a recommend ender system for no JS where you can, like Amazon product recommendations. And I know that there are people in the world that are using that as part of companies. And those companies are obviously making money because it to recommend products, right. And so, the question is, you know, so in that world, do they owe me anything for creating that which is underlying their products? And then, in turn, what do I owe the projects that I build Likely on top of? And then where does the flow of economics in that world go?

    Paul: So I have an interesting view on that. Years ago, I got involved in this project called PHC, which is a compiler for PHP. And there was a couple of guys who had start this and I joined a year later. And when they started it, they made it GPL. When I joined, I argued, we should change from being GPL to BSD because if someone comes along and uses that technology to build something that’s cool, I would rather that happen than not now happen and it might be that if was GPL that it wouldn’t happen. And so that, essentially, in sort of the kinda related to Likely.js you decided by the license.

    Whether or not you were going to make it publicly available or if you didn’t want people to build business on it, you could’ve made it GPL or AGPL or something along those lines and you could’ve restricted it in any way that you wanted and you chose not to. And there’s something implicit in that, that communicates to people who are building their companies on it, etc., as to what your intent was.

    Sean: No, that’s true. Although there’s a nuance in there which is that, even the GPL suffers from this, what Richard Solomon still complains about today which is, you could still use Likely.js on a server.

    Paul: Right, right, right. Well, so AGPL would work around that.

    Sean: Sure, and there’s other licenses that I could choose, but the majority of licenses out there today but even then, let me argue counter side, not because I agree with it just because, hey, let’s argue because—why not! You know, as an individual developer, I don’t have the time resources to go pursue people. I’m not gonna go sue somebody. Really? No, come on, like it’s not gonna happen. So, I think, you’re right only in the act of releasing it as open source on GitHub. I was making a decision that it’s possible for people to use this in ways that may, either A, I don’t intend, they could’ve used on Silk Road to recommend drugs for all I know, seriously, right.

    Or, to make money on it in ways that I am not gonna benefit from. And I made that decision knowing full well the impact of that. And I would actually argue most developers do that. The question is whether or not there’s remorse later on when it turns out, wait, I really wish I hadn’t made that decision, I can go back in time.

    Paul: Well, I think this is a common thing that people create a thing and then they say, well, if this is popular, I could sort of keep it or I could, there’s value here. I could keep it to myself or I could keep the value to myself. Or try to profit from it in some way. But they make, what is essentially, a marketing decision. I’m just gonna release this, I’m gonna see what happens to it. I’m gonna see if it spreads and then if it spreads, I can then make a decision as to, as to what, how possibly I can make money out of this. Or I can get value out of this. But at that point, obviously, the cat is out of the bag in terms of people actually using the software.

    Nadia: Yeah, I mean, I think it’s actually should start from the principle, like you said, of it’s really great when people, you give something away and then people can use for whatever they want. Whether it’s for a hobby project. Whether it’s for illegal drugs or whatever, you know. Businesses, whatever, that’s like, kinda one of the coolest things about open source is that you can use it for whatever you want and that’s kinda what you signed up for right.

    If you didn’t wanna do that, then don’t license it that way. I don’t know, I wouldn’t frame, at least the problems that I’m seeing and that I’m interested in, is not really about seller’s remorse, I guess of, “Oh, I made this thing and now it’s really popular and how can I make money off of it.”

    But I think it’s more really about investing back into the infrastructure that we’re all using and that requires some sort of maintenance and upkeep. And that’s why I like the term infrastructure and I’m trying to use it in that sense of things that don’t have a business model or business attached to it. Like you, literally, could not charge for Python. It’s just not gonna happen. Or the packaging associated with it or whatever, but still like millions of people are using it. It’s touched billions of people. And you literally have like one person working on a library or a project, that doesn’t seem, that seems like it’s in everyone’s best interest to make sure that it works properly.

    Edith: Well I think Nadia made a really good point that a lot of the fun of creation is the creation. And the hard work is all the maintenance and the support and the documentation after. So like, Sean, you basically got the fun.

    Sean: Oh, totally. Well I mean, if you even think back to the original “The Cathedral and the Bazaar” essay from years ago, that was one of the fundamental topics of, you know Eric was inheriting, I think it was called Pop Mail from somebody else.

    He had gotten tired of maintaining it and so he wanted somebody to take it over and he found Eric and Eric took it over. I mean, that’s, you know, I think, yes, as engineers we like creating and we like creating things in our free time and we don’t like maintaining them as much and maintenance feels more like work.

    And so, I agree with Nadia’s point that if everybody is driving economic value from it somebody has to be willing to step forward to support it. I think the problem is that I also, it’s funny that you have a background in nonprofits because I also have worked for nonprofits and I see the similar lament in nonprofit companies.

    Which is that—not nonprofit companies, nonprofit organizations, where the person who starts it usually really wants to solve this problem, they’re usually really good at that. They’re not good at the fundraising

    And in this case, the nonprofits, it’s like raising grant money or getting donations. But they have a good mission and they have a good organization to go do it. And they have this lament which is why can they not get more support to solve the problem they see in the way that they wanna solve it.

    And I see the same around maintainers of open source projects and I think the challenge is going to be that I wonder if it is even possible for the general economy to support them, to do what they wanna do, the way they wanna do it. Or if they are gonna have to start doing it the way the general—

    Paul: Right, because they have other options. They could start a consulting company. Get hired by a category two company or something like that. To build around it and support themselves that way and then their job doesn’t, then their job isn’t what they wanted their job to be which is making cool software. Their job is, you know, doing maintenance contracts for a big soul-less enterprise.

    Edith: You say that like it’s, I mean, soul-less enterprises, I mean …

    Paul: I’m a big fan of soul-less enterprises. But I’m just looking to sort of put the—

    Sean: They have a lot of money. We have to sell them.

    Paul: And if any soul-less enterprise would like to buy CircleCI they should contact me for enterprise pricing.

    Sean: Just mention the code OSS for 10 percent more.

    Edith: And by the way, thank you for wearing your LaunchDarkly t-shirt today, Paul.

    Paul: Always. So, Nadia and Sean had this conversation on Twitter a week ago which led to them being on the show. And one of the Tweets that got involved was from a Jacobian who’s one of the senior Python kind of people. And what he said is, OSS developers deserve to be paid. SV, Silicon Valley, has made massive profits by exploiting free labor. This needs to end.

    And I think that there is this, this feeling in open source by, at least by a lot of people who end up on the maintenance side of things that, there is a sort of a sharecropping going on here. And that’s something needs to happen about that.

    Edith: I think Nadia actually put this extremely well in the essay; like cool, I wish I had written that essay, it was brilliant.

    Nadia: Aww.

    Edith: But just like, what’s really fed this is the explosion of GitHub and it’s really easy now to start an open source project.

    Nadia: Yeah, I feel like right now is just a time when we’re so used to thinking of open source in a certain way and things have kind of gone along as they have for so long that we haven’t necessarily noticed or taken a step back that the past five years look completely different than the past 30 years. And stuff is just not the same anymore. And in part, I think it should be framed as a really good thing because it means that open source kind of won, in a way.

    Companies want things to be open source. They wanna learn how to open source their own projects. They wanna understand the whole thing. Everybody is defaulting to open source and that’s a really positive thing and the question is more of, not like, oh, we’re exploiting people and that really sucks but how can we help support that underlying layer that has helped make everything so great. It obviously needs some sort of reinvestment back into it.

    Edith: Yeah, I mean, one of the most fascinating thing about “The Cathedral and the Bazaar,” which was written 30 years ago, is that they referred to Linus Torvalds as this charming guy. Yeah, I know, and you’re like wow, here’s this charming, personable guy who like persuaded people through sheer force of will to work on his project.

    Sean: Yeah.

    Edith: I mean, to go back to Sean’s example about a nonprofit and everybody in the studio right now is like, whoa, that’s not …

    Nadia: Not at all.

    Edith: By anybody’s perception now, and I don’t know whether that’s just the grind down of having to keep maintaining a project or …

    Sean: First, I’d like to thank, I don’t know if his name is actually Jacobian, whatever it is, thank him for his service and work on Python ’cause I think, no matter what we agree on here, we can all agree that the people doing this are doing a service for the general community.

    Nadia: Definitely.

    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.

  • The Rule Of Law: Open Source, The Internet and Society Breaks Without It

    The Rule Of Law: Open Source, The Internet and Society Breaks Without It

    By now many if not most of you have read the big blowup about an open source developer who pulled some of his JavaScript code from a repository named NPM and in doing so broke the Internet. If you need some background here and here and here are some good articles with the background. To me the real loser here was the rule of law. Make no mistake about it, when the rule of law breaks down, the open source, the Internet and even society itself breaks.

    I think there is blame enough to go around in this drama. The trademark holder threatening lawyers and lawsuits is never a good way to influence people and make friends with open source developers. The open source developer who in essence “took his toys and left the playground” did so without thought to the millions of people who were disrupted, without thinking through what it means to put code in the public domain. The repo service who when perceived as threatened caved in like a cheap suit and took away a name from the developer without due process is also not without blame.

    All three of these parties could have handled this differently and this whole thing could have been avoided. Hell if people all over the world didn’t depend on these 11 lines of code instead of doing it themselves we wouldn’t give a rats behind about any of this. But they didn’t, we didn’t and so we do.

    Just as there are plenty of people to blame here, there are also plenty of losers. The biggest losers are those who depended on this javascript and had their apps break. But I think the open source movement is a loser here too.  I remember when I first got into tech 25+ years ago. At the time open source software was still being snuck into organizations via WAIS, Gopher, Compuserve and floppy disks (by then they weren’t as floppy as much hard). Many organizations did not want open source in their IT department, The reasons were plenty:

    1. Was it secure?
    2. Who did you call for support?
    3. Was it legal? What license was there for it? How could you modify it?

    The security issue persists to this day, though there are arguments pro and con. Many companies have based their whole business model around supporting open source software.  On the legality and licensing issue a whole cottage industry popped up around open source licenses. The GPL in all of its versions, the Apache license, and a myriad of other open source licenses have evolved.

    Around all of these licenses the idea is give the user a sense of legitimacy. To let them know what is allowed, what is not allowed. Both the author and the user are given well defined protections. This as much as security and support enabled open source software to proliferate and become as dominant as it is today.

    For me a key tenet of open source is that once the code has been released into the open community it cannot be pulled. You don’t have to continue developing new versions. Heck you can even do what my friend Ron Gula and Tenable Security did with Nessus. They came out with new versions that were not open source (though still free as in beer). But they would never pull down an older version that was open source and remove it.

    You could be mad at the lawyers, you can rage at the repo, but you can’t decide your code should no longer be available. You can say your new code won’t be, but you can’t take your old code down and go home. Sorry, that breaks the rule of law. When you break the rule of law everything we hold dear breaks. Not just the Internet but society itself. We depend on the rule of law.When you break the rule of law you wind up punished. This is where law suits and damages result.

    The rule of law should apply to the repository as well. There needs to be clear rules of engagement and process in place for when these kind of situations pop up. I reached out to my friends at Sonatype who run the Central Repository about what they think of NPM’s actions here. Brian Fox, VP of Product Management at Sonatype told me this:

    As long time advocates of open source software development, we have huge respect for everything that NPM stands for.  What happened last week was unfortunate — not only for NPM, but for the entire open source community.  

    For the past decade, Sonatype has served as the steward of The Central Repository — which itself has grown to become the de facto standard for Java based open source component distribution. During this time we have embraced several fundamental tenets designed to ensure reliability of The Central Repository in support of developers around the world.  The most important of these tenets is that components are immutable which, in our experience, is the only reliable way to build a system that allows reuse of dependencies.

    Another important tenet underpinning The Central Repository is the requirement of a minimal set of metadata, pgp signatures, and verification of coordinates. Collectively, these ensure that someone can’t show up and pretend to be a representative of a popular project and publish components that would be detrimental to the community.

    Finally, all content in Central is namespaced by a groupId. This groupId maps to a domain name of a project or foundation. (e.g. org.apache) In order to publish into this namespace, a publisher must be manually approved; which guarantees that only the official project or someone delegated to do so, can publish to that namespace.

    If you want to see more about how Sonatype views this you can read their blog on it at the Nexus.

    Whether you think NPM caved or not is not as important to me as did they follow their own pre-defined rules. If they did, developers should know this is how they will handle this kind of situation and the choice to deposit their code there is one that developers should make. But they make it knowing the rules. You need to have expectations of what allowed behavior is. Without it there is no rule of law otherwise.

    Developers should know that once they make the decision to let their code be free (as in freedom, not beer), it is free. Like Jonathon Livingston Seagull, once you set it free it is no longer yours. The rule of law dictates this and without it everything breaks.

  • Black Duck Announces Open Source “Rookies of the Year”

    BURLINGTON, Mass.–(Business Wire)–Black Duck, a global leader in automated solutions for securing and managing open source software, today announced the eighth annual Open Source Rookies of the Year, recognizing the top new open source projects initiated in 2015.

    The selected projects show how diverse and ambitious open source software development has become. From communications to healthcare and beyond, they offer innovative solutions to a range of consumer- and enterprise-grade problems.

    The 2015 Rookies class reflects three industry trends shaping the future of open source software:

    • Docker Containers: Docker, a 2013 Rookies of the Year selection, established containers and DevOps as the heirs apparent to server virtualization. In 2014, a number of Docker ecosystem players emerged, and the trend continues this year with several, including projects sponsored by Red Hat and Capital One.
    • Open Collaboration: Email isn’t dead, but it’s not as important as it used to be. The success of Facebook messaging and Skype for personal use fuels demand for similar solutions in the office, with real-time tools like Slack and GoToMeeting becoming standards. However, proprietary solutions face competition from open source alternatives which promise all the same features of the originals, but without the lock-in downside of proprietary solutions.
    • Artificial Intelligence: We may be a long way yet from truly “sentient” machines, but development teams are helping computers get smarter at getting smarter. Deep learning techniques aim to teach computers to teach themselves by using a system of multiple processing layers to model the neural network of a human brain. This year we recognize two new projects in the field of deep learning.

    The 2015 Black Duck Open Source Rookies of the Year are:

    • Rocket.Chat – an open source web chat platform built for communities and companies wanting to privately host their own chat service.
    • Mattermost – an open source, on-premise Slack alternative, written in Golang and React.
    • Hubl.in – a free and open source video conferencing solution.
    • MXNet – a lightweight deep learning library created by DMLC, the people behind CXXNet, Minerva and Purine2.
    • Bazel – a subset of Google’s internal software development tools, building software quickly and reliably through a shared code repository in which all software is built from source.
    • React Native – a Facebook-sponsored framework for building native mobile applications using the React JavaScript library.
    • Kontena – an open source container management solution “built to maximize developer happiness.”
    • Nulecule – a specification for packaging complex multi-container applications while ensuring smooth deployment across all instances.
    • InSpec – an open source compliance testing framework for specifying compliance, security and policy requirements.
    • Hygieia – Capital One’s enterprise DevOps dashboard, released last year as an open source project on GitHub.
    • Glucosio – the world’s first open source diabetes monitoring application.
    • Honorable Mention: Vault – a tool for securely accessing API keys, passwords, certificates, employee credentials and other sensitive resources.
    • Honorable Mention: RancherOS – a miniscule Linux distribution specially designed to be the easiest way to manage Docker containers.
    • Honorable Mention: OWASP Security Knowledge Framework (SKF) – a free, open source web app security system based on OWASP security standards.

    “This year’s Rookies are impressive examples of how far open source has come, with start-ups like Mattermost and Glucosio as well as big players like Google, Facebook and Red Hat leveraging the open source community to help drive innovation in everything from DevOps and Docker container solutions to diabetes monitoring and real-time communication,” said Patrick Carey, Director of Product Management, who headed the Rookies selection process.

    “These are sophisticated initiatives where the open source approach is a core part of the business strategy for speeding development, promoting adoption and providing the most value to their customers,” Carey said.

    For more information about the Black Duck Open Source Rookies of the Year, please visit www.blackducksoftware.com/open-source-rookies.

    About Black Duck Software

    Organizations worldwide use Black Duck Software’s industry-leading products to secure and manage open source software, eliminating the pain related to security vulnerabilities, open source license compliance and operational risk. Black Duck is headquartered in Burlington, MA, and has offices in San Jose, CA, London, Frankfurt, Hong Kong, Tokyo, Seoul and Beijing. For more information, visit www.blackducksoftware.com.

    Black Duck
    Brian Carter, 508-277-7570
    Director of Strategic Communications
    bcarter@blackducksoftware.com
    or
    PAN Communications
    Michael O’Connell, 617-502-4300
    blackduck@pancomm.com