As part of the new raft of services in development here at Esendex Towers, Adam‘s been busy with his inventing hat on again. Fresh from the lab is SLAP: Service Location and Announcement Protocol. This post is inspired by just how useful basing your inter-service communications on SLAP can be when it comes to development, testing and future resilience.
SLAP is a helping hand to provide and consume network-based services.
- For a service provider, SLAP will help it broadcast its location and status.
- For a service consumer, SLAP will help it find a working instance of the service it needs to use.
Adam’s been introducing SLAP and the two basic UDP messages that make SLAP work: LOCATE and ANNOUNCE. We’ve included these two simple messages in a SLAP Node and built on top of this. The following descriptions illustrates how SLAP can be very useful when integrated into your services. These examples are based on how we’re using SLAP, and not fully reproducible from the basic SLAP examples on Adam’s blog. I’m sure there’ll be more sample code to come.
LOCATE is analogous to a shout across the valley saying “OK, I need to find this kind of service, is there anybody out there?”. The ANNOUNCE is a response back to a LOCATE request saying “Yes, I’m that kind of service and my current status is Green”, for example. Also the service will ANNOUNCE itself regularly to broadcast its current status: “I’m still here and I’m still Green”. (colours are explained later)
The service records all the ANNOUNCEs that it wants to consume in a SLAP State Table. This records all the ‘colours’ of the services to help you pick the best one when you want to send something on. We use colours to indicate the broad status of a service:
- Green – Service is fully operational and available
- Amber/Orange – Service is operational but under load
- Red – Service is not operational
- Blue – Service state is not known
This information can be used by a SLAP Load Balancer to determine the best service to send to. It’ll pick a service in order of Green first, then Amber/Orange. Services that are exiting gracefully will ANNOUNCE a Red status on exit. Services that decide to go for a walk on their own will be marked Blue after a set timeout.
Whilst there’s plenty to talk about SLAP, the great thing that I’ve been finding from a development point of view is how easy it is to start instances of services to help testing.
Imagine a case where you’ve got a set of working services but you wanted to test an improvement you’ve just made. If you want to step into the code as its run, then deploying it as a Windows Service on the testing server would take time and wouldn’t allow you access into the code without the usual peppering of debug logging statements which aren’t as easy to read through than stepping through live code.
The solution with SLAP is to stop the running instance(s) of the Service you’re working on and start your own version on your development machine. SLAP sends out its ANNOUNCE message from your new version of the service and the other services pick up on this new instance. Bingo! You’re in business with real traffic to test your service with without having to do any deploying or reconfiguration of the other services (which might have involved bringing them down anyway).
So there we go, a very brief introduction to SLAP, but in the brief time we’ve been implementing it here it’s already proved itself very handy.