Category: News

Cloud66 vs Opsworks, 1 year later

Cloud 66 is a managed, BYOS (bring your own server) PAAS that runs on many cloud platforms,  we have been using them for our flagship produce www.lumber.io, for about 2 years now.

Opsworks is a service provided by AWS that can manage EC2 or bare metal servers, with some handy pre built chef recipes. We have hosted our time keeping software with Opsworks for about 1 year now.

Similarities,

  • Manage Servers outside of their domain. Opsworks can manage bare metal, so can Cloud 66
  • Provides 90% of devops for you.
  • Provides handy management interfaces and monitoring of servers
  • Click to deploy

Cloud 66

Has been great for us, minus a major security issue early in their life, (delete all managed servers, yea it was bad) they have performed very well.  99% of rails just simple works on their platform, be it setting up the whenever gem for cron tasks, or sharding memcached between your servers it just works.  They tend to be a week or two behind bleeding edge releases which I feel is a very good balance between the latest and greatest and maintaining a stable production environment.

There service is built around “Stacks” or a set of servers built in the same manner with various add ons.  These stacks are meant to be replaced if you upgrade ruby or do anything major, and Cloud 66 provides methods to cleanly migrate and upgrade your stacks, IF you are using their managed backup.

All and all our time with them has been great,  with our only major complaint is the “nickel and diming”, most of the features are free but things like backup, even if you host it yourself costs money. Which I think is pretty poor practice,  a customer loosing data is VERY bad, and encouraging people to back up with there unmanaged server to AWS or something similar should not cost extra.

Opsworks

Is a whole different beast, it presents a surface of being easy to manage, but woah nelly is the learning curve high.  Using opsworks for anything beyond a rails getting started app you must know chef.  We use opswork to manage EC2 instances 2 app server 1 ELB + 1 RDS instance,  memchaced is installed on both app servers and shared between the two. Performance is great.  Managing, and deploying is not, very very little just works.  Any type of background jobs, cron scripts, imagemagick, gs, or anything beyond extremely basic will require custom chef scripts.

The service is also built around “Stacks” very similarly to cloud 66, you add various layers for your application, i.e. Rails, DB, Memcached. and opsworks will provision on new or existing servers.  Building servers tends to be a slow process about 20-25 minutes from the outgoing request, so don’t expect to scale so fast. Though it does provide methods to autoscale or scale based upon time which is very nice.

Opsworks, is a big boys tool, you need to know what you are doing but it can be a good blend between a fully managed PAAS and rolling your own.   My overall experience has been good, but painful at times, we are not a chef shop and have struggled with weird deployment issues.  Most of our grips are beyond the opsworks platform itself, like ELB returning a white page with no error in a 503 event, or deploys failing and bringing down the service.

Conclusion

Cloud 66 is a fantastic service that uses my favorite support tool, and clearly is here to make developers lives easier, providing PAAS on many different cloud platforms you get performance you need and the service that keeps you coming back.   Opsworks, is hosted chef, and that’s the end of the story, it will do very little for you if you don’t understand devops,  there is no “15 minute” getting started guide on this one, once it works it’s a solid tool, but you will save very little time in the devops arena.

 

My journey into testing (An RSpec-2 Factory Girl and Guard Tale)

Testing has always been to me this thing of, “if i had more time”, or “if the project had money to cover testing.”, but I have begun to realize that testing can be development as it not only helps guide good programming it makes it much simpler to keep your code in tip top shape.

As this is part 1, I wanted to talk about setting up testing environments. This is something that I feel like isn’t talked much about on the web, yet it is something almost all people expect when working on open source projects, “Could you add some tests to your code?”.

My environment.

gem 'rails', '3.1.3' ... gem "rspec-rails", ">= 2.0.1", :group => [:development, :test] gem 'guard-spork', :group => [:development, :test] gem "factory_girl_rails", :group => [:development, :test] group :development do gem 'spork', '~> 0.9.0.rc9' #Greatly Speeds up Automated Testing gem 'guard' #the magic of automated testing gem 'guard-bundler' gem 'guard-rspec' gem 'growl' gem "progress_bar" gem 'ruby-debug19' end

rspec-rails

rspec is an alternative testing framework, read more about it here

RSpec is a Behaviour-Driven Development tool for Ruby programmers. BDD is an approach to software development that combines Test-Driven Development, Domain Driven Design, and Acceptance Test-Driven Planning. RSpec helps you do the TDD part of that equation, focusing on the documentation and design aspects of TDD.

I am still learning the fundamentals of RSpec so I will follow up on this

Guard

Guard has worked out to be my controller of my testing environment. It’s primary role is to simply watch for changes and perform action when a change in my code is detected, typically through a filesystem event such as saving a file. It has an impressive list of “guards” that can be found on it’s wiki, and I will talk about a few I am using but you really should check this out. Coupled with growl it is an amazing tool.

Spork and Guard-spork

Spork is a time saver, Plain and simple. It launches your rails environment in a separate process that it can fork as you go through your testing. Basically it prevents you from loading the entire environment on ever test run, as our goal here is an auto test environment were tests will be run constantly the quicker the feedback on the code the better.

Guard-Bundler

Automatically runs bundle install when a change in your gemfile is detected (Awesome)

Growl

This is the icing on the cake of Guard growl notifications of all the guard output to keep your focus on the code. Without removing focus you get your testing status.