Baskettecase

Today, I decided to play around a bit with the new local Kubernetes support in the new beta release of Docker for Mac.  I decided to take the Project Riff Setup work done by Brian McClain from my Tech Marketing team and get it working on this new environment as a quick test of its functionality and usability.    It’s actually REALLY easy to get started with the support.  Once you download and install the Beta, you need to enable the support within Docker.   You can find the settings inside the Docker Preferences panel. Once installed and up and running, it pretty much acts like minikube in that you get a tiny K8S implementation to play around with.   In order to test with Brians's stuff, I needed to make a few tweaks.  (https://github.com/dbbaskette/riff-demos).    1) Obviously, the minikube install and start can be removed. 2) You have to change your context to "docker-for-desktop" 3) minikube has a nice comman...

In my earlier years, NBC Television had a slogan for their primetime television line-up: Must See TV.   It really was must see, because there wasn’t a great way to watch it later if you missed it and most people in the office were talking about what happened the next day.  So, if you missed it, you either got a verbal recount of the show or you waited 6 months.  I have been to way too many conferences in my career and very few of the main stage presentation or keynotes would fall into what I would consider the Must See category.  SpringOne Platform 2017 provided us with LOTS of those moments, and thanks to recordings and streaming video, this Must-See TV can be posted for easy consumption.    If you missed the event, I encourage you to at least take a look at the replays of the Keynotes from S1P.   The Pivotal speakers all kept their presentations light, yet informative with a good dose of humor.  I will be the first to admit that vend...

I recently read a blog discussing the fever to declare Hadoop as dead. While I agreed with the premise of the blog, I didn't agree with some of its conclusions. In summary, the conclusion was that if Hadoop is too complex you are using the wrong interface. I agree at face-value with that conclusion, but in my opinion, the user-interface only addresses a part of the complexity and the management of a Hadoop deployment is still a complex undertaking. Time to value is important for enterprise customers, so this is why the tooling above Hadoop was such an early pain-point. The core Hadoop vendors wanted to focus on how processes executed and programming paradigms and seemed to ignore the interface to Hadoop. Much of that stems from the desire for Hadoop to be the operating system for Big Data. There was even a push to make it the  compute cluster manager for all-things in the Enterprise. This effort, and others like it, tried to expand the footprint of commercial distributions...

Most of my career has been spent on infrastructure and data products, but recently I was asked to refocus slightly and work a bit more with data architectures in the cloud.  That's a pretty broad list of topics, but who doesn't love a challenge.   One of the first things I like to do when working with a new set of technologies is to set them up, break them, set them up again, and break them in a new and novel way.   I am actually pretty talented at breaking things, so this part comes really easy.    My first adventure was setting up Pivotal Cloud Foundry with Google Compute, and then using the Google Compute Service Broker.   The first step was getting the IaaS setup and configured. I looked around a bit and located a very helpful Terraform repo that was exactly what was needed to jumpstart the process.   Now, the process of setting up Google Compute for PCF was as simple as setting a couple variables and then running terraform a...

I have been working with Hadoop for quite a few years now and frequently find myself needing to try bits of code out on multiple distributions. During these times, the Single Node virtual editions of the various Hadoop distributions have always been my goto resource. Of all the VMs available, I believe the most seamless and well done version is the Hortonworks Sandbox. In fact, in the work I am starting now, to build a new PHD3.0 and HAWQ virtual playground, I view the Hortonworks Sandbox as the bar that needs to be exceeded. When we at Pivotal first announced HAWQ would be available on HDP, some of my first thoughts were about how nice it would be to provide customers the ability to install HAWQ directly onto the Hortonworks Sandbox to provide them with a place to take the software for a spin. Earlier this week, I had a request to do a live customer demonstration of installing HAWQ on HDP 2.2.4 leveraging Ambari.   This activity kicked off those Sandbox thoughts agai...

Continuing on the theme of "So easy that Hulk could do it", I recently wrote this document as a Pivotal blog piece, but I seemed to outrun the startup of the new Pivotal Technical Blog.   So, it was decided to add the content to the product documentation since the blog is still in a "coming soon" state.    Nothing earth shattering here, just some best practices for taking slave nodes out of the cluster in the proper manner. Decommissioning, Repairing, or Replacing Hadoop Slave Nodes Decommissioning Hadoop Slave Nodes The Hadoop distributed scale-out cluster-computing framework was inherently designed to run on commodity hardware with typical JBOD configuration (just a bunch of disks; a disk configuration where individual disks are accessed directly by the operating system without the need for RAID). The idea behind it relates not only to cost, but also fault-tolerance where nodes (machines) or disks are expected to fail occasionally without bringing...