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

Оценить экономику компании помогают несколько простых метрик — MRR, CLV, CAC. В этом посте мы расскажем о том, как их считать и интерпретировать.

MRR: как оценить рост бизнеса

Основная особенность облачной компании — она продает сервис, а не лицензии. На практике это означает, что клиенты оплачивают доступ к решению по подписке, как правило, ежемесячно.

Традиционно, если серверу собственной подсистемы хранения данных оказывается недостаточно, то выбор ограничивается DAS (подключаемыми напрямую дисковыми полками) и сетевыми блочными или файловыми хранилищами. Но недавно к этим вариантам добавился еще одна весьма перспективная концепция — Shared DAS. Чем же она хороша?

Наша статья по Shared DAS вызвала большой отклик и вопросы о возможности тестирования. Некоторое количество компаний брало на тесты разные варианты решений, но желающих оказалось настолько много, что мы решили сделать универсальный стенд с максимально возможным количеством современных технологий по хранению данных.



Конфигурация под катом.

Ранее мы увидели как организована виртуальная память процесса. Теперь рассмотрим механизмы, благодаря которым ядро управляет памятью. Обратимся к нашей программе:

Привет, Хабр!

Сегодня я хочу рассказать о некоторых решениях проблем, которые возникают во время использования высоконагруженных систем. Все, о чем пойдет речь в этом материале, проверено на собственном опыте: я – Social Games Server Team Lead в компании Plarium, которая занимается разработкой социальных, мобильных, браузерных игр.

Для начала немного статистики. Plarium занимается разработкой игр с 2009 года. На данный момент наши проекты запущены во всех наиболее популярных социальных сетях («Вконтакте», «Мой мир», «Одноклассники», Facebook), несколько игр интегрированы в крупные игровые порталы: games.mail.ru, Kabam. Отдельно существует браузерная и мобильная (iOS) версии стратегии «Правила войны». В базах числятся более 80 миллионов пользователей (5 игр, локализация на 7 языках, 3 миллиона уникальных игроков в день), в итоге все наши серверы получают в среднем около 6500 запросов в секунду и 561 миллион запросов в сутки.

В качестве аппаратной платформы на боевых серверах в основном используются два серверных CPU с 4 ядрами (x2 HT), 32-64 GB RAM, 1-2 TB HDD. Серверы работают на базе Windows Server 2008 R2. Контент раздается через CDN с пропускной способностью до 5 Gbps.
Разработка ведется под .NET Framework 4.5 на языке программирования C#.

Учитывая специфику нашей работы, необходимо не только обеспечить стабильное функционирование систем, но и гарантировать, что они смогут выдержать большой скачок нагрузки. Увы, многие популярные подходы и технологии не выдерживают проверку высокой нагрузкой и быстро становятся узким местом в системе. Поэтому, проанализировав множество проблем, мы нашли оптимальные для нас (как мне кажется) пути их решения. Я расскажу, какие технологии мы выбрали, от каких отказались, и объясню, почему.

Всего какой-то месяц назад (23-25 апреля) в славном городе Будапешт прошла конференция для разработчиков CRAFT. Мне посчастливилось на нее попасть и вот теперь дошли руки написать отзыв об увиденном и услышанном.

Конференция заманила к себе не тем, что можно за корпоративный счет выбраться в Европу, а подборкой приглашенных авторов, среди которых были Dan North, Michael Feathers, Bruce Eckel, Eric Evans, Greg Young. Странно, что о ней не было упоминания на хабре. Не смотря на то, что конференция заявлялась как конференция для разработчиков, она была совсем не о технологиях. Было несколько докладов про использование конкретных технологий, но большинство докладов было про разработку вообще.

Девизом конференции можно назвать призыв «Адаптируйся!». Эта мысль звучала в очень многих докладах. Может организаторы поэтому не выдали блокнотов в пакете участников — хотели, чтобы мы адаптировались? =) При этом выдали ручки и пришлось искать блокнот в окрестных магазинах.

Под катом описание и видео докладов, которые мне показались наиболее интересными.

Некоторое время назад после волшебного пендаля под названием Tolstoy Summer Camp я начал пилить свой стартап.
Сначала у меня в команде было два разработчика и дизайнер. Потом один разработчик ушёл пилить свой проект. Затем появился другой разработчик. И всё бы ничего, но я сходил с ума от того что не мог найти простых и понятных средств ведения дел в таких маленьких компаниях как моя.
Я перепробовал тучу всяких Basecamp, Asana, Redmine, Trello, Мегаплан и прочих, массу мессенджеров в разных сочетаниях c он-лайн файлопомойками типа Dropbox и GoogleDrive — ничего мне не нравилось. «Ну, не то это всё, не то!».

