24.6.05
Service Architectures
A report from a colleague in industry (who prefers to remain anonymous) comparing Erlang with traditional web architectures. A detailed assessment that should be useful input to the design of Links. Many thanks to my nameless friend!
Subscribe to:
Post Comments (Atom)
8 comments:
Hmm... seems that existing approaches suffer from complimentary problems:
The traditional approach uses a mix of wildly different technologies (HTML for presentation, "traditional" programming for business logic, database for storage); this implies massive debugging problems and a broad range of required skills.
Erlang/OTP's lineage from telco programming means it doesn't address security issues, which creates massive problems with safeguarding a system.
Erlang can unify the database and application layers, so in this respect it's already better than the traditional approach.
Just a first impression...
As for the references to security, both in the above comment as well as in the paper, the comments are in my mind no issues.
A Web application needs to be open on the public side on port 80 and that's it. It's just a matter of configuring the firewall correctly, be it an upstream real fw or iptables rules on the target webserver machine itself.
If yaws is used, I have a real hard time to see how port 80 access into the webserver could be a security issue. It's far more easy to make a secure webapp in erlang/yaws than it is with other more mainstream technologies.
/klacke
The security issue is very real - and it has little to do with yaws.
Once I have a cluster of machines set up, I have set up host-based trusts between them using ssh.
If, for whatever reason, a bad guy gets access to one machine, they have access to them all.
The security flaw could be anything, a service that shouldn't have been running, a firewall port left open by mistake, whatever, but the reality of the situation is that there is an automatic privilege escalation.
In an enterprise system installed under bastion security I would expect to require 2, or preferably 3 separate security breaches before getting access to data. To do that with an Erlang cluster requires building a whole, functionality-free wrapper as a buffer between the customer and the cluster.
This also potentially obviates the benefits afforded by using Eddie to manage load-balancing and internet dial-tone.
/the anonymous author
> In an enterprise system installed
> under bastion security I would
> expect to require 2, or preferably 3
> separate security breaches
You're dreaming.
- An "Enterprise" developer.
pdf please.
If someone distills the doc to pdf and sends it to me, I'll post it.
Here it is in
pdf. Thanks to Rob Crowther for distilling it.
I moved the pdf, it is now here.
Post a Comment