Howdy Eric,<br><br><div class="gmail_quote">On Mon, Aug 2, 2010 at 6:57 PM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Jorge,<br>
<br>
I think we may not be on the same page here.</blockquote><div><br></div><div>But I think we're getting close :) All three of us have slightly different approaches in mind, but we're narrowing down the areas where we disagree. I've tried listing our agreements and disagreements below -- we'll see if this style is helpful or confusing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I can't speak for what<br>
Michael meant, but this is what I had in mind:<br>
<br>
<a href="http://oddments.org/tmp/os_module_arch.png" target="_blank">http://oddments.org/tmp/os_module_arch.png</a><br>
<br>
This removes the intermediate proxies and instead relies on the<br>
scaling out of API endpoint and the services it uses. Different<br>
services or different parts of the same service could consume the<br>
same API/service. See my original email for my reasoning, but the<br>
main ones are to keep the APIs consistent across different parts of<br>
a service and to reduce the number of hops a request must go through.<br></blockquote><div><br></div><div><div><br class="Apple-interchange-newline">OK, I think we all agree that it is good that</div><div><ul><li>code in the request chain can call out sideways to services</li>
<li>we provide language bindings to those services</li><li>the language bindings talk to services using their normal wire protocol, or REST if we write the service ourselves</li><li>the language bindings allow dropping in different implementations of the service, including local mocks for testing</li>
<li>it's undesirable to have a lower layer in the request chain have to call up to a higher layer to service a request.</li></ul></div><div>Here's where I think we disagree (pardon if I put words in your mouths incorrectly):</div>
<div><ol><li>Jorge suggests putting some specific things in the request chain (e.g. caching) which you and I would suggest making into services.</li><li>Jorge and I would suggest making the request chain longer when possible to simplify each part, while you would suggest collapsing it to reduce the number of hops.</li>
</ol><div>Let me suggest that #1 isn't really something we need to settle right now: whether auth, or caching, or rate limiting, or SSL termination is implemented as a layer in the request chain or as a sideways-called service can be individually argued when we get to that piece. I think we're looking to settle the higher-level shape of the architecture. #2 is below:</div>
</div></div><div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
If we find we do need an extra proxy layer because caching or SSL<br>termination becomes too expensive within the endpoints, we can<br>easily write a new service layer utilizing the same APIs to provide<br>this. It would be nice to keep these proxies optional though, as some<br>
installations will not require them.</blockquote><div><br></div><div>What makes me uncomfortable about <a href="http://oddments.org/tmp/os_module_arch.png">http://oddments.org/tmp/os_module_arch.png</a> is that the "API Endpoint" server is a single rectangle that does multiple things, when we could instead have it be a chain of 2 or 3 rectangles that each do a simpler thing. For example, if there does exist some basic auth* that can be done on the incoming HTTP request, I would want that teased out of the API Endpoint and put in front of it as a layer that calls sideways to the Auth Service. Now API Endpoint is a little simpler, and we know that any requests to it have already passed basic auth* checks. API Endpoint can of course call out to Auth Service again to do more fine grained auth if necessary. As another example, I haven't looked at the code for "Compute Worker" yet so I really have no idea what it does -- but if it were a stack of named layers I would be able to grok a piece at a time.</div>
<div><br></div><div>You want to avoid extra hops and extra layers for simpler installations to have to think about... maybe WSGI is the solution to this that lets us all meet in the middle. Build API Endpoint as a stack of as many WSGI servers as possible, so that each one is as simple as possible. If it turns out we never need to scale an individual piece, we have at least broken a larger problem into smaller ones. If we do need to scale an individual piece, we can turn the WSGI app into its own layer and scale independently. What do you (Jorge and Eric) think?</div>
<div><br></div><div>Summarized as bullet points, can we agree that</div><div><ul><li>large problems should be broken into small problems</li><li>if a layer of the request chain can have a piece broken into a WSGI app, let's do that unless there's a good reason not to</li>
<li>by the time we release 1.0, we should figure out which WSGI apps, if any, need to become independent proxies for scaling reasons</li></ul><div>? If not, please push back :)</div></div><div><br></div><div>Hope this helped and didn't muddy the waters,</div>
<div>Michael</div></div>