No one enjoys changing hosting providers. I haven’t had to often, but when I have, it involved manual configuration and copying files. As I’m looking to deploy some new projects, I’m attempting to automate the provisioning process, using hosting providers with Application Programming Interfaces (APIs) to automatically create virtual machines and run Ansible playbooks on those machines. My first attempt involved installing DC/OS on DigitalOcean which met with mixed results.
In this post, I’ll be examining Bee2, a simple framework I built in Ruby. Although the framework is designed to be expandable to different providers, initially I’ll be implementing a provisioner for Vultr, a new hosting provider that seems to be competing directly with DigitalOcean. While their prices and flexibility seem better than DigitalOcean’s, their APIs are a mess of missing functions, poll/waiting and interesting bugs.
Back in 2013, a startup known as Cloud at Cost attempted to run a hosting service where users paid a one-time cost for Virtual Machines (VMs). For a one-time fee, you could get a server for life. I had purchased one of these VMs, intending to use it as a status page. However, their service has been so unreliable that it’s a shot in the dark as to whether a purchased VM will be available from week to week. Recent changes to their service policy are attempting to recoup their losses through a $9 per year service fee. It’s a poor attempt to salvage a bad business model from a terrible hosting provider.
I used to work at the University of Cincinnati and whenever I got frustrated at staff meetings, I’d threaten to move to Australia. After a $300 application fee and a surprisingly short approval process, I had holiday work visa which allowed me to live and work in Australia for a full year. My manager led me to our director’s office. With my resignation letter on his desk, my director simply asked, “Do you want more money?” to which I responded, “I’m moving to Australia.” There were confused looks from the two of them, awkward silence and finally, “No, really … I’m moving to Australia.” It was the first time I had left the relative security of a full-time position, and it wouldn’t be the last.
In recent months, there has been considerable debate by videos creators on YouTube about the future of generating revenue through Google’s extremely popular streaming video service. Advertisers are backing away from more controversial content and YouTube has begun to demonetize several types of videos. Services like Flattr, which attempted to allow content consumers to fill the tip jars of creators, have slowly fizzled. Yet out of those ashes has come a new service known as Patreon, which allows fans to directly contribute to the continual production of many varieties of art.
When I lived in Australia, sending money to an individual or business was as simple as knowing their Bank State Branch (BSB) number and account number. I could go through a web interface, or a phone app, and send $50 to a friend. It would show up the next morning in their account (or potentially the same day if we used the same bank). This transfer went through a government system known as the Australian Payments Clearing House (APCA), was completely free of fees for individuals and worked with all banks in Australia. Many countries have similar systems, some adding additional security with one-time use Transaction Authentication Numbers (TANs).
Although America has a means of electronic transfers between banks, it’s not available for individual person-to-person transfers. Automated Clearing House (ACH) transfers are only available to certain businesses and the means for verifying identity and exchanging money via it are slow and convoluted. I honestly hadn’t realized how far behind the American banking system was until I spent several years exposed to various foreign banking systems.
For the past couple of years, we’ve seen a substantial amount of research committed by the tech and auto industry into self driving vehicles. Billions of dollars are being spent on a solved problem; depending on how you view the problem. If the domain of the problem is transportation and increasing populations within metropolitan areas, automated driverless trains have been a reality for quite some time. I’d argue that solving the domain space of individual automated cars, while contributing significantly to the fields of machine learning and computer vision, is a wasted effort when it comes to sustainable transportation solutions for the planet.
Earlier this year, I decided to build a development desktop. It’s the first PC I’ve fully built in at least four years. While I was backpacking, I relied solely on my laptop for development work. Prior to that I had used desktops people were giving away, or systems I had build years ago and had just continually upgraded. Since this would be a Linux workstation aimed primarily at development, the hardware was focused on performance. It would be built with 32GB of DDR4 memory, a 6700K i7 processor and dual M.2 solid state NVME drives connected to the PCI-E bus in a software RAID0 (striped) configuration for performance.
Mesosphere DC/OS is a data center operating system, based on Apache Mesos and Marathon. It’s designed to run tasks and containers on a distributed architecture. It can be provisioned either on bare metal machines, within virtual machines or on a hosting provider (what some people like to call “the cloud.”). I wanted to see what was involved in setting up my own DC/OS instance, both locally and with a provider, for running some of my own projects in containers. I wanted to keep this cluster as low cost as possible, and ran into some issues with the Terraform installation in the DC/OS documentation. The following is a brief look at setting up a minimal DC/OS cluster on Digital Ocean.
I had been using a Banana Pi BPI-R1 as my router. Due to some reliability issues, I attempted to replace it with a ClearFog Pro, which also met with unfavorable results. Many hobbyist tend to use old PCs as routers, as I have in the past. Due to some scaling down, I no longer have a bucket of spare parts to build a low powered Linux box. Instead of going with another ARM solution, I decided to build a custom x86_64 system based on the Thin-ITX form factor. I discovered that a x86/Thin-ITX solution was more reliable than the ARM alternatives I have tried, and ran the same cost as a high end home router.