Pull to refresh
26
0
Nataly @NatalyM

User

Send message
Особо распространяться нельзя, ибо NDA, к сожалению. Если вкратце, то для одного крупного (и что важно совместного с крупной компанией) проекта нужна своя CRM-система, но такая, довольно мощная с разными штуками вплоть до Field Management Control (приглядывать за выездными сотрудниками). По условиям партнера опенсорс не подходит, а это бы все упростило. Вот в итоге и пытаемся понять, инвестировать ли в разработку под себя, или все же стоит поискать что-то на рынке.
Я раньше работала как раз в таком и там коробки были, так что все же не верится. Хотя может что изменилось за это время
Опенсорс иногда по изначальным условиям проекта не подходит, тут у нас как раз такой вариант. Но за советы спасибо!
Ну и что условный провайдер телефонни с парой филиалов никогда не использует коробочные решения? Как-то не верится, право
Ну вот тут я зашла на сайт автора поста и посмотрела цены. Цифры конечно не маленькие, но так если подумать то полтора толковых программиста будут стоить дороже. Короче ясно, что ничего не ясно все сложно здесь. Нам на один проект тут просто тоже сейчас предлагают серьезную коробочную систему, но есть в команде и сторонники собственной разработки, вот и пытаемся понять, как это вообще анализировать
Почему же тогда покупают коробки? Вопрос без подкола, мне правда интересно
Мне вот как человеку не совсем в теме тут как раз хочется понять, в итоге-то такие самописные решения они оказываются лучше коробок или нет? То, что иногда проще самому написать, чем отвалить кучу денег, это факт, но интересно какой результат получается, в среднем по больнице.

В целом напоминает ситуацию «хабр vs облака», конечно :)
Ну в том посте вообще мало что ясно, какой-то рерайт на три абзаца
Хабр он для всех, статья про технологии. Так что все ок, а про захламляют — есть саморегуляция, пост вроде не в минусе, просмотры идут. Если вам конкретно что-то не нравится, то на всех конечно не угодить, нажмите минус и не читайте, в чем проблема-то. Рассказывать про «все можно сделать самому, поэтому статья бред» — это тоже довольно смешно и крайне наивный взгляд.
Ну это как молоток, можно гвоздь забить, а можно черепа проламывать ходить. Все так.
Замена айтишников все же нетривиальная задача. Опять же, я руководитель бизнеса, мне надо думать, как конкурентов обойти, а не апгрейдить айти службу постоянно. Вы говорите с точки зрения ИТ-специалиста, которому все легко и по плечу, а материал явно написан с прицелом на руководителей
1. Возможно и так, но можно и виртуализировать эти нужные сервисы, тогда поддерживать их будет уже команда провайдера. Как я понимаю схему.
2. Это рассуждения из области сферических коней в вакууме. Конечно все невыгодно, выгодно иметь кучу железяк у себя в офисе («надежно же»). Никто не говорит о том, что не надо пользоваться калькулятором при таких масштабных изменениях.
3. Ну это же проблемы админов облачного сервиса. У них не будет выходных, вы-то об этом не узнаете. Есть SLA, есть репутация провайдера, всегда возможны сбои, но в общем и целом вероятность сбоя облака провайдера ниже, чем косяки в инфраструктуре компании (особенно если ИТ — это не ее профильный бизнес).

Понятно, что есть разные вопросы и опасения, но все в итоге все равно будет в облаке. Это прогресс, куда деваться.
Бургер-машина — огонь вообще. Но, думается, такие вещи еще долго будут уникальными и кастомными.
1. Shadow IT есть такое понятие, это значит, что если какому-то финансисту надо что-то поставить на комп для работы не согласованно с ИТ, то он это сделает, и когда оно не будет работать, прибежит к службе поддержки.
2. Сейчас есть у провайдеров услуга по созданию резервной площадки, плюс никто не мешает не выносить все — бывают же гибридные облака.
3. Тут пост же про изменения для ИТ-службы. Это очень важный момент. Я когда-то работала в саппорте, и новогодние каникулы, убитые на перевоз стоек из одного дата-центра в другой не забуду еще долго. А так подключился удаленно и все сделал, красота же.
А что конкретно тут высосано из пальца? Приведены ссылки на два кейса реальных проектов, команды которых вроде положительно отнеслись к переезду на IaaS. Поднять небольшое облако и избавиться от кучи постоянного геморроя по поддержке — это вроде тоже разные вещи. Насчет порядка в ЦОДах, я бывала (в Москве исключительно, правда) в нескольких, там порядок идеальный.
Тут я не спец, ок, но хамство в ответ на быструю правку это явно не оправдывает. К тому же те, кто заходят в пост вынуждены читать в комментах информацию о правке, которая уже пару часов как внесена. Непонятно, зачем это кому-то может быть нужно.
Во-первых, никакой фундаментальной разницы здесь нет, кому надо, все поняли и в первоначальной версии. Во-вторых, читать ваши правки в комментариях лично у меня никакого желания нет, я ожидаю на Хабре в комментариях видеть дополнения к материалу или интересные мнения по теме, а не препирательства в стиле «вы так плохо правите, я буду писать публично» — робингудство это не нужно никому здесь.
Вроде как раз в последних абзацах говорится о том, что не следует эту статью обсуждать в ключе «это хороший или плохой метод», а доносится понятие о необходимости использования разных уровней безопасности.

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

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

Короче вам про Фому, вы про Ерему, и конца этому не видно. Тут в комментах уже все разжевали двадцать раз, достаточно уже, думаю :)

Information

Rating
Does not participate
Location
Тульская обл., Россия
Date of birth
Registered
Activity