понедельник, 18 января 2010 г.

Hotmail: немного о цифрах и архитектуре

Оригинальная статья находится по адресу: http://windowsteamblog.com/blogs/windowslive/archive/2009/12/22/a-peek-behind-the-scenes-at-hotmail.aspx. Здесь я привожу только выдержки из статьи.

Цифры
  1. 1,3 млрд. почтовых ящиков.
  2. 350 млн. человек в месяц активно пользуются сервисом.
  3. 3 млрд. сообщений в день, из которых 1 млрд. отфильтровывается как спам.
  4. Скорость роста хранилищ - 2 Петабайта/месяц.
  5. На сегодняшний день это свыше 155 Петабайт. 70% с основном, это письма с фотографиями.
  6. Это самый большой SQL Server 2008 в мире (мониторинг и управление многими тысячами SQL-серверов).
Архитектура
  • Сервис Hotmail организован в логические "масштабируемые единицы" или кластера:
  • Сервера, управляющие входящей и исходящей почтой.
  • Спам-фильтры.
  • Хранилища данных.
  • Службы мониторинга.
  • Инфраструктура для конфигурирования и автоматических обновлений.
На одном кластере "живут" миллионы пользователей (их число зависит от того, насколько устаревшее оборудование используется) и включает:
  • Frontend-сервера. Проверяют почту на вирусы, "отдают" пользователям почту через web-интерфейс, POP3, DeltaSync.
  • Backend-сервера. SQL и файловое хранилище, спам фильтры, мониторинги, агенты каталогов и сервера, хранящие информацию о том, на каком сервере чья почта хранится.
  • Используются также программно-аппаратные балансировщики нагрузки.
Меры для обеспечения надежности, в общем-то, стандартные. Например, избыточность:используются массивы хранилищ на SQL Server'е. Данные синхронизируются постоянно между серверами. Если один сервер "падает", то за считанные секунды включается перенаправление запросов на другой сервер. Данные хранятся в 4 (четырех) копиях.
 
PS: Из всего описания мне интересно было узнать, что в таком масштабном высоконагруженном сервисе используется SQL Server, а также то, что данные хранятся в 4 копиях (интересно, почему именно в четырех?). А в остальном, это общее описание показывает стандартный для таких проектов подход к архитектуре высоконагруженных приложений.

воскресенье, 17 января 2010 г.

Про удаленную работу для дизайнеров

По ссылочке статья, как можно зарабатывать на удаленной работе дизайнерам. Приводится список фрилансерских сайтов. Т.к. тематика соответствует моему блогу, и ссылочка может бы полезна моим читателям, то привожу ее здесь.

В формате микроблога про MindApps

Примерно месяц назад читал про MindApps обсуждение, в духе: "хорошо, что ребята стараются, но маловероятно, что что-то получится у них." Сегодня я подробно поигрался с этим сервисом. Сильно не понравилось. Я, программист, и то впал в ступор от обилия этих всех менюшечек, пунктиков. А что уж говорить о "любом неподготовленном менеджере"? Интересно, а ребята знают о, например, MS Access, интерфейс которого юзабильней, более того, формы, разработанные в Access, можно экспортировать как web-страницы, организуя на своем сервере доступ к БД через браузер? Не сказал бы я что 1141р. за CD с MS Access сильно обременит бизнесмена. На мой взгляд, это все "игрушки" из разряда Google Docs и etc.
PS: иногда на такие "безобразия" смотришь, и подмывает подготовить свое ответное приложение, без всяких фантазий, на старых проверенных технологиях. Не для того, чтобы "утереть нос", а чтобы еще раз показать, что надо проще быть, проще.

четверг, 14 января 2010 г.

ERP по лицензии GPL: условия выживания

Обязательно прочтите первую часть.

Часть 3. Технические подробности
Общие предпосылки для устойчивого развития ERP-системы изложены в виде четырех условий выживания. Насчет 3-5% рынка ничего сказать нельзя определенного. Есть и другие факторы, кажущиеся малозначимыми, однако их удачное стечение может придать развитию такой системы сильный толчок. Исходя из эти общих условий попробую немного углубиться в технические детали проекта. Именно от деталей уже будет зависеть выполнение первых двух условий выживания из четырех перечисленных.

