"We can not solve our problems with the same level of thinking that created them" ― Albert Einstein

Why we moved from AWS Beanstalk to Google AppEngine

I'm continually exploring various cloud offerings. Heroku, Google Cloud, Azure, AWS, etc... Previously Lodgik.com (a Rails 5 app) was hosted via AWS ElasticBeanstalk. Even though everything worked perfectly fine once it was deployed, I had a lot of concerns with the difficulty / quirks involved. A few of the issues I faced and wasn't very happy about with AWS Beanstalk:


  1. Environment variables configured in .ebextensions didn't completely map to the deployed app. Instead, I had to set some (not all) of the env variables in the admin console. There doesn't seem to be a good explanation for why some would map and others just didn't show up.
  2. The configuration files used when deploying the app were complex, confusing and didn't always work as expected.
  3. The cost of a simple, very modestly resourced deployment of this simple site was running $80+ a month. Which seemed excessive considering the auto-scaling configuration had a minimum of 1 instance and scaling was not ever being triggered to use more.

Regarding the configuration files, here's a comparison between Beanstalk's configuration and Google AppEngine's:


AWS Beanstalk:

option_settings:
aws:elasticbeanstalk:application:environment:
BUNDLE_WITHOUT: test, development
RAILS_SERVE_STATIC_FILES: true
RAILS_SKIP_ASSET_COMPILATION: false
RAILS_SKIP_MIGRATIONS: true
SECRET_KEY_BASE: REDACTED
DB_NAME: REDACTED
DB_USERNAME: REDACTED
DB_PASSWORD: REDACTED
DB_HOSTNAME: REDACTED
DB_PORT: 5432

Another file was also required which would force each EC2 instance spun up to run assets precompilation for Rails production


Total configuration settings required 50+ lines spanning 3 very specifically named files.


Google AppEngine:

env_variables:
SECRET_KEY_BASE: 'REDACTED'
DB_NAME: 'REDACTED'
DB_USERNAME: 'REDACTED'
DB_PASSWORD: 'REDACTED'
DB_HOSTNAME: 'REDACTED'
DB_PORT: '5432'

Everything is contained in a single app.yaml file and totals 35 lines which are easier to read/follow. They also all worked exactly as expected. Overall just simple.


Google's console admin interface is really clean and well designed. Whereas AWS' feels clunky and like the UX team didn't have a chance to weigh in on anything. Logging, additional services, security, connecting a code repository for auto-deployment... all extremely intuitive and easy.

Overall, I'm thrilled to see that Google is putting a lot of solid competitive pressure on AWS. While their offerings aren't nearly as diverse as AWS, they do seem to be thinking things through more than AWS is. I'm excited to see where Google's cloud platform goes. 

AWS and Terraform Experimentation

We've been experimenting with AWS services. Specifically, how do we best utilize IaC (Infrastructure as Code) concepts when deploying entire application stacks? The answer (as many of you know) is not a simple one. There are several technologies that attempt to tackle this problem. Each of them require a bit if buy-in and investment, which means ample research is required before making a selection. 


Our latest experiments involved comparing AWS ElasticBeanstalk with something more agnostic (in this case Terraform by Hashicorp).


AWS Elastic Beanstalk (EBS):

We had a lot of trouble finding appropriate documentation to support an IaC philosophy when it came to Beanstalk. The only reliable way we've found so far to deploy a highly customized rails application on Beanstalk is to use the AWS console (not IaC friendly) and then pulling configurations via the eb cli to further tweak. However, some of the settings that are documented (which should work) with the eb cli simply did not update their appropriate settings on the application. Obviously there's a way to do this effectively, but solutions are not clear or well documented by AWS. There's also a fair amount of magic happening with EBS, which makes any SysOps Engineer uncomfortable. You always want to know why and exactly how something failed. That's not information that can always be ascertained when using EBS.


Terraform by Hashicorp:

Terraform is mostly focused on orchestration and less on provisioning. That doesn't mean it can't provision, but it's not as robust as other technologies (Chef for example). It's also worth noting that Terraform is still pre-1.0, so there may be a lot yet to come in the area of provisioning. All that said, Terraform performed amazingly well. Configuration is clear and well-documented. And since there's no "console" (admin) tool, everything is done with configuration files. As it should be if we're aiming for true IaC solutions. The drawback here is that Terraform has some trouble updating existing resources. It seems heavily geared around a "we create everything from scratch" philosophy. Again, as we're still new to the technology, existing resource updating may be possible, but it's not clear on how that would work. Especially when destroying a stack that has updated existing AWS resources. It seems to fail on reverting config updates since it's thinking that the resource should not exist after running terraform destroy instead of just removing the configurations that were modified. 


