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!

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

<< Home

This page is powered by Blogger. Isn't yours?