СУБД
В разных организациях уже могут существовать свои СУБД разных производителей (MS SQL Server, Oracle, DB2 и т.д.). Соответственно, уже есть в штате программисты, владеющими программированием на используемой СУБД. Поэтому, желательно, чтобы наша система умела работать с разными СУБД. У каждой СУБД есть свои особенности, которые, желательно, использовать, т.к. это позволяет зачастую либо значительно повысить производительность, либо сильно упростить решение задачи. Но, с другой стороны, хотелось бы иметь единообразный доступ к данным. Как это можно совместить? Есть два варианта: 1). стандартизировать набор хранимых процедур, образующих интерфейс работы приложения с СУБД (OpenDBI - открытый database interface); 2). использовать скриптовый язык и кодогенератор к нему, что позволит из единого скрипта под каждую СУБД генерировать свой SQL-скрипт для создания структуры БД, а для языка программирования- соответствующий набор классов для взаимодействия с СУБД. Для второго случая набор классов должен реализовывать некий единый интерфейс, чтобы гарантировать единообразную работу других частей приложения с БД. Мне нравятся современные фреймворки для работы СУБД типа hibernate. С их помощью можно успешно комбинировать описанные подходы: со стороны БД обеспечить некий стандартный набор хранимых процедур для работы с данными, а со стороны приложения- стандартный набор классов для работы с БД.
Внутри стандартного набора хранимых процедур программист уже волен делать любые свои оптимизации. Это понравиться гикам.
Не забываем: обязательна поддержка региональных настроек и мультиязычности в OpenDBI!
Каждая подсистема (отдел кадров, ввод заказов и т.д.) такой ERP должна иметь свой OpenDBI (для разных подсистем можно использовать либо свои пространства имен, либо свои префиксы). Это позволит организовать обмен данными между подсистемами, написанными разными группами программистов. В перспективе, этот интерфейс может служить шлюзом для обмена данными между коммерческими ERP, которые обычно не сильно стремятся обеспечить свободную передачу данных с другими аналогичными продуктами- достаточно будет, чтобы в них появилась поддержка OpenDBI.

Ядро
Несмотря на то, что большую часть бизнес-логики можно реализовать внутри OpenDBI, на клиентской стороне останется немало функций:
  • При изменении данных в одном окне надо, чтобы другие окна обновились. Значит нужен механизм рассылки сообщений. Более того, очень желательно, чтобы и другие клиенты могли по событию обновлять данные в интерфейсе пользователя.
  • Нужна подсистема подготовки отчетов, чтобы пользователь мог сам разрабатывать отчетные формы, сохранять их (на диске или в БД), делать общедоступными и генерировать с их помощью отчеты.
  • Подсистема для разработки форм ввода данных, сохранения (диск, БД) и предоставления общего доступа.
  • Подсистема хранения пользовательских настроек.
  • Подсистема тонкой настройки отображения данных под потребности предприятия или отдельных пользователей. Например, с помощью скриптов.
  • Импорт/экспорт данных в другие форматы, например, MS Excel.
  • Подсистемы взаимодействия с внешним ПО и оборудованием (например, сканеры штрих-кодов).
  • Подсистема работы с региональными настройками.
  • Подсистема поддержки мультиязычности.
Количество подсистем, естественно, не ограничивается этим списком. Важное требование к ним- модульная конструкция, позволяющая их гибко подключать или исключать из проекта. В качестве минимального требования к функционалу каждой подсистемы, они должны реализовывать некий стандартный интерфейс, позволяющий передавать/получать данные между подсистемами. Разные группы программистов могут реализовывать свои альтернативные подсистемы, например, может параллельно разрабатываться три подсистемы генерации отчетов. Но благодаря тому, что все три подсистемы будут реализовывать обязательно один и тот же интерфейс, то можно будет легко пересобрать ядро с любой из них. Каждая из них может предоставлять дополнительный функционал помимо реализации стандартного интерфейса.