We'll continue to share our research and conclusions as we go. Reach out if you have questions.


Migration from Digital Ocean to AWS

We recently moved my Rails applications over to AWS EBS from Digital Ocean. The goal here was to get setup on AWS's platform so I can continue to experiment with AWS's set of services. I continue to use DO for a lot of my development work. That won't change. Yet, being able to use Lodgik as a testing ground for various technologies is a primary focus. Thus the move. So here's the rundown on what we're doing now...


  1. Rails 5 app with Bootstrap Alpha6 on EBS instances for auto-scaling and continuous deployment
  2. Route53 for DNS settings
  3. Postgres for DB via an AWS RDS instance

Bootstrap4 Alpha6 and Github Work

Bootstrap 4, Alpha6 was released today. As with any Alpha release there were several breaking changes. I'm not going into the ones which were relevant to this site because is it's easy enough to track changes related to your own project if you're on the alpha release branch for your testing purposes. I will say that the navbar changed dramatically again.


I've updated the code for Lodgik.com to make use of the latest Alpha6 release. I've also added a couple quick-links to the home-page status message area. These direct to the Github repositories I've published. In 2017 I'm making a concerted effort to contribute more code to the open-source community in general. So far, it's come in the form of a couple useful (hopefully) Docker configurations.


I welcome your feedback or contributions to those two (very small) projects. Larger and more meaningful contributions to come.

Migrating to Bootstrap 4

If you're a front-end developer, you're already fully aware of Twitter Bootstrap. Bootstrap 3 is already "the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web." Yes, that's a quote from Bootstrap's site, but it also happens to be true. Even though Bootstrap 3 is an incredibly powerful, flexible and useful framework, it has always lacked in a few areas. Vertical alignment of "cells" being one of the most pervasive. Also, it was heavily reliant on basic CSS or LESS for its styling system. While LESS is a great CSS-preprocessor, it's not nearly as versatile or logical as SASS (in my opinion). There's been a consistent migration for many front-end developers away from LESS, moving more towards SASS. The fact that you had to find a port of Bootstrap 3 in order to utilize SASS's features was a point of contention. Thankfully, with Bootstrap 4 the team has made the transition from CSS/LESS to SASS as a foundation of the framework. Here's an overview of changes in Bootstrap 4: http://v4-alpha.getbootstrap.com/migration/ 


Now let's move beyond the fundamentals of styling. In Bootstrap 4 they have overhauled the grid-system, utilities and the navbar. And all of the changes are welcome ones. Regarding the grid-system, you're welcome to continue using the default table-cell structure (this is currently the default as of Alpha5) but there's a ready-to-use variable which switches "everything" over to flexbox mode. This is where CSS is headed and rightly so. Flexbox offers more features, flexibility and is more logically constructed. Here's a quick primer on flexbox https://css-tricks.com/snippets/css/a-guide-to-flexbox/ 


Right now, Bootstrap 4 is still in its earliest stages of development. The latest version as of this post is Alpha-5. Each update to the framework comes with massive breaking changes. So am I using Bootstrap 4 on Lodgik.com? Because I know the future is going to embrace the changes that come with Bootstrap 4 and I want to be fully educated on how those changes translate into real-world builds. Knowing how to migrate from v3 to v4 is going to be a huge benefit to front-end developers. Rather than wait for the actual release and try to get up to speed quickly, I think it's important to watch and experiment with the ongoing changes to better understand the reasoning behind said changes. 


I'd never use or recommend anyone use Bootstrap 4 on a production web application. However, if you have a project that lends itself to experimentation, then I highly encourage you try v4 out for yourself. Watch how structural changes evolve, keep track of project commits and if you have the time, offer your own contributions.


Since Lodgik is a site built on cutting-edge, experimental technologies, this is a perfect fit for us. If you have any thoughts on Bootstrap 4, please feel free to share them via Twitter or our contact-form. 

Site Launch

The all new Lodgik site has launched. I plan on sharing a lot of useful (hopefully) information about how the site is constructed, hosted and even eventually making the code open source (eventually). The goal is to help share experiences, shortcuts and whatever else proves useful with anyone interested.