Note: the following article is in the context of the Ruby community and makes many Ruby-specific references, but the principles discussed are generally language-agnostic.

Intro

By now the benefits provided by macro-architecture in the context of web applications and web services via frameworks like Rails are well-understood and do not need to be re-explained. Changes in Rails and the introduction of ActiveResource have also contributed to the current acceptance of REST’ful principles as being beneficial in web apps.

However, one area that has been gaining more support in the community but has not been directly examined is that of micro-architectures. For the sake of this article I am defining a micro-architecture as a REST’ful web applications or service that is composed of several self-contained services communicated with over HTTP. Herein the general benefits of micro-architectures, as well as when and how to effectively move to them, well be discussed.

Test-driving the public interface

As with most software, begin TDD-style with tests first. I recommend outside-in style development, with heavy emphasis on the “outside” and little on the “in”. In other words, favor integration tests over unit tests. For example, in typical software development your goal might be the algorithmic transformation of some data set. In this case you would start out with some example base cases of how your library works, and implement them in the red-green-refactor cycle. If the implementation starts becoming too complicated then introduce some unit tests to help you manage complexity. However, remember that the purpose of the api is just to get the integration tests to pass, and any extra unit tests just make refactoring more difficult. Thus, unit tests (and even more extremely, mocking) are only a result of necessity due to complexity or test-suite run time savings.

The analogy in the web app/service world to our algorithmic transform library then would be to use integration tests at the highest level possible, namely through the http api. For a web application (something consumed by a human in a browser) use webrat so that you can exercise the same navigation and data-submission structure that users do in the browser in html. For testing web services (consumed programmatically as apis, mostly simple xml or json serialization formats), I recommend testing with rack-test.

One common and valid argument against micro-architectures is that they are a bit complicated to setup automated tests for, although I think this is beginning to change. Either way both webrat and rack-test can be used to test rack-based applications in-memory. It is advised to start this way to avoid setup pains.

Once you have your tests passing you can easily convert them to shoot real http requests at servers rather than in-memory rack-object interface testing. You have many options here for webrat, including mechanize if you want to go headless and selenium if you want to spawn up a real browser. I recommend going headless, at least during development so you don’t slow down your feedback loop. If you are using rack-test then something to look out for is rack-client. Although the library isn’t mature yet, it offers a single line of code change to go from in-memory rack-test to http-based rack-test. Since webrat has a rack-test adapter, it could also be used with rack-client instead of mechanize. First get your in-memory tests passing, then write up some rackup .ru files to manually spawn servers with, and then convert the tests to http with the methods described above. After that is done, you can automate the spawning servers with your testing framework’s equivalent of RSpec before(:all) and after(:all).

Development guidelines

I will assume that we are building some single web app or service to be hosted at some top-level domain (e.g. facebook, google, etc). As such, the customer will be facing an api that from the outside looks like a macro-architecture, where many things are possible in a somewhat complicated service. The opposite would be many Amazon AWS-style mini services like S3, SimpleDB, EC2, etc, but these kind of public micro-services are not too common.

So, once again we start building our public macro-service. Because such services have growth and complexity in mind, it’s a good idea to use a larger framework like Rails or Merb with enough conventions and organization to handle that complexity. It is easier to develop an entire macro-service with a macro-architecture, putting all of your controllers, models, views, etc in the same codebase to makeup your resources. In contrast separating code out into isolated internal micro-services takes some work, in the same way that organizing a pile of legos into piles of common color is harder than throwing everything into a single pile.

Additionally, while setting up http-level integration testing by forking a process in before(:all) and killing it in after(:all) is manageable, doing the same with several internal services consumed by one main one is a bit more complicated to setup. Nonetheless, it is still advisable to manually do this until some nice library pops up that can handle expressing these connections and spawning/tearing down servers from them elegantly.

You should design your macro-architecture in a way that makes separating out micro-services easy. In other words, think about how whatever part of your app that you are building could be backed by some service that stands on its own (e.g. a blog post comments controller could be backed by a generic annotation service that accepts a uri to some resource, as well as annotation text and author information). Get your tests passing this way against your integration-level macro-service api. Note that you don’t have to test the micro-service api, that is the fun part of refactoring (but if necessary due to complexity, be sure to add tests… use the same discretion between integration, unit, and mock tests as used in the simple algorithmic transform example above).