Интерфейс пользователя
Так, как каждая из подсистем реализует некий стандартный интерфейс, то интерфейс пользователя можно реализовывать с помощью различных технологий. Например, собрать систему можно будет с пользовательским web-интерфейсом или сделать обычного "толстого клиента", а можно и то и другое одновременно.

Вывод
При таком подходе важно стандартизовать интерфейсы различных подсистем и OpenDBI. Это позволит при сборке собственной системы ERP задействовать подсистемы различных производителей и собрать систему под использование с требуемой СУБД. Небольшим производителям систем автоматизации выгодно использовать такую ERP, т.к. они смогут свои системы дополнить недостающими подсистемами или заменить свои менее функциональные подсистемы на аналоги. Вероятно, они (небольшие производители систем автоматизации) станут основными двигателями процесса разработки подобной ERP.
В конечном итоге, система получится очень гибкая, в ней возможно будет комбинировать подсистемы различных производителей, реализуя различный функционал. Таким образом, процесс внедрения будет аналогичен, тому как внедряются коммерческие ERP, с одной стороны. С другой стороны, сохраняется вся мощь универсальных языков программирования. Первые два условия будут соблюдены. А выполнение третьего условия (портфель внедрений) и четвертого (проверка временем) обеспечат те самые небольшие производители систем автоматизации. А насчет 3-5% рынка- уже время покажет.
В приведенном описании ясно прочитывается набор технологий, на базе которых можно реализовать подобную систему. Ясность того, как надо делать- это хорошо. Однако, с учетом того, что система должна быть рассчитана на использование в разных странах с разными стандартами документоведения, то даже простые модули в реализации будут сложны. Поэтому не испытывайте иллюзий по поводу того, что первую версию удастся выпустить очень быстро. Для практиков рекомендую внедрять уже готовые ERP системы, для пылких умов- присоединяйтесь к уже существующим проектам разработки ERP систем, например, OpenERP или выбирайте по списку, для авантюристов- дерзайте, конечно, но главное тут- сначала написать стандарты, описать интерфейсы, а уж потом программировать.
Это все: у меня эти мысли роились в голове, я их высказал.

среда, 13 января 2010 г.

ERP по лицензии GPL: условия выживания

Обязательно прочтите первую часть.

