Notes to Palo Alto Networks

I’m working with the cloud environments for long and I get use to have the mindset. Whenever I see non cloud-native solution in the cloud, I feel the frustration.

Especially, I find network solutions world so primitive and ancient. In most cases, you see the cloud version of the solution is a giant kludge. You find yourself in a position that you’re trying to debug things blindly or engineering your jugaad to make things work.

Whenever I find myself in a position like this, I immediately ask the questions “What the heck I’m doing” and “What’s the value in all these? Does it worth the effort?”. So, most of the time my only answer is “Well, I’m a consultant and this is the exact requirement from the client. So, do it instead of complaining”. What a motivation, eh?

I’m not going to go into many details in this post and I’ll try to write up the experiences I had with Palo Alto firewalls in another post once I’m done with the implementation, but there are some notes I took time by time while I was frustrated with their way of doing things.

• Git is a source code management system that stores your codebase and the chain of the changes. It’s not a file storage that can have/store binary files.
• Versioning matters. No one wants to build an infrastructure from a branch that might be changed at any time.
• Indentation is important
• camelCase, CamelCase and snake_case shouldn’t be mixed all together.
• Hitchhiker’s Guide to Python or at least Zen of Python should have read by the developers.
• A better understanding of the Separation of Concerns might be helpful.
• Speaking of which, for the solutions that the cloud provider gives you, shouldn’t have re-engineered.
• Having black boxes and making its users miserable or making hard to build flexible solutions were back in the days. It doesn’t sell. Not anymore. Especially in the world of cloud and automation. The day is the community-driven and open world’s day.
• Automation should be visible, traceable, debuggable and accountable. There is no value in having overly complicated and non-accountable automation while the opposite could make your life easier and find its meaning.
• As a vendor, publicly released solutions should’ve planned better and more generic even if it only has one use case. For instance, FIFO queues are only available in the US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) regions. *

Highly possibly I’ll update this list in the course of time.