Hi All,
Since there had been some interesting discussions surfacing regarding the configuration of SMB products, I thought it would be good to have a users thread discussing the differences so both experts and beginners a like can have a chat about it, it will also prevent the hijacking of threads which often have a tendency to break down once topics like this creep into them... So please if we can out of respect keep discussion of CLI-v-GUI discussion to a single location so the OP's of the threads do not get lost in irrelevant debates that pose little to no help for them.
The CLI versus GUI debate can be often a heated topic, none-the-less it is always an interesting topic for all users to be apart of as it can no doubt shape the path way that Cisco takes, as in the past Cisco have taken on board the views of the Cisco community to assist them with their decision making process, hence the age of GUI accepted practices for SMB products and the eventual move away from CLI practices in this space. This has attracted much fan far and also opposition from both sides of the fence, the interesting part of it is that debate from both sides have been both interesting and in many cases constructive as well
As a personal view on things, I have always taken an objective view on the inroduction of new products and directions, but being a very opinionated person have always voiced my concerns in not so fashionable ways (Nothing new there I guess) and have also given the Cisco management team much grief for some decision that have been made, and in some cases have had to eat my own words, YES humble pie is never a good thing to ones ego
I hope through this discussion people will put in their own opinions and perspectives on this subject matter, and I would like to do a Pro/Con format to point out differences between the two approaches to working with Cisco Products CLI or GUI, where I have missed something out in the Pro/Con section of each pathway, please indicate your own personal opinion in red so I can include it into the original post so new readers or new entrants into the Cisco world can have a good read and through this thread maybe even gain a better understanding, I do hope we get active participation from the community, it would be good
So lets start...
The CLI path:
CLI configuration is generally accessible across all Cisco Products inclusive of their SMB pro series, there are some SMB (Note: NOT SMB Pro) products that do not have CLI access, or if they do, can only be accessed by Cisco Support engineers (In theory), there are many products that can be configured using CLI only and some with a combination of both or pure GUI only. So lets look at the Pro's and Con's of CLI configuration of the Cisco products, and note that this will be driven by users who offer up their opinion.
Pros:
- Flexibility in configuration
- Greater range of options when configuring via CLI
- Certain features can be accessed with CLI only
- Engineers can indavidualize the configuration to their own methodology
- Ability to do clean and cut down versions of the configuration by choosing what to enabled or disable
- Ability to work of text files using a text editor of your own choice and have a template structure
- Better diagnostic capabilities on the CLI
- Better management of the system with CLI
- Better Remote management of the system with CLI due to SSH or Telnet access a widely accepted practice
- Greater control of the system
- Exposes the user to a greater understanding of the inner workings of the appliance in order to work with CLI
- Engineer in theory must undergo certification to work with the Cisco IOS in CLI
- Has access to the worlds best support services... Cisco "TAC" which is an award winning support facility and we all know why
Cons:
- A longer time to become certified, trained and experienced with CLI
- No two configurations are the same in standards due to indavidualization, which can make it hard to support
- Ability to break a system much easier due to Cisco's open nature to the CLI (We give you the rope, its up to you if you want to noose yourself type policy)
- Ability for other engineers to work with due to the inconsistencies of the configuration, it is much harder to interpret someone else's methodology when it is not your own (Not the same as point 2)
- Partners time to market can be much longer when the work force is not seasoned or experienced with CLI
- Perception by the market place as the equipment being to complex to support, manage and maintain
- The cost for the consumer to have qualified staff to manage equipment via CLI, not all clients will want to have partner based support contracts on top of the Cisco based support contract
This is what I can think of myself, and I am certain that this can be expanded upon quite easily so go for it, please give your suggestions for entry and feel free to debate any of the ones I have offered up.
The GUI Path:
Now onto the GUI path way, which I am sure would be the most controversial one due to there being more CLI based experts out there then there is GUI based one (For now that is). However I am personally now an Avid GUI based supporter as of about 3 years ago when I was asked to participate in GUI trials or Early field trials of products/services, it was at this point in time for me (Personally) that I realized my time to deployment could be greatly reduced, purely because with CLI you have to take care in what you are doing and a fair bit of QA in your coding has to be put in otherwise you could be deploying a lemon, and this is never a good thing. GUI based appliances also exposes a larger market for Cisco, which some may debate is a bad thing, but commercially speaking this IS a good thing, and a company needs to constantly expand and evolve if you want to stay in business and ahead of your competitors.
Pros:
- Go to Market can be quicker due to a less strenuous certification path
- Go to deployment can be quicker as the configuration is generally the same and is handled by the GUI based on the instructions given to it by the engineers (Yes I still call them engineers)
- Consistent configuration which are pretty much the same on every deployment with the exception of the individualization of users based configuration and extra services that will differ from system_to_system, but the foundation or base is the same
- Much easier for Cisco to manage and support with trained GUI support engineers, who also understand CLI (You will notice that the majority of SMB support personal are also certified engineers)
- Easier to build the system with a point and click method, two clicks can cover over 15 different lines of configuration that would normally have to be done by hand in CLI
- Opens the market place up to different forms of engineers who may be used to competitors products and do not want to transition to CLI based system
- Has the perception by the market place that the system is easier for management and maintenance (Even if it may not be to various people)
There are probably more Pros but cannot think of them right now (Good thing or bad thing? ) please feel free to add to this and even debate any of them.
Cons:
- Relies on third party systems/operating systems which cab hard to code for and cater for different systems
- Poor QA of the code introduces bugs which makes life for an engineer hard
- Relies on third party Software such as Java or Adobe to allow the GUI to function which relies heavily on the environment it is installed into
- Has bugs some of them can be percieved as being serious
- Long turn around times between revisions and releases
- Has difficulties working with pre-existing system due to the translation of non OOB compliant code, whcih adds another layer of complexity to the engineer, and has support issues
- Is missing features which can be easily achieved on the CLI
- The SMB support mechanisms is not as refined as Cisco TAC which leads to frustration and bigger problems for the "On Ground" engineer, as reflected in other points
- Remote access for GUI based systems is either not stable, hard to achieve or simply cannot be achieved or relies exclusively on the client providing access to a localized system, which is not always available
- GUI is not on system which reflects on various other points listed, On system GUI's have more than one way of accessing them
- Introduces engineers that may not have a good sound/fundamental knowledge of how the product works and functions, they may be able to program the system up and get it to work, but without understanding the fundamentals incorrect provisioning can be easily achieved for that environment, which gives the perception that the equipment is faulty, does not do what it is supposed, or is simply not as good as competing products
That is all I will introduce on the Con's for now, dont want to be seen as picking on it but they are the most obvious things I guess.
So now for the community to chip in, just remember peoples that your post may just be the one that helps out someone else in gaining just that little bit more understanding, do not be shy to engage and provide your input, these forums have a history of partners and users alike assisting each other.
I only ask for one thing, please be constructive, if you disagree with something explain why and put some reasoning behind it, if you want to introduce something please provide an explanation with it so others also understand it, and most of all don't not attack anyone (Flaming) or get personal, respect the opinions of others and debate them if you wish but "RESPECT" others opinions.
Cheers,
David.
Cheers,
David Trad.
**When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *
