Category: DevOps and Open Technologies

Editorial Calendar for February 2016

  • 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

  • NodeSource Increases Metrics in Node.js Development Platform

    NodeSource Increases Metrics in Node.js Development Platform

    As reliance on Node.js to build applications in the enterprise has skyrocketed in recent years, the challenges with managing these applications have been manifold, because most existing tools don’t provide much visibility into Node.js applications. To help address that issue, NodeSource has revamped a development framework based on Node.js to make it easier to manage deployments of Node.js applications at scale.

    NodeSource CEO Joe McCann says N|Solid 3.0 includes a revamped user interface and enhanced dashboard through which thousands of processes can be monitored. DevOps teams now can choose from more than 50 metrics to explore relationships between application data. In addition, all of the snapshot and profile assets can be downloaded, sorted, deleted or marked as favorite. Previously, the dashboard could only monitor up to 250 processes.

    The latest edition of NodeSource also provides support for alerts that can be used to trigger notifications in the event certain thresholds are exceeded.

    Fresh off raising an additional $17.5 million in funding, NodeSource has been making the case for an enterprise-class implementation of Node.js for several years. It counts Citadel, Comcast, Condé Nast, Delta Airlines, Goldman Sachs, Mastercard and PayPal among the organizations using its platform.

    NodeSource captures application metrics using agent software written in C++. The idea is to replace an open source implementation of Node.js with the version developed by NodeSource that is integrated with that agent software.

    As a variant of JavaScript, Node.js is essentially delivering on one of the original core promises of Java by making it easier for developers to build applications that can run on both clients and servers. Variants of JavaScript may not be as robust a framework for building applications as Java, but as programming environments go, JavaScript variants are much more accessible. According to the Node.js Foundation, the arm of the Linux Foundation that oversees the Node.js framework, there are more than 15 million downloads of Node.js per month.

    Most of the Node.js use is driven by developers who don’t always appreciate operational management issues. Many IT organizations have been hesitant to more broadly employ Node.js because they lack the tools needed to manage Node.js applications at scale. NodeSource is now trying to address that issue by embedding management tools in its core platform.

    By embedding many of the management tools needed to manage Node.js at scale, NodeSource is hoping senior-level IT managers will adopt its platform as a corporate standard instead of continuing to allow developers to pick whatever flavor of Node.js they find. Naturally, increased usage of Node.js is drawing interest across a broad spectrum to DevOps tool providers, so the issue many IT organizations must evaluate is the degree to which they can rely on existing DevOps tools to manage Node.js applications. NodeSource recently integrated its platform with the application performance management tools provided by AppDynamics. Because developers are now being held more accountable for the performance of their applications, NodeSource is betting that the metrics it provides will also appeal to enterprise developers.

    The degree to which Node.js will become a de facto enterprise standard remains to be seen. Contention between various programming language camps is fierce. But at the very least it’s already apparent that Node.js applications in the enterprise are here to stay.

    — Mike Vizard

  • LinkedIn Open-Sources Fossor Log Mining Tool

    LinkedIn Open-Sources Fossor Log Mining Tool

    Over the years there has been a steady flow of technologies developed by web-scale companies that have benefited the larger IT community by becoming open source projects. The latest two examples of this trend are Fossor, a tool for investigating broken hosts and services, and Ascii Etch, a Python library designed to complement Fossor that takes streams of numbers and turns them into visual graphs using ascii characters. Both were developed by LinkedIn.

    Steven Callister, senior site reliability engineer for LinkedIn, said Fossor, which is Latin for grave digger, was developed to provide a mechanism to mine logs to more easily discover unknown issues such a memory fragmentation. Typically there are 10 commands that DevOps teams employ to investigate whether certain issues might be occurring. Fossor eliminates the repetitive tasks associated with issuing the commands manually by enabling them to be automated then executed in parallel.  This approach  allows DevOps teams to continuously execute tests to discover any potential unknown issues that might arise at any time, he said.

    Callister noted LinkedIn decided to open-source Fossor to give back to the IT community in a way that is extensible. Fossor has two basic components: a core engine and a mechanism for creating plugins that DevOps teams can use to add tests specific to their site architecture. Linkedin is hoping that an entire library of plugins will emerge around a Fossor open source community.

    Of course, no organization is obligated to contribute the plugin they create to the open source community. There may be information in that plugin an organization considers too proprietary to share. But Callister said there are plenty of use cases where a plugin developed for one type of site might apply to another.

    One of the single biggest issues most IT organizations struggle with in managing IT at scale is a lack of engineers on staff. The average IT organization tends to rely on administrators that don’t have much in the way of coding skills. Organizations that manage IT environments that operate at web-scale typically have hired software engineers capable of developing their own tools. Open source projects such as Fossor provide a means through which software engineers working at web-scale companies can share their skills and expertise with the rest of the IT community.

    It’s not clear to what degree open source tools will replace commercial software tools. It’s not unusual for an IT vendor to leverage an open source project to create a commercial offering around which they provide extensions and professional support. But many DevOps teams are becoming more self-reliant out of necessity, either technical or budgetary. The challenge now becomes sorting through all the open source code available to determine which of the many tools available today solves a problem well enough to not only rely on every day, but also to make ongoing contributions.

    — 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 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

  • CA Technologies Extends DevOps Push

    CA Technologies Extends DevOps Push

    At its CA World 2017 conference this week, CA Technologies moved to tighten the integration between the various elements of its DevOps portfolio acquired over the last year and unveiled CA Digital Experience Insights, an analytics-infused monitoring tool delivered via a software-as-a-service (SaaS) model.

    The company also announced an instance of the CA Microservices Gateway that allows the API management platform to be deployed as a Docker container. Earlier this week, CA Technologies launched a beta release of Fastrack.io, a service for monitoring Kubernetes clusters based on machine learning algorithms and embedded in an instance of the open-source Prometheus container monitoring service.

    The company is also adding CA Virtual Test Data Manager, a tool that makes it simpler to create copies of large data sets for testing purposes, and CA Service Virtualization Community Edition and CodeSV, a plug-in that enables DevOps teams to invoke service virtualization from within their integrated development environment to mimic external services without having to connect to an actual instance of those services running in a production environment.

    Additionally, CA Technologies announced it has integrated CA Veracode security testing software with CA Automic IT automation platform, and announced general availability of BlazeMeter API Test, a SaaS-based API testing tool, and CA Continuous Delivery Director SaaS, a service that integrates the DevOps toolchain.

    Aruna Ravichandran, vice president of DevOps product and solutions marketing for CA Technologies, says each of these offerings are part of a larger company effort designed to enable organizations to set up their own software factories. Now that more organizations have come to realize their ability to differentiate themselves depends on custom software, many of them want to be able to acquire all the integrated DevOps tools required to achieve that goal from a single vendor, Ravichandran says.

    CA Technologies is making a concerted effort to link the need to create a software factory as a prerequisite for driving digital business transformation at scale. To achieve that goal, she says, control over IT operations is continuing to shift to the left as developers become more accountable for the entire application experience. Offerings such as CA Digital Experience Insights make it simpler for developers to holistically manage those end user experiences by infusing predictive analytics and machine learning algorithms coupled with improved data acquisition techniques in a single service, Ravichandran says.

    CA Technologies clearly wants to become a DevOps force to be reckoned with. In the last two years it has acquired Blazemeter, Automic, Veracode and Runscope. Prior to that, the company acquired Rally Software, Nolio, Grid Tools and Layer 7 Technologies. From here it’s likely CA Technologies will continue to expand its portfolio by acquiring companies while tightening the integration between the various code bases that make up its DevOps portfolio.

    The company’s stated goal is to provide a suite of DevOps tools and services that are too compelling to ignore without forcing IT organizations to consume a product or service they don’t want by maintaining open interfaces across the portfolio. The degree to which CA Technologies can succeed in that effort remains to be seen. But there’s no getting away from the fact that the company has now assembled a formidable DevOps arsenal of products and services.

    — Mike Vizard

  • Building a Services and IoT Platform with DevOps, Part 4

    Building a Services and IoT Platform with DevOps, Part 4

    IoT platforms and their solution development have crossed different maturity levels. At first, devices were primitive, isolated and working with limited functions before slowly evolving to communicate and connect with other devices using lightweight communication protocols, and then stepping into advanced level with remote management of devices, harvesting the data from devices and smart decisioning and analytics. Beyond that, IoT has moved to optimized levels of using multiple technology options and adopting cloud and DevOps disciplines to build intelligent IoT solutions.

    This article focuses on giving insights on choice for IoT platforms and factors influencing build or buy options for IoT solutions, different hosting options, factors on IoT development in the cloud and more.

    IoT Platforms: Build, Buy or Both?

    The dilemma of whether to build an IoT system from scratch or buy an off-the-shelf platform still continues. Below are some of the key factors to consider before making the critical decision.

    1. Price: If you plan to build an IoT platform, the infrastructure setup and operation costs can be high. And, as you plan to scale, there will be additional infrastructure cost in setting up additional data centers in that region. If you buy an IoT platform, prebuilt infrastructure is available across global data centers to scale out on a per-usage basis. Plus, you get the the benefit of buying devices from a certified partner ecosystem with discounted device prices. You can buy a few devices from cloud vendors or other device manufacturers, and use mix of devices, mix of cloud/multi-clouds or on-premises, using mix of platform as a service (PaaS)/infrastructure as a service (IaaS) at competitive prices.
    2. Time to Market: A house-built IoT systems will typically take about six to 12 months to complete, including infrastructure setup, device development and software development and testing. Depending on the complexity of the business case, the release cycle may take even more time to get to production, especially with ongoing device technology updates, lack of protocol standards and new business demands.
      Under the buy option, you can buy preconfigured end-to-end solutions available for common IoT use cases such as remote monitoring, predictive maintenance and connected factory, and these solutions can be customized based on need. You can even try to build only few components of IoT solution which may not be available from the vendor, such as the devices/edge, build a field gateway and use preconfigured solutions for data ingestion and data processing, data analytics and data storage components. There are starter kits available to quickly prototype, evaluate and deploy, eliminating spending more cost and effort, before hitting to the ground.
    3. Skillset/Expertise: Building an IoT platform requires a skilled team with expert knowledge of software and hardware and development, which costs more. Currently there is lack of skilled IoT experts with a mix of software and hardware knowledge in traditional industrial-based enterprises.
      When buying a IoT solution from vendors, the solutions are prebuilt and guided by standards and best practices. The platforms are built by experts who are proven with cloud infrastructure, based on their experience working with large customer base and customer support—necessary for IoT platform development.
    4. Scalability: When you plan to scale your business, you need to scale your infrastructure as well. With millions of devices connecting to your infrastructure to send and receive data and firmware updates, monitor the devices, support multiple range of network providers and store large volumes of data being collected and processed, you need a scalable infrastructure on-premises or in the cloud to meet those demands. Setting up a scalable infrastructure on your own requires skilled labor, effort and cost.
      Real-time streaming and data processing capability is available for large volumes of data workload, enabling scaling of individual components of IoT solution, as well scaling as scale units (group of components for data ingestion, data processing and data storage). Choices of different cloud vendors give you options to scale based on demand, horizontally or vertically, adding/removing devices with portability options and providing on-demand simulated test environments with the flexibility to choose multiple clouds or a mix of PaaS/IaaS options from different clouds or hybrid infrastructure.
    5. Security: For in-house IoT development, teams should be aware of various security attacks and develop systems with current security strategies and technologies to both protect data and devices and maintain data privacy. A large infrastructure is needed to support the sandboxed hosting of data in separate geographic regions for secure data storage, device security and user security.
      IoT platform vendors provide security standards. For example, Microsoft provides SDL (Security Development Lifecycle), which enables developers to follow the standards during device development and ensures development happens with security built at all parts of system. These platform providers have prebuilt infrastructure for secure data storage, cloud security, user security, application security and device security, and has separate security teams to protect the data at all levels.
    6. Analysis & Visualization: It’s estimated that 90 percent of the large volumes of data collected from millions of devices remains unused in most enterprises. To tap the data for valuable business metrics, data analysis/algorithms should be updated as industry and device requirements change and extensions are needed to integrate data with data analysis tools to churn the data. There are open-source and proprietary tools available for data mining and data analytics and custom dashboards must be built to monitor the telemetry, setup rules and actions.
      Preconfigured solutions and most IoT platform providers have out-of-box data analysis tools integrated and rules can be defined to analyze data with customizable dashboards, enabling you to focus more on business outcomes and how to churn/mine data, rather than focusing on building algorithms/tools/dashboards from the scratch.

    Factors Driving Cloud-based IoT Development

    Considering the various factors, a hybrid option with mix of buy and build for IoT platform components is better compared to building the platform from scratch, as you get out-of-the-box features from the off-the-shelf platforms that are customizable and extensible to business needs.

    The following are some of the factors driving more and more IoT development in cloud (single/multi-cloud/hybrid), making IoT grow exponentially:

    1. Increasing number of devices – billions/trillions of devices interconnected
    2. Need for remote processing power and high compute
    3. Need for hyperscale systems for processing hot/cold/warm/fast data pipeline with low latency
    4. Need a platform that can quickly evaluate, prototype and deploy IoT applications
    5. Need a platform that provides security by design across devices, gateways, networks, data processing, users and applications
    6. Usage of advanced analytics and monitoring solutions available in cloud
    7. Leverage interdevice communications, interservice communications
    8. Utilize preconfigured IoT solutions for most of the popular use cases such as remote monitoring, predictive maintenance, with proven practices/patterns.
    9. High data storage, highly scalable with minimum cost to deploy
    10. QoS features in cloud—security, performance, usability, backup, etc.
    11. Cloud gateway providers have support for various devices and provides extensibility
    12. Cost of devices, cost to deploy and internet usage has dropped
    13. Out-of-box support and availability of big data and machine learning techniques in the cloud with mobile data visualization
    14. Ease of integration with DevOps tools in cloud, end-to-end testing with simulated devices as containerized environments in cloud

    Expanded internet connectivity, reduced cost of devices, increased spread adoption of remote devices such as smartphones, usage of big data, machine learning techniques and cloud adoption, competitive pricing models and more are the key drivers for IoT’s growth in cloud.

    About the Author / Lavanya Subbarayalu

    Lavanya Subbarayalu is Senior Architect working with Technology Office in HCL Technologies. She has expertise in IOT, Azure, DevOps consulting & Microsoft technologies. She is associated with DevOps COE, working on design and Development of DevOps solutions and consulting tools. Connect with her on LinkedIn.

  • MongoDB Addresses Host of DevOps Issues

    MongoDB Addresses Host of DevOps Issues

    At its MongoDB Europe conference this week, MongoDB updated its open-source document database with the addition of MongoDB Ops Manager to simplify management of distributed instances of version 3.6 of its database.

    In addition, the company has added a capability that enables all updates to the database to be automatically reflected in the application in real time without having to take the database offline.

    Additional new capabilities include a MongoDB Compass tool to analyze schemas and a governance capability that makes it easier to apply and tune data governance polices before and after an application is deployed.

    The company has added an aggregation pipeline that allows users to perform real-time analytics directly in the database to improve performance. Developers and analysts now can write queries combining data from multiple collections for complex analytics. Its Connector for BI, which can now be deployed and managed by its Ops Manager, has been updated to support this new query capability.

    Finally, in the event of a system failure or network outage, MongoDB says it now automatically will replay any writes to the database when those services come back online.

    Brooks Circhlow, vice president of product for MongoDB, says developers have embraced document databases as an alternative to other database platforms because of their flexibility. Unlike, for example, relational databases, a document database doesn’t impose a schema that must be crafted by a database administrator. But as more instances of document databases proliferate across the enterprise, DevOps challenges start to manifest.

    In fact, Circhlow notes that IT organizations are also making extensive use of cross-replication capabilities across multiple database clusters that they manage or are managed on their behalf via the MongoDB Atlas managed service. In many of those instances, DevOps teams are responsible for both the applications and the document databases they run on.

    MongoDB is also moving to address a DevSecOps issue stemming from a wave of attacks aimed at misconfigured instances of its database. Circhlow says the most widely used installer for MongoDB limits network access by binding to localhost by default. With version 3.6, binding to the localhost is now extended to all MongoDB packages across all platforms. In addition, with new IP whitelisting support, administrators can configure MongoDB to only accept external connections on approved IP addresses.

    Document databases such as MongoDB arguably have been a primary catalyst for DevOps. Once developers began to bypass database administrators by downloading instances of document databases, it became clear that traditional approaches to IT operations were starting to erode. Most organizations would prefer their developers to write code than manage databases, so some new means for managing databases that doesn’t compromise the dexterity that document databases provide developers was required. Once those processes get established, the next question then becomes how to make traditional database administration involving other classes of databases part of that process. Most IT organizations are still working through those processes. But it’s clear database administration will never be the same.

    — Mike Vizard

  • Nutanix Extends DevOps Ambitions

    Nutanix Extends DevOps Ambitions

    Nutanix at its .NEXT Europe conference has signalled its ambitions now extend into the realm of DevOps. The company announced it will make available an Acropolis Compute Cloud (AC2) and an Acropolis Object Storage Service on top of its Enterprise Cloud OS software that creates an instance of a hyperconverged infrastructure (HCI) platform that can be deployed on-premises or in a public cloud.

    In addition, Nutanix is embedding an App Marketplace in its Nutanix Calm orchestration software through which applications developed on top of Enterprise Cloud OS can be accessed.

    Finally, Nutanix has added Veritas Technologies to the list of providers of data protection software that can be employed to provide backup and recovery software for applications running on top of its core AHV hypervisor.

    Greg Smith, vice president of product marketing for Nutanix, says his company is now moving well beyond simply trying to combine compute and storage in a locally deployed appliance. It envisions organizations employing Enterprise Cloud OS to drive hybrid cloud computing applications across a consistent set of automated orchestration services based on a common platform optimized around an HCI architecture.

    HCI architectures were pioneered by cloud service providers, and Nutanix applied those concepts to local data centers in the form of an appliance. The company then took the software it developed for the appliance to create a portable cloud operating system environment it is now extending with, for example, an object service that is compatible with the S3 interface defined by Amazon Web Services (AWS).

    Smith says Nutanix is making the compute and storage services available on top of Enterprise Cloud OS as an alternative to more expensive compute services based on platforms such as VMware. Nutanix is essentially in a race against other providers of HCI software to extend the reach of its platform. VMware, for example, has made its software stack available on the IBM Cloud and similarly is working to make its software available on AWS. Smith says the Nutanix approach gives IT organizations more control over where they want to deploy HCI software on any platform, including server platforms from Cisco Systems, Dell EMC, Lenovo and Hewlett-Packard Enterprise (HPE) if they so desire. All three of those vendors also provide access to rival HCI software platforms.

    Nutanix developed its own hypervisor on which Enterprise Cloud OS is built to enable its software to be deployed on multiple platforms. But just to make things more interesting from an IT operations perspective, Nutanix also has HCI software that can be deployed on a VMware hypervisor.

    Against that backdrop, IT organizations are trying to determine the rate at which they want to replace traditional rack-based systems with HCI platforms, which combine compute and storage to reduce the total cost of operating an IT environment. Most legacy applications still expect to access external storage. But as new applications are developed, the expectation is that most of them will run on some form of an HCI platform that can scale out to support a much broader range of applications.

    It’s not likely legacy applications running on rack systems will go away anytime soon. But it is apparent that IT operations teams will be managing a mix of rack and HCI systems for years to come.

    — Mike Vizard

  • Node.js Foundation Embraces HTTP/2

    Node.js Foundation Embraces HTTP/2

    The latest version of Node.js will significantly increase the DevOps challenges surrounding the most widely used version of JavaScript in the enterprise. Node.js 8 adds the ability to support HTTP/2, a major revision of the core internet protocol that, in addition to being significantly faster, enables developers to make multiple requests over a single connection as well as set up pipelines for making a series of requests.

    Myles Borins, director of the Node.js Project and member of the technical steering committee at The Node.js Foundation, notes that while HTTP/2 eventually will be supported by multiple programming languages, DevOps teams most likely will encounter it first in web and mobile applications built using Node.js.

    Borins says HTTP/2 also should go a long way to accelerating the adoption of microservices applications—the majority of which are being built using Node.js.

    Node.js 8, available under a Long-Term Support (LTS) license, is 20 percent faster than its predecessors, Borins says. It is based on the JavaScript V8 engine that makes use of Turbofan and the Ignition compilers and interpreters, which equates to lower memory consumption and faster startup time across Node.js applications.

    Other new features include an Async/Await capability that allows developers to write more linear code versus relying on callbacks and a series of Experimental ES Modules that provide a standard pattern for writing modular JavaScript code that can run on both the web and in Node.js.

    Node.js 4 is now scheduled to be designated for end-of-life status in April, and Node.js 6 will face a similar fate soon after. The Node.js Foundation is encouraging organizations that have deployed Node.js applications to refresh them because security patches and updates soon no longer will be available for the core engines used in Node.js 4 and 6 applications. Node.js API (N-API), a project that enables modules to run against new versions of Node.js, is still considered experimental. That project is being lead jointly by Google, IBM, Intel, Microsoft, nearForm, NodeSource and individual contributors.

    The Node.js Foundation also announced that work has begun on Node,js 9, which is focused on modernizing legacy application programming interfaces (APIs) and implementing a new error system that associates a unique code with all errors in place of relying on traditional error messages.

    The Node.js Foundation estimates there more than 9 million instances of Node.js deployed across the web today, so managing Node.js applications across their life cycle has become a significant DevOps challenge. While Node.js is not the only programming language gaining momentum across the enterprise, the Node.js community is highly focused on increasing the robustness and manageability of Node.js applications in a way that should eventually please even some of the most hardcore fans on rival languages such as Java or even COBOL.

    — Mike Vizard