Мне стоит добавить еще несколько вещей:
1. я говорю одновременно и от мира энтерпрайза и от стартапов. Их отличает не так и много, ведь часто даже в энтерпрайзе надо иметь возможность быстро запуститься, провести эксперимент, а там как пойдет
2. по безопасности я говорю только о том что вы не сможете обеспечить того же уровня и лучше делегировать это сервису. Чем больше делегируете, тем больше у вас сил и времени на ваш продукт же
3. с сервисами вы не получаете проблемы, а переносите ответственность в другое место и снижаете риски (надо понимать что риск есть в обоих случаях, но то что хотите вы менее надежно)
4. NDA действительно не особо защищает, а вот про Privacy Policy и Users Agreement - они не защищают, а доносят до вас кто за что отвечает и в каком порядке это происходит. Советую их читать чтобы убрать паранойю
5. Если вы для совместной работы вынуждены сидеть в одном редакторе то у вас плохо построена эта самая совместная работа. Проект, даже самопал стоит разделить на модули и писать их независимо. Есть такие термины как архитектура (есть сетевая, есть взаимодействия, есть структуры приложения), модульность, контракт и много чего еще. Вам стоит научиться писать такие модули что они будут закончены и не будут влиять на работу другого человека.
6. Про требуемый вам уровень безопасности ... вы понижаете уровень безопасности, как мне это видится, увы.
дальше будет много букв в довольно резкой форме. ппрошу понять - я не со зла, а в целях помочь в осознании важных моментов как в разратобке, так и в бизнесе. Вам успехов, а я начинаю.
субъективно:
0. вы параноик, который читал одно, но забыл прочитать другое
объективно:
1. Про NDA слышали все, все подписывали, а те, кто еще и делал это внимательно знает что почти ни от чего оно не защищает
2. ваши вопросы относятся не к NDA, а Security. Знаете разницу?
3. У вас есть начальный план и RoadMap. А теперь вам нужно узнать про термин Time to Market, посчитать его и минимизировать насколько это только возможно.
4. Для справки - SaaS, IaaS и другие *aaS созданы для того чтобы упростить жизнь, ускорить разработку и сократит Time to Market и увеличить прогнозируемость движения вперед
5. Вы знаете про NDA, А теперь, давайте поговорим про такие документы как Privacy Policy и Users Agreement, которые стоит прочитать у сервисов перед тем как сразу брасаться свои сервера поднимать и надеяться что это более безопасно
6. А теперь о Security и ваш страх перед облаками и "мою и дею и код стырит плохой дядя". Есть Shared Responsibility Model, которая включает Security in the Cloud и Security of the Cloud.
Security of the Cloud - безопасность облака, за которую отвечает вендор. Если коротко то это обоспечение доступности сервисов, сохранности данных, ротиция паролей и токенов, а так контроль сотрудников облака чтобы никто к вашим ценным данным руками не залез (может вы в Git храните персональное порно)
Security in the Cloud - ваша зона ответственности и то как вы пользуетесь сервисом. Вы можете сделать его абсолютно безопасным, а можете открыть всему миру и потом удивляться и валить все на других
7. Про софт. Вы хотите такой софт как запросили, а подумать что такое ПО не будет никогда круче и удобнее чем весь тот софт что уже написали компании вроде JetBrains? Польщуйтесь с другом удобным софтом, желательно одинаковым, ну и вспомните что для совместной работы как вы описали всегда есть RDP, TeamViewer и другие решения. И не надо выходить из зоны комфорта. Все "Realtime Team IDE" профанация.
8. Чтобы сократить Time to Market в этом мире уже давно приняли решения пользоваться Third Party Vendors. Если вы хотите делать все самостоятельно ты вы уже давно опоздали.
9. Если вы хотите запустить что-то свое для удобства как on-Premise Git server, on-Premise online IDE и т.п. то подумайте вот о чем .... с текущим уровнем понимания я могу вам гарантировать что вы не смодете обеспечить безопасность, доступность и сохранность всего что запустите и когда это встанет проблемой все-равно вернетесь к вендорам
Алексей, сразу видно команду без плана действия на голом энтузиазме. Для вас всегда есть такие инструменты как онлайновые sandbox, gist, jsfuddle и миллион других сервисов.
Иван, да. вы пока не знаете что такое канал, как узнать его пропускную способность и какую нагрузку на него дает ваша загрузка. Так что прочитайте матчасть сначала)
DevMan, процессор только тут скорее всего вообще не при делах) у меня есть на php , проекты, гоняющие много данных. Процессор спит почти, а память под завязку
Иван, нужен широкий канал и желательно несколько сетевых интерфейсов (в AWS это ENI). Процессор вас нафиг не нужен, а что до памяти - зависит от того сколько у вас одна загрузка потребляет