Для небольших компаний нередко применение всего двух-четырех серверов с виртуализацией, два Ethernet свитча порой даже с возможностью стекирования и Multi-chassis EtherChannel плюс СХД младшей серии — это вполне стандартная конфигурация инфраструктуры среднего бизнеса.
Таким предприятиям очень важно максимально задействовать все доступные технологии, чтобы максимально утилизировать своё оборудование и в этой статье пойдёт речь как этого добиться.

В большинстве современных серверов на борту как правило присутствует минимум два 1Gb интерфейса под данные и один 100Mb для менеджмента.

На СХД младшей серии NetApp FAS2240/FAS2220 на борту каждого контроллера помимо прочего присутствует 4х 1Gb порта.
Т.е. вполне логично использовать схему, где два свича в стеке используют Multi-chassis EtherChannel агрегируя линки идущие от каждого контроллера в каждый свитч для получения как отказоустойчивости так и утилизации пропускной способности всех этих линков. Такая-себе архитектура по образу и подобию FlexPod Express, но без модно-дорогой фичи vPC как у свитчей компании Cisco серии Nexus, в таком случае вместо интерлинков просто будет использован стек свичей. Да и вообще сервера и свитчи в такой схеме могут быть любого производителя. А если совсем всё туго с бюджетом, то можно использовать прямое включение в сервера, так если у сервера 2 порта на борту, можно будет подключить 4-ре сервера, а когда нужно будет добавить 5-й сервер, тут уж прийдётся покупать свитчи.


Схема подключения FlexPod Express.

Windows принято не любить. Однако, зачастую, фраза: «Книгу писателя не читал, но осуждаю» очень хорошо описывает эту ситуацию. Несмотря на укоренившееся презрение к «Винде», отдельные вещи в ней реализованы весьма удачно, и именно об одной из них мы хотели бы написать. Отдельные фрагменты WinAPI, хотя и были реализованы достаточно давно, по разным причинам, и часто незаслуженно, выпали из поля зрения широкой аудитории.
В этой статье речь пойдёт о встроенной в ОС реализации lock-free стека и сравнении его производительности с кросс-платформенными аналогами.

Я надеюсь, что эта статья станет началом цикла заметок о lock-free структурах данных. Я хочу поделиться с хабрасообществом своим опытом, наблюдениям и размышлениями о том, что такое lock-free структуры данных, как их реализовывать, подходят ли концепции контейнеров стандартной библиотеки STL к lock-free контейнерам, и когда стоит (и стоит ли вообще) применять lock-free структуры данных.

В предыдущих своих заметках я описал основу, на которой строятся lock-free структуры данных, и базовые алгоритмы управления временем жизни элементов lock-free структур данных. Это была прелюдия к описанию собственно lock-free контейнеров. Но далее я столкнулся с проблемой: как построить дальнейший рассказ? Просто описывать известные мне алгоритмы? Это довольно скучно: много [псевдо-]кода, обилие деталей, важных, конечно, но весьма специфических. В конце концов, это есть в опубликованных работах, на которые я даю ссылки, и в гораздо более подробном и строгом изложении. Мне же хотелось рассказать интересно об интересных вещах, показать пути развития подходов к конструированию конкурентных контейнеров.
Хорошо, — подумал я, — тогда метод изложения должен быть такой: берем какой-то тип контейнера — очередь, map, hash map, — и делаем обзор известных на сегодняшний день оригинальных алгоритмов для этого типа контейнера. С чего начать? И тут я вспомнил о самой простой структуре данных — о стеке.

Накопилась уже внушительная пачка материалов по Windows Server 2012 и Windows Server 2012 R2. Решил для удобства свести все ссылки в один пост. Надеюсь, будет полезно.

gitolite — это средство для создания централизованных репозиториев для совместной разработки через git.

Зачем оно нужно?

Родные средства git для этой задачи на сегодня явно недостаточны: родной git-протокол не содержит каких-либо средств авторизации, а для работы через ssh потребуется завести полноценного юзера в ОС (с шеллом), что далеко не всегда уместно и желательно.
gitolite же позволит вам заводить пользователей независимо от наличия аккаунта в ОС и гибко раздавать права.

