Interesting proposal Angus. Though I think this does detract a little
from some of the benefits of providing REST interfaces for all our
components. One of the cool things about REST is how easy it is a to
consume by clients like mobile applications.
Though, like you said it maybe that companies do not want to expose
direct access to internal running services. This was something that
Lutter highlighted in one of his replies to the messaging thread. What
I really think we are lacking when making many decisions in this project
is a real understanding of the real world. In this case, i think we
could better make architectural/design decisions if we have some
information on our target audience/customers. In this for case for
example, it would be extremely helpful to know what percentage of
customers behave as you described below?
We must have a wealth of knowledge about real paying customers given
RedHats large customer base and I think we need to start using it. As a
developer with little/no on-site experience, I can only make best
guesses as to what we feel customers require. Are you aware of any form
of channel at RedHat that we can go through to get this sort of
information? If we had a target audience/customer profile, it would
make these decisions much more straight forward, and I think we'd
actually end up with a project/product that people actually want.
What are your thoughts?
Regards
Martyn
On 01/31/2013 07:23 PM, Angus Thomas wrote:
This is a problem which I've been thinking about in the context
of
Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc
so that they can see the state of running instances, receive
notifications whenever there’s an outage etc..
So long as the users are standing fairly near the server which is
running Winged Monkey, and can get wifi connectivity to the same
network that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit
more complex. In order for the users’ phone to be able to connect over
the internet to the Winged Monkey server, then either the phone is
going to need to have a VPN connection, which is a significant
overhead, or the Winged Monkey server instance is going to have to be
directly accessible over the internet. A lot of the organisations
which are potential users of Winged Monkey wouldn’t be prepared to do
that.
We could use a social network as a messaging conduit between the
Winged Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of
Twitter. I don’t *think* this use would be a violation the Twitter’s
terms of service. (
https://twitter.com/tos ). There are several
public social networks which could serve the purpose...
So, here’s how this could work:
* The Winged Monkey server would register a Twitter account, with
protected tweets.
* A user would install and run the Winged Monkey phone app. The first
run would also create a protected Twitter account, and when the user
authenticates, the two Twitter accounts start following each other.
* Thereafter Winged Monkey and the phone app use tweets to communicate
over the internet, sending instructions, status updates etc. as
strings up up to 140 characters. So long as both the server and the
client app poll frequently for new tweets, the responsiveness should
be acceptable to users.
Some of the benefits are:
* The communications are authenticated, with access permission which
can be very quickly revoked by unfollowing an account which is no
longer supported.
* The communications are also (moderately) secure, in the sense that
tweets from and between protected accounts aren’t generally readable.
* The timelines of the accounts constitute an audit history of events
etc.. It would be trivial to scrape that audit history from Twitter if
required.
* The principle benefit, though, is that the requirement for the
Winged Monkey server to be directly accessible over the internet is
removed. So long as the Winged Monkey server can make a client
connection to
Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think
there’s enough of an idea here to want feedback. I’d love to hear a
better way to solve the problem.
Angus