4 ms·

I think this is a good product offering, and it's nice to see them compete with AWS on another front, as well as Digital Oceans' offering. However, I wonder if

I think this is a good product offering, and it's nice to see them compete with AWS on another front, as well as Digital Oceans' offering. However, I wonder if these abstractions are detrimental to developers understanding the underlying technology? I'm not a supremely experienced developer but it takes very little effort to understand, for example, ufw and iptables on Linux distros. Personally, though I'm (mostly) front end, I spend the majority of my time on the command line. My main editor is vim, I write bash scripts to do what I need instead of manually performing tasks, I often just use `cat` to write files instead of opening my editor, etc. I found that managing things from the command line such as firewalls, daemons, and other tasks like managing databases, gave me deeper comprehension of what's going on. Are abstractions like this becoming crutches for tomorrows' developers?

metachris 9y ago
I think you are right with the understanding, but its a trade-off to be able to build bigger things more quickly and easily.
cobookman 9y ago
iptables on the face is easy to use. But at scale becomes difficult to use. Also iptables does much more than just firewalls and can become a confusing tool. Also, in a large enterprise organization the firewall guy is different than the software engineering team which is different than architect.
gramakri 9y ago
While they look the same, the technologies serve different purposes. iptables/ufw block requests at the VM level. So traffic flows all the way to your VM and then your VM spends CPU cycles rejecting those packets. In contrast, these firewall technologies can block traffic at the network edge of the cloud provider. This is done by propagating rules to the edge routers.
- wcarron 9y ago
  Ahh, that changes my perspective on this. That suddenly seems vastly more useful than it did, to me.
derefr 9y ago
I like things like this not because they make the underlying tooling more opaque/encapsulated, but because they expose that tooling to network-API-based management, through tools like AWS's CloudFormation et al. To be able to set up firewall rules for my app in concert with installing the app—and to roll out changes to those rules as part of rolling app updates—my cloud orchestration system has to be told that a given box "is" a firewall, or discover that fact through SNMP or WSDL probing. If it has that capability, then it may as well let me assign properties to the "box-as-firewall" object in its convergence model, rather than the "box-as-box" object—and then, given that it's not doing anything other than being a firewall, maybe let me leave the "box-as-box" object unspecified and have it created automatically by requirement of the "box-as-firewall" spec. Now we're back to the "opaque appliance" abstraction (at least by default), without ever having chosen to design things that way.

metachris 9y ago

I think you are right with the understanding, but its a trade-off to be able to build bigger things more quickly and easily.

cobookman 9y ago

iptables on the face is easy to use. But at scale becomes difficult to use. Also iptables does much more than just firewalls and can become a confusing tool. Also, in a large enterprise organization the firewall guy is different than the software engineering team which is different than architect.

gramakri 9y ago

While they look the same, the technologies serve different purposes. iptables/ufw block requests at the VM level. So traffic flows all the way to your VM and then your VM spends CPU cycles rejecting those packets. In contrast, these firewall technologies can block traffic at the network edge of the cloud provider. This is done by propagating rules to the edge routers.

wcarron 9y ago
Ahh, that changes my perspective on this. That suddenly seems vastly more useful than it did, to me.

derefr 9y ago

I like things like this not because they make the underlying tooling more opaque/encapsulated, but because they expose that tooling to network-API-based management, through tools like AWS's CloudFormation et al. To be able to set up firewall rules for my app in concert with installing the app—and to roll out changes to those rules as part of rolling app updates—my cloud orchestration system has to be told that a given box "is" a firewall, or discover that fact through SNMP or WSDL probing. If it has that capability, then it may as well let me assign properties to the "box-as-firewall" object in its convergence model, rather than the "box-as-box" object—and then, given that it's not doing anything other than being a firewall, maybe let me leave the "box-as-box" object unspecified and have it created automatically by requirement of the "box-as-firewall" spec. Now we're back to the "opaque appliance" abstraction (at least by default), without ever having chosen to design things that way.