Whilst NonStop remains the world’s No.1 choice for Mission-Critical systems, identifying and retaining resource with the...
It’s been a while since anyone has heard from me on the subject of GitHub. Well, my speaking coach always did say “Lead with a joke”. As many of you know, Microsoft bought GitHub some months ago, bolstering a move in the version control systems (VCS) community from the centralized repositories to the distributed. It also firmed up git’s hold on the distributed version control system (DVCS) market away from Mercurial – GitHub does not support Mercurial, unlike BitBucket, which does – although the general sense is that there are way more git repositories at BitBucket. When Microsoft paid all that money for GitHub, the private repository price plans were a bit much for the lone developer who wanted to keep stuff private. BitBucket was the Cloud provider of choice for people who wanted to go on the cheap, offering free private repositories for teams of up to five people. While it’s hard to make a profit on volume when you’re not charging anything, BitBucket developed loyal followers, who pulled it into the enterprise, and there are some massive installations exceeding 25,000 users in one notable financial institution – seriously. 25,000 git users. Now I know why I’m having trouble hiring. Talk about demand.
Then a relative newcomer to the table, GitLab, who is constantly bringing out new features, started offering self-hosted free options. That coupled with some really hot inexpensive common off-the-shelf (COTS) VM servers – look up Antsle, as an example, for some awesome virtual machine packages and pricing, not that I’m recommending – made GitLab a serious player. Between GitLab and BitBucket, the never-free model that Microsoft purchased started looking a bit bloated. And then it happened: GitHub now has free plans for small teams. There’s a surprise… to no one ever. But wait, there’s more.
In an effort to keep up with GitLab’s innovations, both GitHub and BitBucket are continuing to bring out their own features, mostly in terms of full function DevOps stacks in the Cloud and integrations in the enterprise. Now get this: for free, you get git, code reviews, approvals, security models, process engines, build engines – sadly not for NonStop (yet: hint, hint, HPE Product Managers), problem tracking, and recently deployment integration. All they must do is add project management (some are starting to do that), and connectors to a Cloud ERP system, and a bunch of us will be out of jobs. This is serious stuff. We’re talking out-of-box, free, relatively complete development environments – just add developers or sufficiently well-funded AI systems. It was inevitable that Microsoft would figure what the packaging really offered and change the GitHub price-point to line up with the competitors.
Jenkins and Ansible
What may seem strange about the above packages is that none of them chose Jenkins or Ansible as a basis for build or deployment. On the surface, this may produce a little doubt about the future of these two relatively new products. But that’s really not the case. Unlike the minimalist (currently anyway) offerings in git providers, Jenkins has a huge ecosystem, with plugins that do almost anything and support almost everything, including NonStop. Cloudbees has emerged as full-support Jenkins vendor, so if you want to pay for support instead of doing it yourself, there you go. One little bit about the Jenkins community you should know, though. The rate at which new releases come out is rather staggering. It is sometimes hard to keep up with the updates, but you must. Because of the size and penetration of that ecosystem, it does get a lot of attention from those who try to break things, and Jenkins ends up with a lot of people fixing it – it’s all in Java, so the contributor base is massive – that’s a good thing considering how often the industry gets hit with potential security vulnerabilities in Open Source libraries. So, my take is to accept it and keep your Jenkins up to date as best as you can.
Unlike Jenkins, Ansible tends to move slowly – too slowly for my tastes. It is a bit ironic for a product that does deployment to not do many release deployments. The number of contributors seems to be tiny compared to Jenkins, so that may be part of it. I’m not sure how much RedHat drives the Ansible agenda, but getting new features and fixes done takes time even with Python’s rising popularity. RedHat also has a big-expensive-pretty-sparkly enterprise-class pricing product called the Ansible Tower. Don’t expect me to contribute anything there – at $13,000/year starting price just to play, that’s not going to happen, but I’m sure there are people with big wallets out there who like slick monitor windows. But building core Ansible modules to do cool things is pretty easy once you figure out how the product works.
The price reduction and availability of inexpensive git servers fits nicely into what I’m doing with NSGit – you know, the git front-end for GUARDIAN. We recently brought up a GitLab instance internally for under $2000 total investment including the server, which we are using for our release artifact repository. Since TBC, we have been working on plugins for Jenkins and ECLIPSE, and modules for Ansible.
Since the move to one of the big three, GitHub, BitBucket, and GitLab, is easy once you’re in the git space, the benefits you get are unquestionably worth it. With new features coming out almost monthly, your DevOps stack will continue to improve without needing much capital investment at all. It’s important to keep looking at the main pages (and release notes, of course) to see all the goodies that come with new releases. I myself have had a few stunned moments as features I only dreamed about suddenly showed up without even asking for them.
One gotcha in the Ansible space: there is no provision for any kind of vendor branding of plugins or modules. The names are currently limited to any valid Python variable name. So suppose I created a module called nonstop_sqlmp_compile (which I did, by the way, which does the obvious thing in production), there is nothing stopping anyone else from naming their own Ansible module the same, with rather catastrophic conflicting results. I recently brought this up with HPE Product Management, and hopefully we will get guidance on solving this problem. RedHat does not seem to want to participate in managing the situation, so it’s up to us.
But I can say with the certainty of experimentation, research, development, and getting pushed down this path by customers, which we can all benefit from learning this stuff. Having Ansible scripts to manage routine network and application management functions for our NonStop is a real plus, once you conquer the learning curve. Letting Jenkins drive the automation, timing, and monitoring of your Ansible activities can also be very effective, and much cheaper than the Ansible Tower. And then, of course, there’s the whole git ecosystem to manage the movement of our application and configuration changes, but you all probably know about that particular soapbox of mine. If not, drop me a line at email@example.com.