The reason why you should think about the internal-service that could comprise your macro-service is to avoid sharing code between this part and the rest of the application. If you haven’t noticed already this article is really about taking classic established software principles and applying to the world of web apps. In this case we want high cohesion and loose coupling between code in various parts of our public macro-service api. This is a good practice in general, and as long as you maintain it in a slightly stricter fashion than normal then it will make extracting a micro-service possible. Also when I avoid code sharing, that doesn’t prevent you from extracting common utility code into shared gems, just stay away from sharing business logic code that will eventually make refactoring a service out unbearable.

Being pragmatic

Note that I am not saying that you should always follow this practice of avoiding code reuse and thinking about how to make public-api resources independent for each part of your application. Software development is a constant rearrangement of where complexity resides, whether it be in a specific, isolated, and visible portion of code, or whether it lies in the complex relationships between too many abstractions. Therefore, as always use discretion as to what makes sense to keep in the internal macro-architecture of the public macro-service, and what should be split off into internal micro-services. What I am saying is that you should be aware of when you reuse code across resources and consciously make the decision to do so. Just try to think about whether or not a resource could easily explode in complexity (making the encapsulation of the complex service worth it), or whether it could easily become a performance bottleneck (making isolated performance monitoring worth it). Those two reasons, separating out complexity via encapsulation, and performance monitoring, are the big motivators for creating a micro-architecture.

In any case, if you’ve identified a resource that is a good candidate for becoming a micro-service, and has already been tested implicitly via the public macro-service api, then there is a convenient middle ground to take. Rack and its notion of middleware, in addition to bigger frameworks supporting it with things like Rails Metal, make this middle ground possible. I generally like using a class that inherits from Sinatra::Base as a micro-service, as the api does not contrain your resource design like bigger frameworks with more conventions do, and keeping the amount of files and directories to a minimum is possible. Sinatra provides just enough sugar to make building a Rack-middleware a pleasant experience (although the Rails 3.0 internals are shaping up to be flexible enough to be used in a very similar way, so watch for that as well). By creating your resource as a middleware service you more explicitly mark it as code to be isolated from the rest of the internal macro-architecture, but because of Rack you get the benefit of being able to test the entire public macro-service in one process. Doing this during the development phase of your application prevents you from being barred down by setting up the integration-testing infrastructure for running several rack-apps pulled out of the middleware stack but still consumed by the main application. In fact, if the separation is just for organization encapsulation purposes then feel free to deploy your monolithic app with the micro-services as middleware. However, if you have micro-services that were separated due to performance concerns that need to be monitored then be sure to pull them out and integration test them before your public deployment.

Common criticisms

The most common criticism that I have not addressed when it comes to using all these micro services is complexity introduced by latency issues when dealing with many http apis. To deal with this transparently and most elegantly, I recommend Ruby 1.9 + Neverblock. Other options include manual event handling with em-http-request, or explicit thread-based latency hiding with something like “need_later” futures in Dataflow.

Another common criticism is the complexity increased in an application because of all the new moving parts, which is indeed a problem and should be weighed against the two major motivations. Notably though, with the clear boundaries introduced via the separate applications, you can catch exceptions if one micro-service is not responding and handle error messages on the specific page that uses it. Compare this to a monolithic architecture, where partial system availability is much more difficult to design.

Final remarks

Please note that for simplicity I have been implying a ratio of one public api resource to one internal micro-service, but in reality a single micro service could be used in part by many public api resources, and a single public api resource could make use of several internal micro-services.

This concludes my summary of how to effectively manage and take advantage of an internal micro-service architecture. Micro-services are still in their young and “hip” stages compared to their macro counterparts, so expect best practices regarding them to evolve as we collectively gain experience. I think the general advice in this post is sane though, so hopefully it can serve as a reference to people not yet familiar with the topic. As always, comments/criticism welcome.

