Back in that world where I reinvent the commercially available wheel, I’ve been wondering for a while about how to automate the creation of firewall policies in a multi-datacenter environment. This week I started tinkering with possible ways to achieve this, and knocked up some proof of concept code in my favorite untrendy, archaic language, Perl. Don’t say it.
The key issue is that given a firewall request (source IP, destination IP, port) it’s necessary to identify the firewalls and zones to which those rules apply, in order that rules can be automatically built in the right place(s). An additional twist I’ve seen is firewalls that have multiple routing instances, each of which maintains its own set of zones, effectively isolated from each other, even though they’re all on the same firewall.
I spent a while thinking about ways to model the firewall architecture, and kept on getting caught up on the firewalls with multiple routing instances. Because of the routing isolation, they behave like two separate firewalls, which makes it a little tricky to figure out the correct paths. I also wanted a solution that might also tell me which specific firewall zones were involved in the path; Continue reading
Nodding my head so hard my chin is hitting my chest. "What tends to remain behind is the ‘residue’ — the least talented and effective IT engineers. They tend to be grateful they have a job and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. "
The post Response: The Wetware Crisis: the Dead Sea effect Or Where Have All the Good Staff Gone appeared first on EtherealMind.
Building Microservices
Sam Newman
ISBN: 978-1-491-95035-7
Scale out where you can, scale up where you must.
Someone, somewhere, should probably start a collection of “where you can, where must” sayings, as these rules of thumb (thumbs were used by carpenters instead of a ruler to measure an inch, apparently) are important to remember, even if they’re imprecise. Route where you can, switch where you must — really refers to using layer 3 versus layer 2 networking as much as possible — for instance. Scaling out, from the perspective of network engineering, is all about repeatable modules, spine and leaf fabrics, and distribution of the control plane (didn’t think of that last one, did you?).
But what does scaling out mean in the application development world? It means splitting services into modular pieces which interact over the network. The ultimate goal of splitting services is to get to the microservice.
But what is a microservice?
To answer this question, you need to turn to the first chapter of Scaling Microservices, which says, “Microservices are small, autonomous services that work together.” Sam Newman, in the rest of the first chapter, explains the concept well, from a number of different angles, Continue reading
The latest numbers are a little hard to believe.
One of the potential attendees of my SDN workshop sent me a long list of questions. Almost every networking engineer, team leader or CIO asks the first one:
What will happen, if we don´t follow the SDN hype (in the short term, in the medium term and in the long term)?
Answering this question is the whole idea of the workshop.
The up-to-date list of scheduled SDN workshops is available on my web site.
Read more ...As we come close to ending this rather long running series on how the Internet really works (because I’m certain you’re about bored of this series, and ready for me to talk about something else!), I’d like to discuss three more topics I think are really important to the Internet’s operation on a day to […]
The post HTIRW: That Big Number Database in the Sky appeared first on Packet Pushers Podcast and was written by Russ White.