3 ms·

Seems to imply that because there are features in the software, it would be preferable to get a build with fewer features for the sake of quality; but that make

Seems to imply that because there are features in the software, it would be preferable to get a build with fewer features for the sake of quality; but that makes no sense, removing features from your build isn't going to improve the features you keep. A lot of this post doesn't make sense. :- P > Hardly understandable if you consider “state of the art” Developmental and operational models like DEVOPS. This, and some other sentences, are gibberish. "DEVOPS" is not an operational model. > Lack of micro-services architecture renders technical debt possible. This of course implies that routers can reasonably be constructed as systems of microservices, which to me seems like it would sacrifice basic performance targets if taken literally. If he means node-based routing, sure, that's basically how things work anyway. More facile, it seems to imply that microservices render technical debt impossible, which is ridiculous. > However, it gets challenged using new concepts like SDN and NFV, which promise much faster network adoption, automated control, reduced time-to-revenue, which all are good business solutions. More gibberish. This is probably not an honest article, but a professional services marketing wankpiece. That's too bad, because frankly it seems like some of the ideas are worth exploring, and I would be more convinced and excited for his company if this were less manipulative and more direct.

yeukhon 9y ago
Despite some of the bad commentary from my point of views as well, I don't believe he is advocating for less features. He is saying networking software is a flooded basement: you will find hardware tools likr hammers and screw drivers, but they are dirty. They still work, but no one wants to clean that shit up for as long as shit works. Someone writing the networking vendor softwares should seriously share their opinions on this issue.
whatupmd 9y ago
As an operator at a networking vendor this article really rang true. To me the whole article was a cry to re-think embedded systems design. He opened with relationship between feature-bloat and hardware performance in networking space. Won't your service be more performant if you avoid STP check on a routed network? Yet because of history and system design even if you don't use STP your hardware will perform check because of system architecture. Just take a walk through an IP or Ethernet header and look at how many of those protocols you actually use. Yet even if you avoid using them you can't 'disable' this checks in hardware. Refactoring seems to be hard or cost-prohibitive for network vendors, so it is avoided (at least until the next hardware generation is released). Even when engineering identifies an architecture problem, most managers will not take the risk of proposing refactoring. Maybe because it's more cost-prohibitive in an embedded system? Maybe because engineering teams implementing 20 year old protocols like ARP, Ethernet, STP, OSPF are in that position because they are inexpensive? His bit about DEVOPs is just trying to point out how QA for networking gear running well established protocols should not be a hard problem, yet for some reason gear gets released still with the same bugs you'd see in 2000. Why is this?
inopinatus 9y ago
Eh, I think it is a sincere attempt at a content piece by a non-native-English engineer and first-time CTO who is perhaps more used to writing IETF RFCs. It isn't gibberish if you take a moment to ponder what he is actually trying to suggest, viz. that product developers at router manufacturers are quite isolated from customers, and that considerable technical debt has accrued due to monolithic control-plane design, and he'd like to try some modern alternatives to both. Maybe you don't like the way he expanded the term "DevOps", but I suggest trying to connect with the ideas rather than jumping at the syntax, and I'd hesitate to rubbish quite so energetically the ideas of someone who appears to have spent fifteen years at Juniper mostly working on JUNOS.
SeanDav 9y ago
> "...removing features from your build isn't going to improve the features you keep." Taken literally, this statement is true, but either deliberately or accidentally, is hiding the reality that removing features can absolutely lead to improvements in remaining features. It reduces overall complexity with fewer points of failure due to less possible interactions. It frees up more time to devote to less features, so quality improves. Less features means improved focus. etc etc. > "This, and some other sentences, are gibberish. "DEVOPS" is not an operational model." https://en.wikipedia.org/wiki/Operating_model https://en.wikipedia.org/wiki/Operating_model Quoted from the wiki: "People, process and technology is one commonly used definition,[1] process, organization and technology is another, and [2] Process, Organization and people, Locations and buildings, Information systems, Suppliers and business partners, Management system yet another.[3]" DEVOPS falls clearly in the Process and Technology areas, as well as overlaps with People and Information Systems. Now one could argue exact relevance, but the OP's assertion that DEVOPS is an operational model is hardly gibberish, as in utterly lacking meaning or relevance.
nunez 9y ago
If we define "operational models" as ways in which people can work, then DevOps is absolutely an "operational model."

yeukhon 9y ago

Despite some of the bad commentary from my point of views as well, I don't believe he is advocating for less features. He is saying networking software is a flooded basement: you will find hardware tools likr hammers and screw drivers, but they are dirty. They still work, but no one wants to clean that shit up for as long as shit works. Someone writing the networking vendor softwares should seriously share their opinions on this issue.

whatupmd 9y ago

As an operator at a networking vendor this article really rang true. To me the whole article was a cry to re-think embedded systems design. He opened with relationship between feature-bloat and hardware performance in networking space. Won't your service be more performant if you avoid STP check on a routed network? Yet because of history and system design even if you don't use STP your hardware will perform check because of system architecture. Just take a walk through an IP or Ethernet header and look at how many of those protocols you actually use. Yet even if you avoid using them you can't 'disable' this checks in hardware. Refactoring seems to be hard or cost-prohibitive for network vendors, so it is avoided (at least until the next hardware generation is released). Even when engineering identifies an architecture problem, most managers will not take the risk of proposing refactoring. Maybe because it's more cost-prohibitive in an embedded system? Maybe because engineering teams implementing 20 year old protocols like ARP, Ethernet, STP, OSPF are in that position because they are inexpensive? His bit about DEVOPs is just trying to point out how QA for networking gear running well established protocols should not be a hard problem, yet for some reason gear gets released still with the same bugs you'd see in 2000. Why is this?

inopinatus 9y ago

Eh, I think it is a sincere attempt at a content piece by a non-native-English engineer and first-time CTO who is perhaps more used to writing IETF RFCs. It isn't gibberish if you take a moment to ponder what he is actually trying to suggest, viz. that product developers at router manufacturers are quite isolated from customers, and that considerable technical debt has accrued due to monolithic control-plane design, and he'd like to try some modern alternatives to both. Maybe you don't like the way he expanded the term "DevOps", but I suggest trying to connect with the ideas rather than jumping at the syntax, and I'd hesitate to rubbish quite so energetically the ideas of someone who appears to have spent fifteen years at Juniper mostly working on JUNOS.

SeanDav 9y ago

> "...removing features from your build isn't going to improve the features you keep." Taken literally, this statement is true, but either deliberately or accidentally, is hiding the reality that removing features can absolutely lead to improvements in remaining features. It reduces overall complexity with fewer points of failure due to less possible interactions. It frees up more time to devote to less features, so quality improves. Less features means improved focus. etc etc. > "This, and some other sentences, are gibberish. "DEVOPS" is not an operational model." https://en.wikipedia.org/wiki/Operating_model https://en.wikipedia.org/wiki/Operating_model Quoted from the wiki: "People, process and technology is one commonly used definition,[1] process, organization and technology is another, and [2] Process, Organization and people, Locations and buildings, Information systems, Suppliers and business partners, Management system yet another.[3]" DEVOPS falls clearly in the Process and Technology areas, as well as overlaps with People and Information Systems. Now one could argue exact relevance, but the OP's assertion that DEVOPS is an operational model is hardly gibberish, as in utterly lacking meaning or relevance.

nunez 9y ago

If we define "operational models" as ways in which people can work, then DevOps is absolutely an "operational model."