Tag: open source

  • Malicious Intent: Open Source Developers, Please Protect Your Users

    Malicious Intent: Open Source Developers, Please Protect Your Users

    For the second time in just a few weeks we’re seeing the fallout of missteps taken by publishers of open source components. It was just recently that I wrote about the GitHub id of go-bindata being highjacked. We don’t know for certain if the intentions were malicious, but the risk was obvious.

    Even more recently we find that credentials were compromised for an npm component called conventional-changelog and a malicious version was uploaded that allegedly included a Monero cyptocurrency miner. Anyone who built or installed an npm package depending on the malicious package is now potentially running a miner and worse, potentially distributing it to their downstream users or customers.

    A few months ago people were laughing at a parody of a similar situation describing credit card harvesting via a compromised package. It’s not so funny anymore, is it?

    Open source developers typically thrive in creating something used by millions or billions of other people. This is the fuel that drives us and knowing that you’ve contributed, even in some small part, to the lives of millions of users is amazing.

    Conversely, knowing that you’ve accidentally inflicted harm on those users through careless practices is probably devastating. Yet, seemingly not enough people are thinking about this beforehand while it’s preventable.

    We open source developers and package maintainers are finding ourselves at the frontline of the new battle. Attackers have recognized the power of open source in terms of broad distribution and are seeking to use that against us.

    We must not let them ruin the reputation of the things we’ve built—or, worse, the entire open source ecosystem.

    If you’re an open source contributor or package maintainer: Pay attention to your own digital security as you would if you were protecting millions of others. Because you are.

    — Brian Fox

  • Subtree Rises to Microservices Data Management Challenge

    Subtree Rises to Microservices Data Management Challenge

    Fresh off raising $10 million in funding, Subtree has emerged from stealth to launch a service based on the dotmesh open source utility for microservices to enable DevOps teams to capture the entire state of applications.

    Dotmesh captures application state as a series of units known as datadots, and captures and tracks all versions of all the databases, files and other data in any application based on a microservices architecture, said Subtree CEO Luke Marsden. That utility exposes a command line interface (CLI) through which data about the application captured by dotmesh can be collected, and a dotmesh server component stores all the datadots.

    Marsden said the dotmesh utility can be applied to any microservice regardless of what runtime or class of containers is being employed.

    Once captured, that information can be shared via a dothub repository managed as a service by Subtree. Marsden said there’s no requirement to use dothub as the repository because the dotmesh utility is available as open source code. But dothub is designed to be the most efficient way to share data about the state of microservices applications distributed across the enterprise, said Marsden.

    The goal, he said, is to provide the equivalent of the service for source code that Github makes available and designed specifically for sharing information about the state of microservices applications deployed in production environments.


    Related Content:

    Red Hat Survey Sees Broad Adoption of Microservices

    Flexera Extends Scope of Open Source Scanning Tools


    In effect, the combination of dotmesh and dothub creates a new type of service mesh for tracking and managing data, Marsden said.

    He noted that microservices create a significant data management challenge because best practices call for each one to have access to its own database. Managing applications made up of microservices that are tethered to larger numbers of databases makes it difficult to ascertain the state of an application built on top of multiple microservices, Marsden said. If one microservice should fail, for example, the DevOps team often has to stop the application because of all the dependencies between them. However, dotmesh utilities tethered to the dothub service via application programming interfaces (APIs) make it easier to determine the relationship between all those microservices and their data sources, he said.

    Subtree envisions DevOps teams employing both dotmesh and dothub together to create workflows that specifically address data management in a microservice environment. The degree to which IT organizations are currently challenged by data management varies according to the number of microservices they are attempting to manage. At some point, however, just about every IT organization that embraces microservices will need to address how the data attached to each microservice gets managed, especially within the context of a larger stateful application.

    The impact of a lack of data management that is designed for microservices is already being felt. Many organizations are unable to effectively test a microservices-based application because the tests don’t accurately reflect the true size and scope of the application.

    Pricing for the dothub service is $10 per month for 5GB of storage. There’s also a free tier of storage provided for up to 1GB of storage.

    It’s still not quite clear who inside IT organizations will manage the data being accessed by what inevitably will become thousands of microservices. But it is clear that currently, the tools for managing all that data are, for the most part, nonexistent.

    — Mike Vizard

  • Should You Migrate to Git? Part 1

    Should You Migrate to Git? Part 1

    There are many factors to consider when making the decision whether to migrate your source code. Is it appropriate for the project? Will it work? How might it impact the quality and performance of the finished product?

    Git can help make the decision easier. Git is an open source version control system for tracking changes in computer files and coordinating work on those files among multiple people (Wikipedia’s definition, not mine).

    Git is gaining in popularity and many industries are now moving to it for a number of reasons. For one, Git’s design and performance are remarkably good among all distributed version control system (DVCS) tools. Also, Git can move work quickly between servers without losing history.

    Git has a wide variety of plug-ins for IDEs, and it also comes equipped with a wide variety of tools to help users navigate the history system. Each occurrence of the source contains the complete history tree, which can be useful when developing without an internet connection.

    Plus, Git was created by Linus Torvalds, who also created Linux, which gives it a certain caché.


    Related Content:

    5 Open Source SIEM Tools Worth Checking Out

    Configuration Files and DevOps


    Git’s popularity has been bolstered by killer apps and services such as GitHub, and some very popular projects used it, which further increased its visibility.

    Git nowadays is very popular, but it is recommended companies don’t migrate tools so frequently. Also, there are challenges in  pre-migration and post migration worth considering.

    Distributed revision control uses a peer-to-peer model rather than using a centralized server to store code updates. While a peer-to-peer model would work better for global, open source projects, it may not be ideal in other situations. The downside to a dedicated server approach is that when the server is down, no clients are able to access the code.

    Pros:

    • Great for those who hate centralized version control system (CVCS)
    • Dramatic increase in operation speed
    • Full history tree available offline
    • Distributed, peer-to-peer model
    • Cheap branch operations
    • Attracting lot to non-technical due its open source features (Git is GPLv2)

    Cons:

    • Learning curve for those used to SVN
    • Not optimal for single developers

    Companies That Have Migrated

    Many of today’s new enterprise technologies are centered around free, “open source” technology. As a result, many big companies, from financial giants to retailers to services firms, prefer open source platforms. With the introduction of GitHub many companies have migrated their code base to Git.

    The most popular open source project serves as a “version-control system” for tracking changes and coordinating work between software developers.

    Some very well-known names use Git, including:

      • AWS
      • Reddit
      • Twitter
      • PayPal
      • LinkedIn
      • Gnome
      • Adobe
      • HubSpot
      • Mozilla
      • DropBox

    Terminology

    Git has it own terminology that users, or those considering using it, should become familiar with. Here are some terms worth knowing:

    • Master – the repository’s main branch. Depending on the workflow, it is the one people work on or the one where the integration happens.
    • Clone – copies an existing Git repository, normally from some remote location to your local environment.
    • Commit – posting files to the repository (the local one); in other VCSes it is often referred to as “check-in.”
    • Fetch or pull – Also known as “update” or “get latest” in other VCSes. The variance between fetch and pull is that pull combines both fetching the latest code from a remote repo and performing the merging.
    • Push –  submitting the code to a remote repository.
    • Remote – these are “remote” locations of your repository, normally on some central server.
    • SHA – every commit or node in the Git tree is known by a unique SHA key. You can use them in various commands to manipulate a specific node.
    • head – a reference to the node to which our working space of the repository currently points.
    • branch – similar to other VCSes; however, a branch in Git is actually nothing more special than a particular label on a given node. It is not a physical copy of the files as in other popular VCSes.

    — Amit Anan

  • Flexera Extends Scope of Open Source Scanning Tools

    Flexera Extends Scope of Open Source Scanning Tools

    Now that many IT organizations have adopted an open source-first mentality to acquiring new software, tracking their dependency on all the various modules they are employing is becoming more challenging with each passing day. To help IT organizations track both usage and dependencies of open source software, Flexera has updated the FlexNet Code Insight software to continuously scan the network for open source software and highlight any known security and compliance issues.

    Based on code Flexera gained when it acquired Palamida in 2016, FlexNet Code Insight is now easy to navigate using a single dashboard, says Jeff Luszcz, vice president of product management at Flexera. Its capabilities span high-level package analysis to more detailed analysis that detects when snippets of open source code are being used within a third-party application regardless of build dependencies, sub components, source code, modified source code and binaries and even Docker containers being used.

    In addition, this release of FlexNet Code extends the integration Flexera provides to continuous integration servers and third-party build tools to automate scans during the software development process. IT organizations also can create their own custom plug-ins, says Luszcz.

    FlexNet Code Insight can identify 13 million open source components and supports more than 70 extensions. That includes integration with data from the National Vulnerability Database and security vulnerability assessment software developed by Secunia Research, which Flexera acquired in 2015.

    Luszcz says FlexNet Code Insight is a natural complement to the tools Flexera already provides for tracking use and dependencies between instances of commercial software. The difference now is a steady increase in the rate enterprise IT organizations are now depending on open source code, which changes more rapidly.

    Flexera is not the only vendor these days focusing on identifying open source software (OSS) vulnerabilities and associated compliance issues. But it does uniquely provide tools spanning both commercial and open source software. That capability is especially appealing to senior IT executives who would prefer to rely on a single vendor to provide both classes of tools, says Luszcz.

    While there’s currently a lot of enthusiasm for open source software in the enterprise, Luszcz says many IT leaders don’t appreciate some of challenges that lie ahead. Most open source software is made up of modules provided by different developers working within the confines of an open source project. Updates to that software to address, for example, a security flaw are not easily propagated throughout the ecosystem. In fact, Luszcz says that very issue lies at the heart of recent security breaches that occurred at Equifax.

    Having a local repository to keep track of what software is being used simply isn’t enough, Luszcz says. IT organizations need an end-to-end approach for monitoring all the updates made to that software regardless of where it originates.

    Of course, when it comes to open source software there really is no going back. Lusczs notes that as far as compliance and security are concerned, the proverbial genie is already out of the bottle. The only question now is how to marry OSS tools to DevOps processes to make living with that open source genie a lot easier for all concerned.

    — Mike Vizard

  • The Value of Commercial Open Source

    The Value of Commercial Open Source

    Adhering to the open source definition enables a large, passionate community to collaborate and share their work, insights and innovations on a given OSS project. Companies working in commercial open source add to that value by turning what may look to enterprises like “raw material” into whole product.

    These combined efforts serve to improve products, while continuing to protect customers from the stranglehold of proprietary vendors. Beyond just open source, adherence to open specifications (such as CMIS in the content services space) and implementing open RESTful APIs provides a treasure trove to developers that they can quickly and efficiently build upon to add new innovative functionality into the solutions they craft to meet specific business needs.

    When vendors employ open thinking at all these levels (open source, open standards, open APIs), there are commercial benefits across the board. The enterprise customer has a hedge against lock-in, can benefit from the innovation across the community, and, perhaps most importantly, can quickly and nimbly respond to changing market conditions while relying on the robust software quality commercial open source provides.

    James Dixon, Pentaho Founder and CTO, has described the approach of commercial open source as being akin to a Bee Farm.  Bees can, of course, create honey on their own in the wild, but most of us buy honey that comes from a farm. The beekeeper’s job is to create conditions that attract the bees in the first place, and then (bravely!) collect the resulting honey before refining, packaging and distributing in a way that appeals to consumers.  This system of open collaboration adds value throughout the supply chain, from the bee to the beekeeper to the customer at the breakfast table.

    Likewise, in commercial open source, the vendor takes on the role of beekeeper, creating conditions in a community that attract and retain contributors to help create a better product for all in a win-win-win scenario:

    • The community gains open source software they can use for their own purposes. This software has more functionality and more resources than a ‘pure’ open source project could provide. In this way the community profits directly from the company and its customers.
    • The customers gain higher quality software at a better price. The customers profit from the open source community’s ability to produce high-quality software.
    • The company gains by growing and increasing its valuation as a result of keeping both sets of consumers content.

    I can’t think of a more perfect metaphor for the role of commercial open source. In fact, as a nod to James’s insight, years ago the Alfresco user community named their organization the “Order of the Bee.” What a complimentary match for our company, which, after all, is named after an open air, outdoors experience!

    The open source mindset provides areas of opportunities along the entire supply chain, from creation of software to products and services on which the software runs. Just as bees are integral to honey, open source is integral to today’s digital business environment.

    About the Author / Chris Wiborg

    Chris Wiborg is Vice President of Product Marketing at Alfresco Software. In his role, Chris is responsible for setting and executing the go-to-market strategy for Alfresco’s Digital Business Platform. Connect with him on Twitter and Linkedin.

     

  • DevOps Gets More Exciting in 2018

    DevOps Gets More Exciting in 2018

    As 2017 winds down and the IT industry prepares for 2018, there are a number of DevOps trends that everyone should be keeping their eyes on. It’s not so much that something incredible and explosive is expected in the new year. Rather, 2018 will be a time when DevOps starts to mature alongside other trends important to developers.

    These trends don’t guarantee organizations will be immediately successful with DevOps. Most still will struggle with the management aspects of DevOps, especially the need to keep feuding silos within IT working together as one happy group. Assuming developers, QA, and Operations can all learn to get along and act as a team, the technology supporting DevOps will continue to improve and the ecosystem will grow.

    Here are some of the DevOps trends that Amalgam Insights is following for 2018:

    Everyone Loves Containers and the Ecosystem Grows

    Containers have become a common technology in many IT departments. Although the majority of applications remain housed on single servers and virtual machines, container deployments are growing. Containers are an important enabling technology for DevOps—by creating small, transportable bits of applications, containers make it easy for IT silos to work from the same page.

    In 2018, growth in container deployments is expected to accelerate as large companies outside the software industry, such as those in financial services and health care, adopt microservices infrastructure. Containers that are especially suited to microservices will continue to expand rapidly.

    Increased container growth is also due to an expanding ecosystem. More companies have entered the market with products necessary to large-scale production applications. Products now exist for securing, managing, deploying and enhancing container services that weren’t available a few years ago. What’s more, containers are now available in all the major cloud services including Oracle Cloud, Microsoft Azure, AWS, IBM Cloud and Google Cloud. Containers are becoming enterprise-ready and large enterprises are feeling more confident using them.

    Takeaway: Growth in the ecosystem contributes to growth in container deployments while expansion of containers entices companies to enter the ecosystem. Containers have reached mainstream normalization and we expect to see fast expansion throughout 2018.

    Kubernetes Eats the Container Orchestration World

    In the container orchestration space, Kubernetes has become the tool of choice. Orchestration is the deployment and management of container clusters and is necessary to deploy them at scale. Kubernetes, originally a Google open source project and now managed by the Cloud Native Computing Foundation, has become the most popular orchestration tool available. That became obvious when Docker decided to distribute and support Kubernetes, despite having invested in its own orchestration system called Swarm. CoreOS, Microsoft Azure, Red Hat OpenShift, Docker and others have their own enterprise distributions as well.

    Kubernetes brings to the container ecosystem a relatively easy way to manage containers at scale. In large container deployments, containers are constantly being spun up, shut down, moved and copied. Once container clusters are in place, they must be monitored for security and service failure.

    During development, there will be a number of clusters that must be managed for development, test and final release to production. Doing this manually is close to impossible when even a moderate number of containers are in the DevOps pipeline. Kubernetes provides the tools and workflow to simplify these tasks.

    Takeaway: As container production clusters grow and as they are integrated into the DevOps pipeline, the need for orchestration becomes acute. Kubernetes has won the game and is now the tool of choice for orchestration. 

    The Pipeline is Getting More Integrated

    DevOps is often described of as a “pipeline,” In this context, a pipeline is a linear workflow that moves from build to test to release. As DevOps becomes more common in organizations, the pipeline grows to include additional test phases, monitoring and continuous improvement to create more of a cycle than a linear flow.

    One of the great impediments to making DevOps a reality is a lack of tools that support the entire pipeline. There are plenty of tools that help build applications, such as IDEs and code repositories from companies such as IBM, Microsoft, GitHub and Oracle, as well as dozens of open source products. Testing is well-supported with test data management and test plan management tools from companies such Atlassian, Informatica and Oracle. Release management and deployment products are widely available from Atlassian, Microsoft, IBM and many other companies. The problem lies not with the support for the individual steps in the pipeline, but with the integration of these tools to provide a complete end-to-end workflow. This creates a disjointed workflow, prone to errors and supportive of silos instead of collaboration.

    This is changing, however, and announcements late in 2017 herald toolsets that can provide a continuous DevOps pipeline. A great example of this is the newest versions of Microsoft’s developer tools that were debuted at Microsoft Connect(); in November 2017. Tying together the Visual Studio debugger with Kubernetes allows developers to test and debug as close to the production environment as possible and then deploy cluster to the test environment. That, plus the upgrades to Team Server, shows the commitment Microsoft has to creating integrated DevOps systems.

    Takeaway: While DevOps tools are still more or less disjointed, we are seeing a movement to fully integrated toolsets that enable the end-to-end DevOps pipeline.

    2018 is the Year of DevOps—Unless IT Management Gets It Wrong

    This coming year could be the year that DevOps truly takes off and becomes mainstream. Those who believe it is already mainstream now are fooling themselves. Management may believe their organization is implementing DevOps, but too many barriers still exist—especially management itself. IT departments remain heavily siloed and independent of each other, as do development tools. DevOps at scale requires, above all else, a collaborative and cooperative approach. Sadly, that does not yet exist in many IT departments. As tools reach maturity and best practices become common, managers become the inhibitors of DevOps. New management structures, incentives and thought processes need to be in place or the money spent on tools is wasted.

    Takeaway: All the DevOps pieces are in place except for the breaking down of functional silos that exist in IT departments. 2018 may be the year of DevOps if IT managers can create a new environment of cooperation.

    About the Author / Tom Petrocelli

    Tom Petrocelli is a contributing analyst with Amalgam Insights. His area of interest is collaboration and new ways of work, developer tools, IT project efficiency, governance and methodologies and DevOps. Most recently, Tom worked for a large, global banking corporation. Previously, he was the research director for Enterprise Social, Mobile and Cloud Applications at Neuralytix. He is an experienced marketing, technology and business executive with 30+ years in the computer technology industry. Tom’s background spans software engineering, systems architecture, IT, product management and marketing and general management. Connect with him on LinkedIn and follow him on Twitter.

  • DevOps Chat: Chef Habitat Project Continues to Mature

    DevOps Chat: Chef Habitat Project Continues to Mature

    When Chef Habitat was released a little more than two years ago (good devopsy.kinsta.cloud story on Habitat here and a good DevOps Chat on it here), many people in the DevOps community wondered where Chef was going with Habitat. It was a really ambitious vision, but could it meet its lofty goals?

    Habitat is now made up of many different packages that provide different functionalities. There is, of course, much more to Chef Habitat. This DevOps Chat will tell you all about it.

    Joining us on this DevOps Chat are Jaime Winsor, a co-author of Habitat, and Tasha Drew, senior product manager of Habitat, and Blake Irvin of SmartB, a Habitat user. Between the three of them, there is a ton of great information here. If you are interested in Chef Habitat or would like to find out more, this is a great place to start!

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

    Audio: Chef Habitat

    Transcript: Chef Habitat

    [su_pullquote][su_custom_gallery source=”media: 118811″ target=”blank” width=”250″ height=”250″]Blake Irvin
    Blake has spent over a decade working in systems and software engineering automation, on platforms ranging from on-premise metal to containers-as-a-service, BSD and Solaris systems to embedded Linux sensor platforms. He lives and works in Berlin, Germany, where he’s Senior Operations Engineer at smartB, GmbH, an energy-efficiency and sustainability startup.[/su_pullquote]

    Alan Shimel: Hey, everyone, this is Alan Shimel from devopsy.kinsta.cloud here for DevOps Chat, and we’ve got a really great chat lined up for this episode. It is all about Chef Habitat, and we’ve got some really-we actually have three guests on the show today, so we’re gonna move it along to keep it moving.

    Let me first of all introduce my two Chef guests or from Chef. One is Tasha Drew, who’s a Product Manager for Chef Habitat, and one is Jamie Winsor, an engineer with Chef and one of the co-authors of Habitat. Jamie, Tasha-welcome to DevOps Chat.

    Tasha Drew: Thanks so much. Happy to be here.

    Shimel: Thank you.

    Jamie Winsor: Yeah, thanks for having us, man.

    Shimel: Hey, it’s my pleasure. And then, joining Jamie, Tasha, and myself today, all the way from Berlin, is Blake—and I hope I’m not gonna mess this up—Irvin. Blake, are you there?

    Blake Irvin: Yep.

    Shimel: Okay. Thanks. Hey, Blake, I appreciate you taking the time to join us. Blake, you’re with, is it BusyBee, is that what’s the name of the company?

    Irvin: It’s called smartB.

    Shimel: smartB.

    Irvin: Yeah, and the B essentially stands for business, because we are building, because we focus on providing energy efficiency analysis for businesses—small to very large businesses and the buildings that they operate.

    [su_pullquote align=”right”][su_custom_gallery source=”media: 118812,118813″ target=”blank” width=”200″ height=”200″]Tasha Drew
    Tasha Drew is the Product Manager for Habitat. She previously launched Chef Automate’s analytics capabilities, was Head of Product at Rentlytics, was responsible for product for Engine Yard Cloud, and spent several years in various data center endeavors on behalf of Lockheed Martin. Tasha holds an M.S. in Management from RPI and a B.S. in Computer Science from USC. When not in front of a computer, Tasha prefers to be cruising around Napa or at the beach with her dogs—all while having intensely deep thoughts about how to save application developers from tedious rework via the wonders of application automation with Habitat.
    Jamie Winsor
    Jamie Winsor is a lead engineer at Chef Software and the coauthor of Habitat, an open source project built upon distributed system protocol Butterfly to provide a self-healing, self-configuring, stack-agnostic, frictionless abstraction for running applications—regardless of their complexity—to software developers. Jamie has been a software engineer in the video game industry for 10 years, focusing on networked application servers on such titles as League of Legends, Lord of the Rings Online, and Dungeons and Dragons Online. One of Jamie’s responsibilities in his game development tenure was to bring what we today know as DevOps into the daily lives of the other developers on his team, which Jamie accomplished by building, evangelizing, and teaching methods to his peers. He draws on that experience today in building Habitat, as he helps enable all software developers, regardless of their experience, bring their ideas to life without investing in the details of operationalizing an application.[/su_pullquote]

    Shimel: Wow, that’s really good stuff. Jamie and Tasha, you both work for Chef, no need to introduce who Chef is to our DevOps audience, but Blake-welcome. And we have you on today because we’re gonna talk a little bit about Habitat, and Blake, if you don’t mind, I wanted to start with Tasha and Jamie and talk a little bit-just a little background. Maybe we have some folks on here who are not familiar with Habitat.

    So, Jamie, you’re a co-author. Why don’t you take that one, right? What’s Habitat, for people who may not be familiar?

    Winsor: Yeah, sure. So, the Habitat project is a number of pieces of software, and the overall goal is to, I hope, redefine what application automation means by focusing on the application instead of the infrastructure. In the past, we have been building computers in service to host our applications, and what Habitat does instead is it says, “Let’s focus on what the applications are that we need to run our application, what software we need down to a bare minimum, and then provision the machine around it,” and Habitat runs exactly the stuff that you need.

    It does so with a packaging system and a build system and then a process supervisor. The process supervisor runs the packages, the process supervisor communicates to other supervisors using a gossip protocol to share and spread information about what software they’re running, which allows us to enable things for free, just by packaging your software with Habitat, such as service discovery, leader—follower failover, rolling configuration updates, rolling software updates—and it’s all coordinated using the gossip ring.

    Finally, the piece that we built, the last piece of Habitat is simply called Builder, which we can also chat about today, which we just launched about a month ago. And Builder is a hosted Software as a Service build service that’s currently in preview mode. It’s free, and it builds your software that’s packaged with Habitat and hosts it as well in release channels, which allows you to have supervisors subscribe and then receive automatic updates using a complete CI/CD process of promotion between an unstable branch to a stable branch and so on. That’s basically it.

    Shimel: Yeah, no, more than basically-that was a great description and great stuff there, Jamie.

    Tasha, now, Habitat was released as an open source project by Chef, and it’s probably about two years ago now, right?

    Drew: Yeah, yeah.

    Shimel: And so, Tasha, tell us kinda what’s been the latest with Habitat.

    Drew: Sure. So, basically, we have been working nonstop since the initial reveal of Habitat about two years ago, just adding functionality and capability across both that Builder system and that process supervision system that Jamie’s been talking about.

    We’ve also been working on the deployment piece of the overall integration between those two which, in Habitat’s world, is highly agnostic. So, the idea is, use whatever tools you need to deploy those artifacts and supervisors that you’re using with Habitat. And so, we’ve been working with partners to have a really great cloud foundry ecosystem story, Kubernetes ecosystem story, AWS and Azure story, and then Terraform as well.

    So, the idea is, we have been making it easier and easier for people to come get started using Builder, and that’s why we’ve released Builder in free preview mode, it’s because we just want to have this very low friction way for people to get started with Habitat and start rebuilding all of their workloads, and then deploy using your favorite technologies and then start seeing the benefit of the supervisor in Builder, communicating between the two.

    Shimel: Absolutely. And as you mentioned, Builder is in free preview right now. You know, some people look at things like Habitat and some of the other great open source projects Chef is kind of shepherding, and they say, “This is all great, great, great, but how—you know, where does, how do they stay in business? Where do they make money?”

    So, Tasha, can you talk a little bit about sort of where Chef sees commercial opportunity with Habitat?

    Drew: Yeah, absolutely. So, for our enterprise customers, having on prem solutions that integrate with all of our open source products in order to have that really strong control plane management layer is super important. And so that’s, with Chef Automate, something that we continue to invest and see incredible success with.

    And then, with Habitat, Habitat becomes the technology that continues to support enterprises while they want to move fast to deliver applications to production at scale. And so, having this part of the technology suite be adopted by our core set of enterprise customers will continue to be part of our strategy, but then we also have Builder to enable smaller shops to just get started—really low friction point, really easy to use. And how we monetize Builder itself over time will be something that we investigate as we see how people adopt and use the technology.

    Shimel: Excellent answer. Great, Tasha. So, Blake, I didn’t wanna leave you too long in the cold. Let’s bring you into this now. First of all, Blake, I don’t think I asked you, and I don’t know if our audience is savvy to it, but what exactly is your role at smartB?

    Irvin: So, I—we have a team of sort of multidisciplinary, polyglot engineers at smartB. We do all kinds of things because we’re a small shop and a small company, still. But the focus that I have—and this has been my focus and my interest, sort of, for the last, it’s actually been a little bit over 10 years is on all manner of operations engineering.

    So, what I used to do would be something more like traditional systems administration, and now I would say I’m more of a software engineering operations specialist. In other words, I’m focusing on improving and streamlining the process of software engineering and less focused on things like racking servers.

    Shimel: Sounds like you’re doing DevOps to me, man. [Laughter] But Blake-

    Irvin: Yeah, you could say that.

    Shimel: Yep. So, Blake, smartB is using Habitat?

    Irvin: Yeah, that’s true.

    Shimel: Let’s talk about why.

    Irvin: I would say, for the moment, about-sorry?

    Shimel: I was gonna say—why? What are you using it for?

    Irvin: Well, we’re using it for almost everything. We have one—yeah, we have one production service that is not yet what I called Habitized or wrapped up in the Habitat package, and we’re just waiting for some work in the community to be finished before we can do that. But yeah, like, 85, 90 percent of our services are running under Habitat, using the Habitat supervisor, and we’re using as much of that workflow that Jamie and Tasha were describing as we can at the moment.

    And that’s actually been a pretty good process for us, I think, because the way that Habitat’s designed, the adoption process can be incremental. So, when Tasha was referring to giving Habitat users the freedom to pick and choose how they want to deploy or how they want to go about adopting, that’s definitely something we’ve leveraged a lot to make our story good for ourselves.

    Shimel: Got it. And so, Blake, I mean, when did you guys adopt, start with Habitat?

    Irvin: So, when I saw the launch video, which was, I think, Adam speaking in Seattle-Adam Jacob, the Chef CTO. I was sort of, I was watching it originally just out of curiosity and then, as the talk went on, my mouth started hanging open further and further, I think. Not because I thought it was the most groundbreaking thing that I’d ever seen, but more because I couldn’t-I was surprised to see how many of the check boxes that I had in my mind from 10 years ago around this kinda stuff, all this kind of operations work, how many of those check boxes were getting checked off by the project as the architecture and the behavior of the tools was described.

    So, we really started looking at the feasibility of adoption within weeks, I think, of that launch video.

    Shimel: Wow.

    Irvin: And started doing the rollout probably a few months afterwards. So, we’ve been doing it like a very slow, incremental rollout to, you know, ensure that we don’t disrupt any of our current software development process or our current production environments. That’s what’s been going on. It’s been a continual process for, I’d say, like eight months now, but just done very slowly.

    Shimel: Very cool. So, Blake, you know, I have a long history of working in open source-related projects and stuff, and I’m always curious, you know, as a consumer, if you will, or a user of this open source project, have you guys—what have you contributed back? Have you contributed any code, bug findings, suggestions for new features? How are you giving back to the community, here?

    Irvin: Yeah, sure. I think the thing, since we’re a really small team, what we’ve really focused on is trying to use the tool in the way that it’s been designed to be used and then giving feedback to the community and/or to the core maintainers whenever we find bugs or places we want to see improvements, and just keeping that conversation really open and fluid, which has been great. It’s one of the reasons that I’ve continued to use Chef software stuff for—not quite my whole career, but a sizable majority of my career. It’s just that, I think, as an organization, Chef believes that community is very important, and in fact, perhaps, one of the most important things about building a company. And compared to other experiences I’ve had with other open source groups, I think that’s been a real win for everybody involved.

    So, in terms of code contributions, I think mostly what we’ve done is put out a lot of plans, which are the sort of blueprints for packages that Habitat uses when you set up like a set of dependencies for your application. So, we’ve definitely published a lot of those back into the community. I think you can find them if you look on the Builder site under the smartB origin, you’ll see all the packages we’ve published. And we’ve also published some stuff back into the core plan side, just the ones that the Habitat team maintains.

    Shimel: Got it, got it. So, Jamie and Tasha, does Blake and smartB sort of represent the kind of prototypical Habitat user?

    Winsor: I’d say so. You know, with Habitat, you can pick and choose what pieces you want, and it’s been great to watch Blake and smartB grow from—back to the packaging manager and the supervisor and gradually moving toward adopting Builder. They’ve been great to work with in the community. They gave us a lot of great feedback. You know, they’re users, so one of the things that is really important is, you build a feature or you build—you know, you fix a bug, and then you immediately get the feedback from the community, and they’ve been unbelievable to work with.

    I’d say that Habitat would work for any team that ships software, though. So, they’re absolutely a typical user, because they ship software, right?

    Shimel: Mm-hmm. Cool beans. Guys, we’re almost at the end of time, unfortunately, leading up here over 15 minutes. But Tasha, for people who may want to, you know, go explore Habitat themselves, where can they go to get information?

    Drew: Yeah, we would love them to visit our website, Habitat.sh. There, you can see, we have a quick, you know, just kick the tires, 10-minute kinda step-through demo. We have more in-depth tutorials if you want to start just playing around with both the run and build time features of Habitat, and our community is very active on our Slack channel, which you can find a link there to join, but it’s just at Slack.Habitat.sh. So, as you get started, if you wanna just jump in that Slack channel, the entire core team is there, our community is there, and we seek to be super welcoming to new people. New questions are very welcome in the general channel. So, you can just hop in and get support and ask whatever questions you have.

    Shimel: So, it’s Habitat.sh?

    Drew: Yeah, yeah.

    Shimel: Excellent, excellent. Guys, listen. Thank you very—all three of you, Blake Irvin, Jamie Winsor, Tasha Drew—thank you so much for being our guests in this episode of DevOps Chat. Continued success, Blake, with you guys in your bigger business as well as using Habitat, and Jamie and Tasha, with you guys continuing to develop and make Habitat, you know, an indispensable tool for companies around the world. Alright?

    Drew: Thanks so much.

    Winsor: Thank you.

    Shimel: Alright, everyone, have a great day. This is Alan Shimel for DevOps Chat. We’ll hopefully see you soon on the next chat. Until then, take care, everyone.

    — Alan Shimel

  • NGINX Delivers New Products to Manage Microservices

    NGINX Delivers New Products to Manage Microservices

    At its annual user conference in Portland, Oregon, in September, NGINX delivered releases focusing on the application platform market and support of delivering microservices architectures:

    • NGINX Plus, an application delivery controller that combines a load balancer, content cache and web server.
    • NGINX Controller, a centralized management and monitoring platform for NGINX Plus, which orchestrates the delivery of applications across multiple environments, enabling companies to continuously deploy and update applications using tested and proven policies.
    • NGINX Unit, a multi-language server for applications, designed to work in highly dynamic environments. It features a full REST API that can be fully automated and used to deploy new application versions with no service disruption. It currently supports PHP, Python and Go with more language support coming soon.
    • The NGINX Web Application Firewall (WAF), powered by ModSecurity, which protects web applications against various Layer 7 attacks and provides DDoS mitigation, real-time blacklisting and audit logging.

    In addition to launching the NGINX Application Platform, the company has added the ability to use NGINX Plus as a Kubernetes Ingress Controller. Based on the open-source NGINX Ingress Controller for Kubernetes, this new feature enables the deployment of applications within Kubernetes and Red Hat OpenShift anywhere across a cluster so they can be reached by outside traffic.

    While these products combine to deliver a complete and manageable microservices solution, the most interesting of these is NGINX Unit. According to Owen Garrett, head of products, the complement of tools facilitates management of both north/south and east/west traffic for cloud-native applications. It’s small, lightweight, fast, polygot-enabled and programmable through an API and works with other Unit instances to deliver a service mesh.

    Key features of Unit that should be of particular interest to businesses deploying microservices relate to the ability to foster continuous delivery. For example, when the router accepts new configurations from the Controller process, the worker threads start to handle new incoming connections with the new configuration, while old connections can continue to be processed by the threads according to the previous configuration. That is: Router worker threads can work simultaneously with several generations of configurations.

    Additionally, Unit uses interprocess memory to communicate with the applications, thus allowing the Unit to provide greater agility in routing of HTTP requests. So, rather than forcing the application to directly listen, they can delegate network handling to the service mesh providing for increased scalability. They accept the clients’ requests, pass the requests to the application processes, get responses back from the applications and send the responses back to the clients. Each worker thread polls epoll or kqueue and can asynchronously work with thousands of simultaneous connections.

    — Alan Shimel

  • Logz.io Extends Scope of Log Analytics Service

    Logz.io Extends Scope of Log Analytics Service

    Log analytics is all the rage these days among IT and security professionals trying to discover the root cause of any performance issue or security breach. But there’s little consensus about how best to go about analyzing logs. Many IT organizations have made major investments in commercial platforms such as Splunk, while others prefer to rely on the less expensive, open-source tools Elasticsearch, Logstash and Kibana, collectively known as the ELK stack.

    As a provider of a cloud service based on the ELK stack, Logz.io has been providing organizations that prefer to rely on open-source software an alternative to deploying and maintaining their own ELK stack. Now Logz.io is extending that service to include Logz.io Application Insights, which employs machine learning algorithms to create a model of normal IT operations that can be used to more easily identify anomalies, and Logz.io Data Optimizer, which helps identify which logs are worth keeping long-term.

    Fresh off raising an additional $23 million in capital, Logz.io CEO Tomer Levy says his company is building up a pool of machine data to drive advanced analytics fueled by machine learning algorithms. Those insights then can be shared proactively with other Logz.io customers to head off production issues before they even occur. At present, Logz.io has more than 400 customers.

    Levy says the Logz.io Data Optimizer should enable IT organizations to substantially reduce their costs. Most providers of log management tools charge based on the amount of data collected. By helping organizations identify extraneous log data, the cost of implementing analytics of machine data drops considerably, Levy says.

    Logz.io Application Insights, meanwhile, provides a simple way to identify the last changes made to the environment that might have created a performance issue or introduced a security vulnerability.

    Levy says Logz.io, via application programming interfaces (APIs), can be integrated with multiple continuous integration/continuous development (CI/CD) platforms, including Jenkins. In fact, log analytics is now a fundamental element of any mature set of DevOps processes, he notes.

    Platforms for analyzing machine data is one of the fastest growing sectors of enterprise IT. New research from Zion Market Research forecasts that the IT operations analytics market is expected to grow on a 23.7 percent compound annual basis to reach $9.2 billion by 2020.

    Most DevOps issues only take a few minutes to resolve. But identifying the root cause of an issue can take weeks, sometimes even months, to identify. In more advanced IT organizations, centers of excellence around log analytics are now being created to identify not only potential IT and security problems, but also issues impacting, for example, the amount of revenue being generated via a specific application.

    It still may be a while before log analytics become pervasive across the enterprise. But every event in the IT environment generates a log, so the real challenge and opportunity is correlating all those log events into something that manifests itself as a truly actionable intelligence.

    — Mike Vizard

  • Kubernetes is the Universal Cloud Infrastructure

    Kubernetes is the Universal Cloud Infrastructure

    Before I started Rancher Labs, I created a company called Cloud.com where we developed Apache CloudStack. We were inspired by the early success of Amazon Web Services (AWS) and wanted to make it possible for everyone to stand up AWS-like cloud infrastructure for themselves.

    While CloudStack was successful in powering a number of public and private clouds, it failed to achieve mass adoption. Instead, cloud infrastructure today is increasingly concentrated in a small number of very large public cloud providers such as AWS and Microsoft Azure. There are a few reasons for this:

    1. It takes a lot of capital investment and operational expertise to operate cloud infrastructure. Only large players can benefit from economy of scale.
    2. There is no consistency among different cloud infrastructure providers. Even if a smaller provider can beat an established player on price, it becomes increasingly difficult for customers to migrate workloads from one cloud to another.
    3. The scope of cloud infrastructure services is forever expanding. It is no longer sufficient to offer basic compute, storage and networking services. Leading providers such as AWS offer an ever-growing number of services for data processing, analytics and artificial intelligence.

    Despite the downside of cloud lock-in, organizations are facing increasingly fewer choices in cloud infrastructure as they adopt cloud computing.

    Enter Containers and Kubernetes

    We started Rancher Labs because we saw that containers can potentially change the game in cloud computing. Docker is a universal application packaging standard that makes applications portable. Kubernetes adds cluster management to Docker. Many people think the power of Kubernetes lies in its ability to manage applications and microservices. We completely agree. We believe, however, that Kubernetes also brings significant benefit by hiding the differences between cloud infrastructure providers. Kubernetes comes with a rich ecosystem of plugins for storage, networking and load balancing. As a result, it does not matter where you have deployed Kubernetes. As long as the drivers are configured correctly, users get a consistent view of cloud infrastructure regardless what cloud provider they use.

    In addition to offering consistent storage, networking and load balancing, Kubernetes also brings with it a rich ecosystem of higher-level services for developers. The Cloud Native Computing Ecosystem includes all major providers of system- and platform-level software. Kubernetes has become the center of gravity of innovation in cloud computing. New capabilities are made available at a faster pace than anywhere else.

    In the early days, it was quite challenging to setup and run Kubernetes. Companies such as Rancher created Kubernetes distributions that make it easy for DevOps and IT teams to deploy and operate Kubernetes clusters. Today, many cloud providers offer Kubernetes as a service. At Rancher, we are now more focused on managing Kubernetes clusters. We expect most, if not all, major cloud providers to support Kubernetes in the future. When that happens, Kubernetes will be the universal cloud infrastructure.

    If you use cloud computing, there is no reason not to use Kubernetes. You get the most complete ecosystem support and the same consistent experience no matter where you go. Cloud lock-in will be a thing of the past.

    About the Author / Sheng Liang

    Sheng is a co-founder and CEO of Rancher Labs. Prior to starting Rancher, Sheng was CTO of the Cloud Platforms group at Citrix Systems after their acquisition of Cloud.com, where he was co-founder and CEO. Sheng has more than 15 years of experience building innovative technology. He was a co-founder at Teros, which was acquired by Citrix in 2005 and led large engineering teams at SEVEN Networks, and Openwave Systems. Sheng started his career as a Staff Engineer in Java Software at Sun Microsystems, where he designed the Java Native Interface (JNI) and led the Java Virtual Machine (JVM) development for the Java 2 platform. Sheng has a B.S. from the University of Science and Technology of China and a Ph.D. from Yale University. Follow him on Twitter.