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:
<< Home
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...
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...
# posted by 
: 17/7/05 11:47 AM
: 17/7/05 11:47 AM
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
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
# posted by : 4/8/05 1:30 PM
: 4/8/05 1:30 PM
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
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
# posted by : 13/8/05 11:14 PM
: 13/8/05 11:14 PM
> 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.
Post a Comment
> under bastion security I would
> expect to require 2, or preferably 3
> separate security breaches
You're dreaming.
- An "Enterprise" developer.
# posted by : 5/6/06 3:10 AM
: 5/6/06 3:10 AM 
<< Home
