← Back to team overview

launchpad-dev team mailing list archive

Re: A draft microservice for gpg verification

 

On Wed, Jul 6, 2011 at 4:33 AM, Stuart Bishop
<stuart.bishop@xxxxxxxxxxxxx> wrote:
> I've refactored this into parts and added the client side code I think
> we need. I've also added ZeroMQ as an alternative transport.

Cool!. I'd like to tie
https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements in
here: the server and the client should be in separate trees so that
the LP isn't *able* to bypass stuff and import the server. e.g.
gpgverify_client.

> Branch is at lp:~stub/+junk/gpgverify
>
> Random thoughts:
>
> ZeroMQ seems to do what it says on the tin.
>
> Unlike HTTP, we need to define our own protocol. This gives us more
> flexability, but also more to think about.
>
> HA story is the same (by putting servers behind HAProxy), or better
> (we could plug in our own broker which whatever features we can dream
> up, such as persistent queues or services registering themselves
> instead of hard coded addresses and ports).

I think once you have a broker 0mq starts to look a lot more like
haproxy+http; its real strengths lie in point to point arrangements.
Of course, as I'm still a total noob, this is probably wrong :)

> ZeroMQ doesn't need Apache. With ZeroMQ, we can write and test our own
> HA and failover stories. This is very difficult when HA and failover
> requires HAProxy. But HAProxy probably provides a good enough story
> for us, is already production ready and has a decent admin interface.
>
> ZeroMQ services need ipfilter configuration to open the port. HTTP
> services need HAProxy & Apache love, and possibly the ipfilter config
> too if Apache is not local.
>
> If we are putting together complex services, I think ZeroMQ would be a
> win. But at least at this stage, I think we want simple services and
> the HTTP services are less of a surprise. I personally am leaning
> towards whatever is easiest to deploy and maintain, as from the dev
> side there seems little real difference. If we abstract out the
> transport in a similar way to my example code, there will be no
> difference. ZeroMQ would have a superior deployment story if we put
> the effort into a common broker and had services register themselves
> as they come up and down, but not by much since there isn't much work
> adding the new service to the HAProxy configuration.

I'm very glad we're getting some experience with different protocols;
let the party continue :).

-Rob


Follow ups

References