Часть 2. Условия выживания
В мире ОС есть такое явление как Linux, распространяемая по лицензии GPL. Есть и другие виды лицензий, в той или иной степени декларирующие бесплатность распространения программного продукта. На сегодняшний день эта ОС получила заметное признание среди пользователей. Есть другой мир- мир ERP-систем. И в нем подобного рода лицензии широкого распространения не получили. Я помню множество ПО автоматизации предприятий, бухгалтерского учета и других учетных систем, которые распространяли по лицензии GPL. Однако с уверенностью могу сказать, что, на сегодняшний день (2009 год), ни одна такая система подобного же, как и Linux в мире ОС, распространения не получила. В порядке эксперимента, предлагаю обсудить, как можно создать ERP-систему, распространяемую по лицензии GPL, которая потенциально могла бы занять, например, минимум 3-5% рынка систем ERP.
Ну, понятно, если представить объем работы и оценить всю картину, то выглядит этот эксперимент смешно. Тем не менее, поиграем по-серьезному. Наш герой и образец для подражания- Линус Товальдс. Когда он начинал, то вряд ли представлял, что у него получится, тем более в те времена многие делали свои ОС "на коленке" и Linux была просто "одной из". А почему не выжили или не процветают системы, пусть не уровня ERP, а автоматизации отдельных частей деятельности предприятия, распространяемые по лицензии GPL? Имеет ли вообще для предприятий значение, что система распространяется по лицензии GPL? Не ходя "вокруг да около" сразу скажу на основании своего и изучения чужого опыта: в нашей стране поголовного пиратства это имеет минимальное значение. Поэтому, идея бесплатности не может служить ведущей идеей при разработке подобной системы. Другой аспект, касающийся лицензирования- это использование не ворованного ПО, чтобы не давать лишнего повода силовым ведомствам придраться к Вам. Ха! Еще три раза: ха, ха, ха! Обросьте эту наивную мысль. Так что же остается? Тип лицензии мало кому интересен, разве что рассчитывать на распространение по всему миру, особенно в развитых странах, где лицензия- не пустой звук. Пусть будет так! Первое условие выживания: изначальная ориентация на распространение по всему миру. В каждой стране свои стандарты учета, отчетности, однако опыт мировых лидеров, таких как SAP, Oracle показывает что реально под все это разнообразие стандартов подвести единую техническую базу. С точки зрения технической реализации изначально должна быть поддержка мультиязычности и региональных настроек как на уровне обработки данных, так и на уровне интерфейса. Выбор однозначный за Unicode, в самой системе должно присутствовать API, возвращающее региональные настройки ОС.
Хорошо, допустим у нас есть подобная система. Что надо, чтобы ею захотели пользоваться? Есть пользователи: экономисты, бухгалтера, операторы. Есть те, кто принимает решение о покупке: начальники отделов, директора. А есть те, кто дает свое заключение о пригодности системы к эксплуатации, и дает советы с технической стороны- это ИТ-отделы предприятий, консультанты. Пользователи в процессе выбора даже на большинстве малых предприятий безголосые- что дадут, тем и пользуются. Решение принимают руководители. Вопрос откатов не буду рассматривать- только честная конкуренция. А значит, мнение технических специалистов или консультантов очень важно. Второе условие выживания: система должна нравится техническим специалистам. Как это обычно бывает- сначала подтянутся гики и организуется тесное сообщество вокруг системы. Однако, чтобы система "пошла в народ" нужна харизматичная личность, умеющая убеждать и заражать других своим оптимизмом по поводу перспектив этой ERP-системы. Гикам эта система может понравиться, если ее можно будет очень гибко настраивать, реализуя умопомрачительные конфигурации. Такое возможно, если использовать в системе скриптовый язык программирования. Проще будет, если это какой-либо уже известный язык: Python, Java, C#. В чистом виде эти языки абсолютно непригодны для программирования конфигураций ERP-системы. Однако на них можно написать framework, повышающий удобство и скорость конфигурирования системы под требования предприятия.
Прекрасно, система у нас есть, есть сообщество, есть лидер. Нужно ли еще что-то, чтобы система достигла поставленной цели? То, что система нравится технарям, еще не означает, что будет принято решение о ее внедрении. Руководитель захочет убедиться, что система оправдает себя: внедрение в любом случае будет стоить денег, даже если сама ERP-система бесплатна. Заранее это трудно спрогнозировать, но хороший портфель примеров реальных внедрений поможет в этом вопросе. Да это же наше третье условие выживания! Третье условие выживания: наличие портфеля примеров реальных внедрений. Портфель наработать можно начиная с небольших внедрений. Малые, средние предприятия, отдельные самостоятельные учетные системы (например, печать ценников или более крупный пример- складской учет). Хорошие, яркие примеры внедрений в руках харизматичных лидеров, владеющих ораторским искусством, становятся мощнейшим орудием убеждения.
В конечном итоге такая ERP-система должна проработать у пользователя лет десять, развиваться, доращиваться, удовлетворяя изменяющиеся и/или возрастающие потребности предприятия. Новые потенциальные пользователи должны видеть на примере, что, будучи внедренной, система не станет узким местом, и не будет создавать существенных трудностей в эксплуатации. Четвертое условие выживания: проверка временем.
Продолжение следует...

вторник, 12 января 2010 г.

ERP по лицензии GPL: условия выживания