Benefits

For brevity I tried to not cover specific benefits of micro-architecture within the two major categories of encapsulation and performance monitoring isolation. Here is a list that I will update if anyone has more suggestions in the comments.

• library/gem dependency isolation
• choosing appropriately different servers for services (e.g. passenger vs thin)
• partial-site functioning when isolated services are down and error handling is in place
• full http reverse-proxy caching via ESI pulling in bits from disparate services

Cry is a Ruby library that provides a nice object oriented way to create, transfer, and manipulate frozen parse trees. The idea behind the name is that you end up writing in parse tree format, in a syntax more verbose than CLOS… hence “Cry” =) In reality Cry would mainly be used in meta-programming though, and is designed to have a simple & consistent api.

Let’s say we have an instance of an “Account” class stored in the local variable “acnt”. It has a “withdraw” method that takes an “amount” parameter.

In Ruby you would normally call this method like so:

acnt.withdraw(50)

In Common Lisp’s CLOS you would do it like this:

(withdraw acnt 50)

Notice that because CLOS deals with objects, the second parameter is the instance of the class that the method will be called on. Cry copies this parameter order in its parse trees:

Cry::ParseTree.new(:withdraw, acnt, 50).evaluate

In Ruby classes are just instances of the “Class” class. Thus, the syntax for class methods remains the same:

Cry::ParseTree.new(:sqrt, Math, 16).evaluate # => 4.0

Another neat thing is that the parse tree instances are not evaluated until you call the evaluate method. This lets you pass them around, similar in concept to Procs (aka lambdas.)

parse_tree = Cry::ParseTree.new(:+, Cry::ParseTree.new(:*, 2, 3), Cry::ParseTree.new(:/, 16, 2)) # => (:+, (:*, 2, 3), (:/, 16, 2))
parse_tree.evaluate # => 14

Notice that the object and any of the parameters can each be parse trees as well (and even those can continue recursively nesting parse trees with their respective objects and parameters.)

There are also convenient getter methods for our parse tree components:

parse_tree.node_method # => :+
parse_tree.node_object # => (:*, 2, 3)
parse_tree.node_arguments # => [(:/, 16, 2)]

Similarly, there are setters that could be used like this:

parse_tree.node_object = parse_tree.node_object.evaluate # => 6
parse_tree.node_arguments = parse_tree.node_arguments.map{|p| p.evaluate } # => 8
parse_tree.evaluate # => 14

The previous example takes components of our parse tree and evaluates them separately, then sets the results back. This opens up possibilities for having a very deeply nested parse tree, and evaluating certain sections in parallel.

In traditional Ruby the above can be explicitly written like so:

2.*(3).+(16./(2)) # => 16

The big difference is that this would be evaluated immediately, whereas you can delay and manipulate the whole structure by using a parse tree.

We previously used setter methods to manually evaluate the parse trees for the object and arguments. However, we could also change something, such as the object:

parse_tree.node_object = 5
parse_tree.evaluate # => 40

Or, we could change every part of the parse tree:

parse_tree.node_method = :new
parse_tree.node_object = Array
parse_tree.node_arguments = [5, 9]
parse_tree.evaluate # => [9, 9, 9, 9, 9]

Certain methods are defined with blocks, for these simply pass in a Proc as the last argument:

# Traditional Ruby
[1, 2, 3].inject(2) {|sum, i| sum + i } # => 8

# Cry::ParseTree Ruby
parse_tree = Cry::ParseTree.new(:inject, [1, 2, 3], 2, lambda{|sum, i| sum + i })
parse_tree.evaluate # => 8

Cry::ParseTree extends from Array, and internally stores the method, object, and arguments in that order respectively. Knowing this, we could have done the following to switch out the block to be used for our parse tree:

old_block = parse_tree.pop
parse_tree.push lambda{|product, i| product * i }
parse_tree.evaluate # => 12

We have access to all methods Array does, so this would work too:

