Agile Ops is pleased to announce the General Availability (GA) of CA Network Flow Analysis Release 9.3.6.
Key New Features for CA Network Flow Analysis R9.3.6 include:
Where to Obtain CA Network Flow Analysis Release 9.3.6
You can download your copy of CA Network Flow Analysis r9.3.6 from CA Support Online https://support.ca.com/.
If you have any questions or require assistance contact CA Customer Care online at http://www.ca.com/us/customer-care.aspx where you can submit an online request using the Customer Care web form: https://communities.ca.com/web/guest/customercare. You can also call CA Customer Care at +1-800-225-5224 in North America or see http://www.ca.com/phone for the local number in your country.
Release Notes
For more information on the new capabilities in CA Network Flow Analysis r9.3.6, see: CA Network Flow Analysis r9.3.6 Release Notes.
Tyler,
thank you for the quick response.
I'm sure, the two tier architecture would indeed be a good solution and I'm also sure, I have to replace Windows 2008 by Windows 2012 servers.
And of course it's o.k. that a new version did not support old architectures.
But, what I expect as the customer is, that there is at least one step between "only old" and "only new".
9.3.6 not only contains the new architecture. It contains also functional improvements, e.g. for Cisco ASA . (A.f.a.I.,k.)
I need these improvements now for my old installation and later this year or next year I will migrate to new servers with the new architecture.
Installing new servers increases our TCO and I don't want do this every 2 years.
I can expect such a hard cut, if I use shareware.
But I can't accept this for expensive professional tools.
When I spoke the first time with my colleagues and my boss about this, one reaction was:
"Before you install new servers you should look for alternative products with better support!"
These discussions are what you are provoking.
Best regards,
Frank
Happy to set up a session and share it with you, Scott. I'll reach out over email and we can find a time that works for both of us.
Personally, I’d like to see a roadmap. Where is it going? IS there a plan?
Frank,
Ron and I and members of the R&D team spoke last week. Through a half-hour conversation we each were able to understand where we are coming from. He understands why we have not carried the three-tier architecture forward - focusing on one architecture to support allows us to bring new capabilities to market faster and we chose the two tier architecture for many reasons. He also realized that the two tier architecture would indeed be a good fit for his use case, and with the new architecture, he can use his existing DSAs as new harvesters as he is on-boarding new customers.
Where we dropped the ball (and I apologize) was in not having the migration capability available at the time of launch, which we are looking to address as soon as possible.
I offered this to Ron and it led to our conversation, and I offer the same to you - please feel free to write to me at tyler.peterson@ca.com in case you have further questions. Additionally, as I mentioned before, we have a beta version of the next release of NFA which includes the ability to move historical data from each DSA to the appropriate harvester(s). Let me know if you would like to participate.
Tyler
I think here is nobody from CA who would like to answer unpleasant questions about NFA 9.3.6.
"The 3-Tier architecture is still supported in NFA 9.3.3 and will continue to be."Yes, but that means we are at a dead end and will see no further development."No "end of support" date for 9.3.3 has been announced, and as a general rule CA will continue to support a version for at least a year after we announce that support for it will end."Merely delaying the inevitable.These are non-answers. How about answering the questions you've been asked? Such as, "Whose idea was THIS?" and all the ones that Frank asked. Do you think they are not legitimate? Is that why you did not answer them? And how about telling us why you're doing this and why those of us using the 3-tier architecture were not consulted on this ahead of time?
One comment on this:
1) People who are current using a 3-tier architecture are now unsupported.
This isn't quite correct. The 3-Tier architecture is still supported in NFA 9.3.3 and will continue to be. No "end of support" date for 9.3.3 has been announced, and as a general rule CA will continue to support a version for at least a year after we announce that support for it will end.
Sorry,
but for whom do you develop?
New versions without migration paths: Do you think, this is what your customers want?
No chance to update our existing 3-tier Environment to 9.3.6: Do you think, this is what your customers want?
When will you release the version with migration path?
What shall we do, if we need the functionalities of 9.3.6 now?
We pay maintenance fee for this "support", but who pays the additional time we need to instal new servers with new OS for this update?
Best regards
Ron,
I appreciate your concerns and we've taken your feedback and that of others into consideration. The next release of CA Network Flow Analysis is planned to include a migration from 3-tier to 2-tier architecture, including keeping your old data.
Please feel free to write to me at tyler.peterson@ca.com if you have further questions; I'd be happy to walk you through our roadmap and answer any additional questions you might have.
Also, we are starting a beta program for the next release; please let me know if you are interested in participating.
You forgot to mention a couple of other key features:1) People who are current using a 3-tier architecture are now unsupported.
2) There is no migration path established from 9.3.3 to 9.3.6!Whose idea was THIS? I work for a service provider. The current 3-tier architecture was perfect for me. I put a cheap harvester in each client's environment/address space and route the records from it to my R/A and DSP in my environment. In fact, I just spent a bunch of money last fall to get rid of all the old proprietary DSA, R/A and Superharvester hardware that I was running 9.1.3 on, buy new hardware and Windows licenses and upgrade to 9.3.3. The lack of a convenient migration then meant that I lost all my old data because it was going to take up too much time and resources to convert over the old data while keeping current polling current. That was fun, and I had to do some fast talking to management to get the money and project time and sell them on "Well, we don't really need that old data". You can imagine how well that went over. And now you want me to set up a separate environment with a full set of hardware, run it in parallel until I "feel comfortable" and lose my old data again?
Plus, now my database for each customer is going to have to be in the customer's environment. I run into latency when I run reports that require me to go to the harvester instead of the DSA for data. Now every report requires me to go to the harvester? EVERY report is going to run slow?
And NO migration plan. Again. I have informed my management about this and their reaction was to direct me to investigate buying a new product and migrating off of NFA completely. As much as I like NFA I have to agree the expensive and arbitrary way that CA has now treated us twice makes it very difficult to continue to use this product.
Hi Scott,
I appreciate the honesty. As product manager, I am the owner. That said, I cannot commit to it - the best I can say, due to revenue recognition rules, is what I've said, which is that it's on the roadmap, under consideration. And of course I prioritize features higher the more customers that stand to benefit. We have several customers that have asked, hence its priority is increasing.
When we get to the point that the API feature is ready to beta test, would you be interested?
Best,
Hi Tyler,
That's nice to hear, but, I've been hearing that for many, many months, so, until I see an actual commitment and an owner, I don't believe it. Just being honest.
Scott, I've heard the same thoughts from others. Rest (REST?) assured, this is on the roadmap and under consideration. Initially focused on administrative use cases (programmatically enable/disable interfaces, as an example).
Maybe, just maybe, they’ll address the API someday…