Путь к размещению SQL Server в любом облаке, будь это Microsoft или другое, должен начинаться с тщательного планирования. Архитектурные решения, принятые на ранней стадии проекта, могут совершенно неожиданным образом повлиять на будущее проекта, причем не всегда это могут быть очевидно-решаемые проблемы. Планирование также включает в себя решение о том, в какой модели должен размещаться SQL Server — в модели IaaS (на виртуальной машине) или в модели PaaS (как SQL Azure DB). Разница между моделями заключается как в особенностях технологического плана, так и ценового, например уровни соглашения об обслуживании (SLA) обеих моделей, влияние латентности как на ранней стадии, так и на стадии выхода проекта в свет, автоматизации и многого другого.
 
В этой статье мы попробуем разобраться не только в том, какие технологические различия есть между IaaS и PaaS в Microsoft Azure, но и том, откуда может такая разница возникать, откуда могут возникать проблемы в PaaS, которых можно и не встретить в IaaS, и архитектуре этих решений, а также о том, что такое Azure SQL DB Premium и когда его нужно использовать.
 

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

Пользуясь советами из предыдущих статей, мы нашли хорошего юриста и надёжного бухгалтера для нашей условной компании. Бизнес встал на ноги, местами начал расти, приходят новые клиенты, дел гора, домой возвращаемся поздно и нерегулярно, в выходные развлекаемся выполнением недобитых за рабочую неделю задач. 1024 чашки эспрессо и пару бессонных ночей спустя, голоса в голове начинают нашёптывать волшебное слово «делегирование». Преодолев тяжёлые моральные противоречия, про которые хорошо написал Максим Ильяхов, предприниматель начинает искать человека, который поможет вырваться из рутины. Таким человеком может стать секретарь, личный помощник или бизнес-ассистент.



Рынок предлагает кучу вариантов, начиная c веб-сервисов и заканчивая штатными сотрудниками. Мы провели небольшое исследование и хотим рассказать о популярных вариантах, которые подойдут московским предпринимателям в диапазоне от микро до среднего бизнеса. Постараемся быть объективными и не тянуть одеяло на Кнопку, хоть это и непросто.

Начиная работу с новым сервером, нелишним будет проверить, соответствует ли он заявленной конфигурации. Многие начинающие пользователи испытывают затруднения в случаях, когда требуется просмотреть информацию о сервере с использованием команд, доступных только в консоли.

В этой статье мы расскажем о том, как можно получить спецификацию Linux-сервера в командной строке.

Доброго времени суток, уважаемые хабравчане. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

PourOver

Библиотека для реально быстрой фильтрации и сортировки огромных коллекций, где речь идет о сотне тысяч элементов. PourOver построен на идеально простых запросах, которые могут произвольно формироваться друг с другом. Вы сможете объединять, скрещивать и разделять запросы. PourOver будет помнить как были построены ваши запросы и по-умному обновлять их, если появятся новые элементы или будут изменены старые. Работает на IE7+, Firefox 4+, Safari 5+, Opera 9+, Chrome 1+.

Стоит также заметить, что это проект от New York Times, на корпоративном Гитхабе которого есть еще популярный backbone.stickit плагин для датабиндинга и Tamper — serialization protocol for categorical data. В последнее время гики из западных СМИ прямо раскочегарились — вот недавно я писал про классные проекты от The Guardian и Financial Times.

Microsoft Azure предлагает сервис балансировки нагрузки для виртуальных машин (IaaS) и облачных служб (PaaS), запущенных в облаке Microsoft Azure. Помимо прочих достоинств, балансировка нагрузки позволяет масштабировать ваши приложения и дает возможность мягче реагировать при возникновении ошибки или отказа.

Службы балансировки нагрузки могут быть задействованы как с помощью настроек на портале управления Microsoft Azure, так и с помощью сервис-модели вашего приложения. Как только размещаемая служба с одной или несколькими конечными точками публикуется в облако, она автоматически настраивается на использование балансировщика нагрузки, предоставляемого платформой Microsoft Azure. Чтобы получить все плюсы эластичности и масштабируемости вам необходимо иметь хотя бы две виртуальных машины, настроенных на одну и ту же конечную точку.

Диаграмма на рисунке ниже показывает пример приложения, расположенного в Microsoft Azure, которая использует балансировщик нагрузки для адресации входящего трафика (по адресу/порту 1.2.3.4:80) на три виртуальных машины, слушающих 80й порт (кликабельно).


Далее перечислены основные возможности балансировщика нагрузки в Microsoft Azure

В последнее время на рынке появилось множество сервисов, предлагающих за денежное вознаграждение свои услуги по обеспечению высокого качества вашего продукта. Точнее, по контролю этого самого качества. Однако за красивой вывеской часто скрываются проблемы, сводящие на нет всю пользу от такого “тестирования толпой”. Хотим поделиться нашим опытом и уберечь вас от повторения некоторых ошибок.