Это очень разные миры. Я работал по обе стороны лагеря, но в основном на стороне сервера. Я работаю на классическом клиент-сервере, а не в Интернете (да, мы все еще вокруг).
- Клиентская сторона - все о взаимодействии с пользователем, серверная сторона (чаще всего) не имеет пользователя. Это на самом деле довольно освобождает.
- Серверная часть означает думать о менеджерах, а не о пользователях. Вам необходимо предоставить доступ для регистрации ошибок, отчетов, диагностики - ваши собственные и журналы событий Windows обычно.
- Клиентская сторона эфемерна (пользователи приходят и уходят), серверная сторона постоянна. Поэтому управление ресурсами имеет первостепенное значение: утечки означают смерть. Утечки памяти, утечки ручек, фрагментация кучи. Вы заканчиваете мечтать об этом материале. Меня притащили в Испанию за 24 часа, потому что одна система может сорваться из-за распределителя памяти Windows DDE в аномальном состоянии, что говорит вам, насколько важен этот материал.
- На стороне клиента отзывчивость пользователя (обслуживание графического интерфейса) - это все, на стороне сервера это сложнее. Многопоточность становится более важной, но она предназначена для масштабируемости, а не для обеспечения поддержки графического интерфейса пользователя. Я не начал подсчитывать циклы процессора или проверять значения задержки прерываний, как я делал это во времена моей прошивки, но он приближается.
- Безопасность становится важной, но меньше, чем вы думаете. Не каждое серверное приложение имеет выход в Интернет. Думайте с точки зрения уровней доступа, ограничения доступа через представления и т. Д.
- Когда-то серверная сторона всегда означала родную, но это меняется.
Edit:
Под поточностью для масштабируемости я подразумеваю, что довольно легко применять потоки так, чтобы они не масштабировались. Создание одного потока для каждого запроса - это нормально, пока ваше моделирование не скажет вам, что у вас может быть пятьсот одновременных запросов. Так что вам нужно думать о пулах потоков и очередях.
Что касается "менеджеров", то здесь действительно есть два типа требований: один - для отчетов SysAdms, а другой - для подходящих типов управления. SysAdms нужна помощь в обнаружении ошибок, которые я считаю системными сбоями, которые могут повлиять на ваши приложения (сбои в работе сети, сетевые сбои, переполнение жесткого диска, аварийное переключение сервера, запуск DR и т. Д.) И диагностике, которую я считаю сообщение об аномальном поведении ваших собственных приложений.
У SysAdms очень краткосрочные потребности - в этот час, в этот день, отправьте мне электронное письмо, отправьте SMS-сообщение, получите его обратно и т. Д. Им постоянно нужна подробная техническая информация, потому что вы не знаете, когда будете действительно нужно это. Но независимо от того, сколько информации вы им дадите, только самые лучшие SysAdms не поднимут трубку и не позвонят вам, когда орда коснется устройства перемещения воздуха.
Менеджеры нуждаются в среднесрочной и долгосрочной отчетности по производительности, сколько запросов в день / неделю / месяц, как я делал на прошлой неделе, что мне нужно сделать, чтобы улучшить эту неделю, как сделать так, чтобы производительность была нацелена на то, чтобы ее видели сотрудники / коллеги / начальство и т. д. Это в основном по запросу (отчеты), хотя часто просят такие вещи, как настенные панели с статистикой работы ... но даже это не обязательно в режиме реального времени. Вы можете высосать подобные вещи из базы данных в опросе. Как серверный парень, вам, возможно, придется разработать некоторые представления, чтобы упростить эту отчетность, но большая часть вашей работы направлена на аномальные условия, которые интересуют SysAdms. По крайней мере, по моему опыту, это так. Но имейте в виду, что если SysAdm не останется довольным, вы все равно будете иметь дело с менеджером ...
В сторону: любопытно, что хотя SysAdms, кажется, ведут довольно напряженную жизнь, все лучшие, с которыми я когда-либо работал, были очень непринужденными людьми. Странно, это. Я полагаю, это механизм выживания.