Часть 1. Почему я об этом захотел написать?
Примерно лет 10 назад я плотно сидел на внутренней автоматизации предприятия: генераторы отчетов, датасеты, гриды, печать, БД- т.е. весь типичный набор технологий "автоматизатора". Мой друг занимался, в то же самое время, той же автоматизацией, но на базе 1С. Он очень любит программировать в 1С, т.к. встроенный язык 1С очень прост в освоении, а сама программа имеет развитой инструментарий для генерации различных отчетов и экранных форм. Мы периодически затевали споры на тему: "Что лучше: 1С или язык программирования, типа Delphi, C#, Java и СУБД?" Существенным аргументом в мою пользу было то, что на универсальном языке программирования и СУБД я мог гораздо гибче программировать, чем на 1С, да и быстродействие получалось чувствительно выше. Его аргументом было то, что на 1С можно очень быстро ваять отчеты и экранные формы.
Однажды он поинтересовался у меня по другому поводу, как осуществлять подключение к БД из языка программирования, т.к. программируя в 1С, он этого не знал, а тут потребовалось зачем-то. При нем я на форму накидал мышкой компонент, в их свойствах прописал подключение к БД. Мастер настроек сам при этом предложил доступные БД для прописывания пути к ним, так что ручками и набирать ничего не пришлось. Пять минут- и приложение готово! Я запустил его, на экране показалась форма с заполненным данными из БД гридом. Все это сортировалось, месторасположение и ширина колонок могли изменяться. Накидав на скорую руку приложение для демонстрации, я повернулся к приятелю, чтобы подробней спросить у него, что ему показать. Его лицо было вытянуто, глаза как два пятака, а он сам, буквально, онемел. Пришлось ему повторить вопрос. Его "расклинило", и он воскликнул: "Как у тебя получилось написать целую программу? Ты ведь даже до клавиатуры не дотронулся!"
Я знаю, что в 1С делать отчеты, экранные формы ничуть не легче, чем в распространенных IDE универсальных языков программирования. Конечно же, благодаря своей заточенности под конкретные функции, 1С гораздо проще и быстрее внедрить. При использовании универсальных языков программирования трудно будет вначале, пока не написан своеобразный framework, набор функций, позволяющий оперировать информацией на метауровне. А потом уже, по ходу работы, 1С не будет иметь никаких преимуществ перед универсальными язками программирования+framework+СУБД. Только получается, что на каждом предприятии этот framework обычно пишут с нуля. Как обычно, попадают на те же грабли, на которые наступали другие разработчики другого предприятия. Потом оголтело бегают по форумам в Интернете с криками "help! help! что делать если...".
Тогда я задумался, а почему, собственно, нельзя написать такой framework, чтобы его все использовали, а не изобретали каждый раз новый велосипед? Тогда получилось бы красиво: из плюсов 1С мы бы получили быстрое и простое развертывание приложения на предприятии, а из плюсов универсальных языков программирования - гибкость программирования и хорошее быстродействие. А хорошо бы, чтобы стоил он недорого или вообще, как Linux, бесплатный был.
Время шло, и я окончательно пришел к мысли, что не надо фантазировать, а лучше использовать готовые системы, типа 1С. Но подспудно грызла мысль: "А что если получится как у Товальдса, только в области ERP?" Вроде все понятно: собрать вместе свои наработки, оформить их, так чтобы это выглядело единым framework'ом, и выложить для публичного доступа. А народ там подтянется, framework начнет развиваться. Но, с другой стороны, меня грыз "червячок": а зачем это надо, ведь та же 1С, фактически и представляет собой тот самый framework. Система недорога, а, если учесть развитость воровства ПО в нашей стране, то, вообще, цена перестает быть решающим аргументом.
Поэтому, осознавая бесплодность своих мыслей 10-летней давности, я решил их изложить в блоге, не ставя перед собой цели реализовать эдакую GPL ERP а-ля Linux. Больше "в назидание потомкам", чем для попытки, что-то реально сделать.
Продолжение следует...

пятница, 1 января 2010 г.

21 век однако...


Никогда не слышал про ИНФОкрасные сауны. Поискал по Интернету- может это я такой дремучий, и не в курсе новых ИТ-технологий?