parse_tree.each {|p| puts p.inspect }
:inject
[1, 2, 3]
2
#<Proc:0x0005526c@(irb):67>
=> (:inject, [1, 2, 3], 2, #<Proc:0x0005526c@(irb):67>)

That about wraps things up. If you would like to follow development, or fork/contribute to the project, you can find Cry on github. Even if you just wonder if something will work, feel free to try out your Ruby parse tree masterpieces by adding funky ones as tests.

In case anyone is interested, I made this so I could have an easy datastructure to manipulate when dealing with Genetic Programming algorithms. I’m working on an interesting project that involves them, and will be sure to put it on github and make a post when it’s ready.

I was reading TopFunky’s great post on various queue’s that you can use with Ruby, and came across Rick Olson’s particularly amazing BBQ Queue service.

Being immediately inspired, I wrote a complementary version, the InlineBBQ Queue service.

Expect an MIT license on this sucker soon once it goes through at least 2 more production applications.

As mentioned in the comments, I’m in the middle of implementing the service for Rubinius, JRuby, and IronRuby too…. “rbx” and “jruby” are just proving much harder to type than “ruby”.

Note: This is a joke =p

I really like the concept of the Uniform Interface. One of my favorite things to do is spend hours on my whiteboard (and sometimes days) fiddling with ideas that express what I consider to be elegance. This ranges from macroscopic elegance (ie: the architecture level) to microscopic elegance (ie: the function/method level). Somewhere in the middle lies my fascination with sets, my favorite topic in Discrete Mathematics.

I think one of the reasons I like the Uniform Interface so much is that it groups things together into a set (all things that respond to the same method or methods), which lets you conjure up powerful abstractions at any point in the macroscopic to microscopic elegance scale.

One reason I like REST is because of its HTTP implementation’s Uniform Interface, the most common request methods being CREATE, UPDATE, PUT, DELETE, and HEAD. Programs using MapReduce also use a Common Interface for both the map and reduce functions… and there are many, many more examples.

The difference between the Uniform Interface and Interface Polymorphism is subtle. The Uniform Interface is more general (ie: applying to REST, which is a service), whereas Interface Polymorphism specifically applies to programming. Thus, Interface Polymorphism is a specific kind of Uniform Interface.

The term “Duck Typing” is mentioned in Ruby circles sometimes, and it’s mostly just another name for Interface Polymorphism. This is probably because Ruby has no such thing as an interface. Java on the other hand does, which is how I learned about the concept first. In Java, if a class implements an interface then it absolutely has to define the interfaces methods in its class definition. In Ruby, duck typed methods simply have to be defined by the time an object is called (even if they weren’t there during the objects initial class declaration, or even during the objects initialization). Notice I used the word “object”, but don’t forget that in Ruby a class represented through a constant is an object too. So, the only difference is that Duck Typing is more often used when talking about dynamically adding Interface Polymorphic methods.

Let’s sum it all up with a Ruby class definition and some inheritance.

class DuckTyping < InterfacePolymorphism < UniformInterface
end


As some of you know, when I’m not working I’m taking classes in Information Systems at UCF. One of the classes I took this semester was Web Systems II, which is essentially a server-side course that focuses on ASP.NET development.

One particular assignment was creating a “Category Code Manager”, which I had never heard of previously. I think the professor made the term up, but the concept is simple nonetheless. There are categories (ie: fruits) that each can have many codes (ie: apples, oranges). I think the purpose of the assignment was to get used to working with foreign keys, and building dynamic drop downs as a tool to display this sort of relationship. Another gotcha is that the categories can have parent categories.

The class had a participation grade that I must have overlooked… Needless to say that didn’t bode well for me, so I created this screencast as an introduction to Ruby on Rails (beginner level) using the new Rails 2.0 (final source code included.) I tried to follow best practices where possible (ie: TDD), and covered the topics of:

• Database agnosticism & environments
• Using rake to create databases, and to run
• Scaffold generator
• has_many & belongs_to relationships within ActiveRecord
• The interactive Rails console
• The new integration of the ruby debugger, and a drop of live metaprogramming
• Test Driven Development with Test::Unit
• Intro to REST’ful architecture within Rails

But, I left some things out to avoid making the screencast even longer, and avoid it being confusing for beginners. Just so you all know, some changes I would have made include:

• Create some helper methods for things like populating the select tags
• Use nested routing (I did this first, but renaming all the named routes, having to explain the routing, etc made this too complex for a beginner video)
• Use RSpec for testing (RSpec’s scaffold uses mocks and stubs, which are just a little too much to explain when already introducing all of Rails and testing)
• Use a REST’ful abstraction plugin (we developed an internal one at work, but unfortunately we haven’t been able to open source it yet… until then check out make_resourceful)
• Use the ObjectMother pattern for creating objects during tests

Enjoy the screencast!

I’ve recently been doing some very fun, elegant, and exciting things with Ruby at work and in my personal time. Although I have to admit that I learned Ruby because of the amount of hype Rails got on Digg back in the day, I am proud and overjoyed to consider myself a Ruby developer now.

Even though these bits of knowledge are obvious to advanced Ruby developers, I think there is value in recognizing these in context and expanding upon them. Below is my version of a summary of a presentation, courtesy Glenn Vanderburg.

• Punctuation gets in the way for short lines, but makes long lines more readable (this applies to the use of single versus multi-line blocks too.)
• The minimal syntax to open and close blocks makes their use feel natural. This naturalness is powerful, because blocks seem to allow powerful abstractions to be developed without much thought.
• Sigils are used for scope (@@, @, CAPS, $, etc) rather than typing (like in Perl.) This use of sigils helps, because the most common scopes (classes and local variables) do not have them. However, they provide an effective language feature that eliminates an annoying standard like using an underscore before instance variables (Java.)
• There are usually two (or possibly more) ways of doing something, allowing for the coded implementation to fit the context.
• Mixins/modules cannot create instance variables (because they cannot be instantiated), but they can reference them (because the instance variables spring into life inside of the object the module is mixed into.)
• The Enumerable module, along with blocks, allows Ruby to apply some functional programming techniques.
• Operator overloading.
• “Three-quals” (===) allows for beautiful case statements by defining the concept of a match.
• “Open classes” allow for nice common interfaces and DSL’s to be defined when patterns are discovered (ie: Rails’ blank? method on NilClass and String.)
• Classes being defined can execute code on themselves to define themselves further because they are objects.
• Although classes are just object instances, creating them still uses a declaration (unlike Smalltalk) and feels natural.

As a closing note, Ruby makes trade-offs in its design like any other language. These range from dynamic typing (which makes tool creation harder), to the “Principle of Least Surprise” (which make consistency harder), to many other things.

Glenn points out, and I agree, that Ruby seems to strike all the right balances (big ups to Matz.) However, this is a personal preference and we should respect the languages choices of others as a matter of taste… there’s room for everyone =)

