Looking for opinions on the modularization of web applications. Already most applications regardless of language have a backend DB and support tie-ins with their respective web application server (Apache, IIS, Lighttp, etc ) but a lot of developers I’ve dealt with have problems coming to terms with using Memcached or anything outside of the web app’s immediate process space.
Is modularization of a web application as good thing a thing as I believe or is there something I’m missing that causes everyone from Sr. Developers to CTO’s to be hesitant to move specific parts of the business logic out of the web front end and into specialized backend services?
For example, a few years ago I got shot down in a project design meeting for a very high traffic website when I suggested we rip the process intensive ACL logic out of the front end framework and turn it into a semi-clusterable service application in the backend. For me the benefits was a cleaner separation of code and the ability to reuse the ACL logic in multiple places by using REST/JSON as the bridge between say PHP & Python.
The developers who disagreed with my idea argued it was ‘too complicated’ but I just couldn’t see how? My arguments are that just as there can be tag soup for the presentation layer, there can and is often a logic soup of code that’s so meshed together that if a issue arises it might be nigh on impossible to perform a ‘surgical’ fix.
So to shorten it down, what are the con’s & or pro’s of break large applications down into independent but cooperative processes ( not threads or sub requests ). MySQL, Memcache, similar service process are great…but why not anything else? How is going down this path ‘too complicated’?
Well, sometimes ‘too complicated’ means ‘I don’t want to think outside my confort zone.’
The basic notion sounds good — you’re talking about pretty plausible service-oriented architecture here.
Now, as far as the pros and cons, the first thing against it is that you do indeed have to get people to think outside their comfort zones. A more technical con is that you need to preserve what is, in effect, the session state. Say you pick up the authentication token from your auth service; how is that token going to stay associated with the correct user session.
Another issue is that it might be harder to debug, since it’s happening more dynamically.
On the pro side, though, if you can satisfy the session-state issue, you get a highly scaleable architecture; if you need more service, you can either enlarge the server or simply add another server.