News for hackers. Stuff that matters.
Re:Microservices without the Servers by patsplat on Sunday September 06, 2015 @10:24AM (#10177727)
The current problem with this architecture is the network cannot be used as a security layer. Databases, search engines, etc need ports opened to the public rather than to selected servers.
Re:Microservices without the Servers by dikaiosune on Sunday September 06, 2015 @11:35AM (#10177909)
If you're on a private network (like your own DC), I'd argue that network-based security is a poor idea because then an attacker just needs to plug in and have pretty easy access.

If you're on the public cloud, I'd argue that this is an even bigger problem as you're then relying on VPC (or the equivalent) to always work correctly.

Why not ignore the networking and just build in robust security? Pubkey authentication where possible, random long passwords where not? Retry limits for clients, network intrusion detection, etc. To me, relying on the network to keep you secure seems a bit like a crutch.

Re:Microservices without the Servers by patsplat on Sunday September 06, 2015 @12:11PM (#10178023)
This is an optimistic counterpoint.

However realistically nearly all persistence services such as MySQL, Postgres, MongoDB, Memcache, ElasticSearch, etc either have been insufficiently hardened as a public service or flat out are not intended to be used on a public port and depend on the network for security.

There is not currently an option to connect an RDS database instance to a Lambda function without opening said database instance up to the public. It's a problem.

You are correct that SSH tunneling could be used to provide security but such usage is not yet a standard approach.

Re:Microservices without the Servers by twagner on Sunday September 06, 2015 @01:34PM (#10178324)
Totally agree. It's our most requested feature on the Lambda team and a priority to enable.