Ruby has a nifty feature to be able to use a special constant that represents infinity, accessible as follows:

irb(main):001:0> 1.0/0
=> Infinity

Recently, I needed to validate that a field in my Rails model would be positive. While there are countless ways to do this, I was very happy to find a fun and practical use for infinity.

validates_inclusion_of :some_attribute, :within => 1..1.0/0, :allow_nil => true, :message => 'should be positive'

The attribute is validated to be within positive one (inclusive) and positive infinity (technically exclusive.) This is done with Rails’ validates_inclusion_of for numeric data, Ruby’s range operator .., and the infinity constant 1.0/0.

Huzzah!

I am in love with how dynamic Ruby is… Whenever I talk about that aspect of Ruby I always bring up this example, which I heard about from someone that read it on the Ruby-talk mailing list. Nevertheless, doing it always amuses me.

So here we go. What I am going to do is make a Ruby class with an instance method and instance variable. The method first assigns the current time to an instance variable. Simple enough…but then I reopen the method and define it to just return that instance variable. What this ends up being is a simple form of caching:

class Cacher
def cache
@time=Time.now
def cache
‘Succesfully cached at: ‘ + @time.to_s
end
end
end

So now I can do this:

larry-diehls-computer:~ larrytheliquid$ irb
irb(main):001:0> require ‘cacher’
=> true
irb(main):002:0> c=Cacher.new
=> #
irb(main):003:0> c.cache
=> nil
irb(main):004:0> c.cache
=> “Succesfully cached at: Mon Oct 30 23:31:26 EST 2006″
irb(main):005:0> c.cache
=> “Succesfully cached at: Mon Oct 30 23:31:26 EST 2006″
irb(main):006:0> c.cache
=> “Succesfully cached at: Mon Oct 30 23:31:26 EST 2006″
irb(main):007:0> c.cache
=> “Succesfully cached at: Mon Oct 30 23:31:26 EST 2006″
irb(main):008:0>

