In light of your further questions, I feel like I should post.

We're working on a microservice framework which:

    - does the routing to and from the actual microservices
    - provides a structured enough interface (through our small language), that it can:
      - cache the results of requests out to any service
      - allow services to find and rely upon each other to compose functionality
      - run one lightweight runtime per service per machine (which never shuts down, but has little overhead due to its lack of state)
      - serve static assets both to clients and to microservices requesting them
      - allow services written in differing languages to talk to each other

Perhaps this gives you a picture of what might fit the job description of a microservice framework? :P

... and if this sounds what HTTP servers do, you'd be partially right, but building such apps today is pretty non-trivial and hard to orchestrate.

The focus on microservices is making it much more possible to build apps like this and we're personally betting on an approach which focuses on allowing each microservice to express as much as possible in its own little corner (using our language, which we use both for app structure and communications and gives different programming languages a neutral meeting point).

We're over at http://wym.io/, where there's a demo of our language builder, for now. Hopefully this is low key enough. :P

This sounds very useful.

One further question. Say a service A calls service B. And let's say service B needs several seconds to complete, and emits a progress indicator every second (I assume this is possible?) Will A be able to read these progress indicators also every second, and send its own progress indicator to its caller?

It depends on the case, but an easy way to emit progress indicators in our system is to make the long-running service a generator. It looks like this:

    g = wym('/email') #=> Generator(id=<...>)
    g.on('value', (v) ->
        ...
    )

and /email looks like:

    function next(inp) { ... }
    return generator(next);

Sending values in uses a slightly different syntax, and manually walks the generator through. :)

A more trivial way is to pass in a callback for the service (we call them routes) to send its updates back to, but this requires more code to send values in.

Edit: to be clear, using a Generator as above isn't very microservice-ey and will trigger our framework to start tracking local state to keep the generator around, which it will auto-free when it believes it can. This is a necessary evil with any long-running code, though. Better is to break up the code so that it may be called multiple times to progress state and returning generator('/someRoute') if possible. :P

You'll struggle to find a definition of microservices that everyone will agree on. I'd say microservices are lightweight, isolated units of business logic that can communicate with other such microservices through a well defined interface. I'm sure smarter people than myself can come up with a better definition though.

Well, under your definition, just any piece of code could be a microservice...

So not very enlightening yet :)

Part of the notion is that any piece of code _can_ be a microservice. The way our framework does it, very nearly any function can trivially be turned into a microservice.

It becomes a _service_ once it gains communications and a global name, perhaps?

This is the definition most commonly used in the Scala community IME: http://klangism.tumblr.com/post/80087171446/microservices

Whether or not Colossus meets it exactly, I haven't checked.