Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

We Have to Learn How to Manage the Cattle

Not long after I published the blog post arguing against physical appliances, Oven wrote a very valid comment: "But then you'd have 20 individual systems to manage, add licenses to for additional features, updates etc."

Even though the blog post (and the comment) was written in 2013, not much has changed in the meantime.

We’re still dealing with big hardware appliances that are managed like pets instead of smaller virtual appliances that could be managed like cattle, the only exception being distributed firewalls in environments like VMware NSX.

To learn more about pet-versus-cattle analogy, start with the original Randy Bias’ presentation or an updated version.

Even though everyone mostly agrees on the benefits of using the network-services-as-cattle approach, most enterprise environments still haven’t solved the challenge of managing a large number of small appliances, and the appliance vendors still want to charge per box (making the cattle model untenable) instead of by value added (= total throughput or something similar).

It would be great to have a list of firewall and load balancing vendors that got the memo and implemented a throughput-based licensing model for their on-premises virtual appliances. If you encountered one (or are working for one) please leave a comment. Also note that having an appliance on AWS marketplace doesn’t count ;)

There are two ways to manage network services appliances at scale:

  • You make your cattle someone else's pet: each application team becomes responsible for their own firewall and load balancer. This approach works surprisingly well for public cloud vendors, and there’s no reason why organizations that talk about moving into a public cloud wouldn’t implement the same approach for on-premises workloads… or maybe it's all talk and no action.
  • You need tools that allow you to manage at scale. Server people solved that with Puppet/Chef/Ansible/Salt, apps people solved that with Zookeeper (and the like), forward-looking networking engineers already started automating their networks, but the majority of the networking/security industry is yet again a decade or more behind the others, the only exception being the management systems for VM-NIC virtual firewalls (because nobody would be crazy enough to buy them without such a system).

Not surprisingly, the network security management systems follow what the appliance vendors are doing and thus have the wrong focus - instead of focusing on managing 10K rules on a single giant FW, they should focus on managing the cattle - enforcing single policy across all tenants.

8 comments:

  1. Hello Ivan,

    I recently read F5 now has a "per-app" licensing model for its load balancing and WAF modules.
    https://goo.gl/tBH1PQ

    Rgds,
    Fred.

    ReplyDelete
  2. Juniper have throughput-based licensing for vSRX on-prem.
    Disclaimer - I'm a Juniper employee.

    ReplyDelete
  3. Thanks for this treasure from your attic. By the way ASAv has a per connection license model. Disclaimer: I'm not a Cisco employee.

    ReplyDelete
  4. Have a look at vyos or free range routing, depending on your requirements, these packages can offer decent features and automation. Because linux is under the hood, puppet or chef can be used. Or in the case of vyos, use its juniper like syntax to simply deploy and commit/save configs as a whole. Unless I must, I will always deploy clusters of these as firewalls and routers before looking at a commercial vrouter or vfirewall.

    ReplyDelete
  5. Pulse Secure vADC offer a throughput-based licensing.

    ReplyDelete
  6. A10 Networks offers "Flexpool" which is a troughput based License you can split to as many vThunder VM's you want.

    Demo: https://youtu.be/A_eFout4Xb0

    ReplyDelete
  7. Radware offers a throughput based license model for their ADCs/Loadbalancers: https://www.radware.com/products/alteon-gel

    ReplyDelete
  8. "You make your cattle someone else's pet: each application team becomes responsible for their own firewall and load balancer" This was the subject of long debate at my $employer. We have a large enterprise, the apps people want to consume IT like a cloud and of course there is no budget to actually build a fully functional private cloud. The compromise we discussed was microsegmentation and just letting each app team own/manage/operate their own little slice of the network. However, many like the irules, so now we are talking about tons of maintenance OpEx for multiple F5 appliances. And the apps owners aren't accountable for PCI/PII/SOX audits, so letting them manage firewalls seems unlikely. Further, we'd have to build pretty tight guardrails around every tenant to ensure that they don't inject routes. Still haven't found an elegant solution so we are trying to compromise with centrally-managed cattle with limited input from app-owners (such as letting them use their API-driven automation tools to put nodes into F5 pools, or other limited modifications). Still haven't fully divested ourselves from the "pets" but... baby-steps.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Sidebar