As you can see, the @cache@ method gets redefined and always outputs the same thing. This works great for any method that takes a long time to execute but needs to be called multiple times. Say, maybe a Google Map API call, an intensive SQL statement, etc…

I love how simple this example is and plan to post plenty other such examples that illustrate the elegance of Ruby in the future, so stay tuned. Have something short and similar? You are most welcome to post it, or a link to your blog post about it, etc in the comments!

I came across “an interesting message”:http://www.ruby-forum.com/topic/83839 on the ruby talk mailing list a month ago. “Second Life”:http://secondlife.com/ is a 3d, online virtual world with no specific purpose. I heard about it from a good friend that was planning a business within it, selling virtual goods and services (the game lets you exchange real money for “Linden dollars”.) Although the concept appealed to me, I was never interested in it enough to install it and give it a try.

I had also heard of the “recent hiring”:http://headius.blogspot.com/2006/09/jruby-steps-into-sun.html of JRuby developers (Charles Nutter and Thomas Enebo) by Sun. I knew that “JRuby”:http://jruby.org/ was some sort of Ruby integration with Java (like Jython), and was happy as a Rails developer that Sun was giving Ruby some love. But again, I was satisfied with Rails enough to not dig deeper into it.

I love web development and try to stay in touch with local scenes such as the “Orlando Ruby Users Group”:http://www.orug.org/ , “Refresh Orlando”:http://www.refreshorlando.org/ , the upcoming “Refresh06 conference”:http://refresh06.com/ , and have attended “BarCamp Jacksonville”:http://barcamp.org/BarCampJacksonville and “Refresh Jacksonville”:http://www.refreshjacksonville.org/ in the past. Needless to say, being able to meet up with a virtual locality of “Rubyists of Second Life”:http://rosl.iandb.net/ AND learn about JRuby seemed like an amazing opportunity to indulge in the kind of fun that makes the internet so great.

“[click here to see all the screenshots I took]”:http://flickr.com/photos/larrytheliquid/sets/72157594350925388/ !

@On my trips to the meeting before it started, in my Eastern time zone, I had fun playing with interactive billboards that had pages like the RoR website, some Ruby sites, etc. The coolest thing was this little red cube on the middle of the giant ruby…it was a module that let you use IRB in Second Life! That’s right, IRB right there in the game…so cool.@

Then came the presentation, a format I found to be very entertaining. Headius started off the projector with some introductory slides, to the sweet tunes of Daft Punk that someone in the audience was streaming. You could see his avatar move his eyes and body to change slides, look around at people, and gestures were performed during chat to make the whole thing eerily lifelike. As you can see in the “presentation and chat log”:http://rosl.iandb.net/presentations/jruby/JRuby%20Presentation%2018%20Oct%2006.html , discussion during and between slides ensued…the air was electric and the format for this kind of meeting definitely works.

!

!

So to sum this all up, Second Life is a fun and exciting presentation medium. I encourage anyone interested enough in Ruby to read this article, to join the Rubyists of Second Life group (refer to “install and setup instructions here”:http://www.ruby-forum.com/topic/83839 .) JRuby has great and friendly developers that have that oh-so-good open source concern for community needs, and now has the backing of Sun. Anything that gives the dark side of Rails (deployment) another alternative is fantastic in my book, and access to probably the best libraries ever (Java’s) is also very sweet. Plus…possible better performance…sign me up! I’ll definitely be playing with JRuby, and am glad to have found out more about something I initially neglected. And finally, in case anyone cared, my in-game name is “Liquid Lunardi”.