Richard Bucker

Introduction to AppScale and Google App Engine - Part 1

Posted at — Nov 23, 2014

I’m not certain how many parts this is going to take and what the outline looks like. It’s off the cuff but I hope you find this interesting nonetheless.Lately there has been a lot of interest in micro services in the form of Docker. While I am a Docker fan and categorizing it as a micro service container started me thinking about monolithic and micro kernel operating systems; and that also forked a conversation about J2EE and google app engine; with a little flow based programming sprinkled in for good measure.From the history perspective micro-based systems are faster but harder to orchestrate and debug. This is the one prevailing reasons why MicroSoft’s monolithic Windows kernel defeated IBM’s microkernel (but that war might have also been over before it started for many other reasons not related to the kernel). Testing a micro service itself is not difficult it’s the integration testing within the system and testing the orchestration system/bus itself.I recently implemented a flow based programming system in go. It was very simple to design and code the nodes. It was straightforward to write test cases. It was even trivial to wire the nodes together in order to define some sort of flow. And graphing the nodes into some sort of visualization was also pretty simple. The system was very data driven so generating queries or refactoring the nodes and reuse became favorable. The only downside is/was that there was no debugging.  GoLang does not currently have a debugger and while the application took advantage of lots of goroutines (one goroutine per node); debugging by writing log messages was not reliable due to timing and intermingling of messages from the concurrent goroutines.I’m not suggesting that micro services in the many new incarnations are good or bad but I would say that I’m in the business of adding business value for my employer. And in such a position there is a balance between cool tech, future proof, technical debt, and getting shit done.A few killer reasons for going after app engine are [1] it supports some modern languages including golang and just around the corner dart [2] If the code is implemented correctly then scaling can be a simple matter of increasing the instance count [3] simple APIs for storage, query, cron, MQ.** I have been administering close to 15 machines for friends over the past 20 years. The only thing I need to do is upgrade the operating system about once a year and apply patches once or twice a month. The challenge is having to remember what I did last time and what the risk is. Worse still is not being 100% certain what the recovery from a failure might be. I’m even thinking about backup/recovery of the user data.  It’s just a big mess. If I had implemented these apps in app engine things could be a lot more carefree.I’ve decided to restart my app engine experience with app scale and  going through the getting started exercise using virtualbox on my laptop following these getting started docs. (For OSX)install homebrewinstall ssh-copy-id (not available by default)brew install ssh-copy-idinstall virtualboxinstall vagrantregister the image with vagrantconfigure and install your virtual terminalI had to perform the vagrant up command twicedeploy appscale on VMthe appscale up command required ssh-copy-id** this outline is now incomplete because I could not get past this step.There are a few more steps from here but I’m stopping for now.  Appscale is throwing an exception which is going back to vagrant which [a] has installed version 12.04LTS and is complaining about 14.04LTS [b] the guest is aborting. So I have to restart assuming that I missed a prerequisite when I installed everything else… so to the beginning.<timeout/>After trying the appscale install on virtualbox from the beginning I have had no luck. I get the same error(s) which suggest that there is an IP address mismatch between the appscale private network and the hosted network. As well as the hosted tools.** running this framework means that eventually I’ll be running on GCE. By deploying on GCE I will not be bothered with the host or guest OS versions. This is a big deal. It’s the one reason I really like Docker+CoreOS. And even though I have indicated that micro-services are a challenge to debug it’s not impossible. So, for the moment, there is no winner.  In part 2; I will try the installation on Google Compute Engine (that’s GCE and not GAE), however, this will be a little self defeating if I cannot get it to work on a plain vagrant install.I’m just guessing; but in part 3 I might try to install appscale on my own VM install. And wondering if it’ll install on CoreOS as-is.