search

pandastrike / huxley

API and CLI for Docker Deployment
9 stars 1 forks source link

Add an External Facing API to the Kick Server #40

Open freeformflow opened 9 years ago

freeformflow commented 9 years ago

The kick server has a big role in the future of Huxley's development, beyond simply handling DNS setup.

Remember that kick is short for "sidekick", and this server really is there to help out with a variety of tasks. In fact, it is positioned to become the API handle for the whole cluster, which is an extension of the idea that every component of the CAM model must be self-describing.

The kick server should monitor the state of every app running on the cluster, including the health of their micro-service children. By implementing an external facing API, users can see what's going happening on the clusters they have deployed.

Imagine a command like huxley cluster describe [cluster-name]. This makes a call to the Huxley API, which finds the cluster and would then query its kick server. The Huxley API would then process that response and relay information back to the user's local machine. The Huxley API would not have to constantly monitor cluster resources. It would be off-loaded to the cluster itself, which is the power of self-describing clusters.

Additionally, state monitoring is a prerequisite of one of the kick server's most impressive roles, auto-scaling. The kick server can allocate additional EC2 instances as needed and spin up more service containers. When it detects that the additional containers are no longer needed, it can spin them down. Even better, it should be able to move services off of instances that are relatively empty so they can be terminated and save on server costs. This was another concern raised at SCaLE, and the kick server is poised to be the perfect solution.

dyoder commented 9 years ago

Alternatively, we could simply have the kick server update the cluster description as services register, instead of requiring the API ask the kick server.