Вот уже больше 3-ех лет я активно работаю на облачной платформе Amazon. Сегодня я хотел бы в этой небольшой статье рассмотреть интересный момент – вопрос надежности. В последнее время в сторону Amazon по этому поводу поступает много нареканий. Вероятнее всего, все хотя бы краем уха слышали о многочисленных проблемах с доступностью сервисов за последний год.
Казалось бы, что тут обсуждать? Все понятно: Amazon – г..но, а мы с вами все Д’артаньяны. Но я решил взглянуть на это под немного другим углом. Чаще всего, при разработке enterprise продукта никто не задается вопросами следующего характера:
- А что будет, если временно пропадет сеть к серверу БД?
- Что если сам сервер БД перестанет быть доступным?
- Как быть в случае дисковых ошибок на сервере приложений или же сервере БД?
- Куда деваться, если диски “полетели” глобально?
- Что предпринять, если у нас в дата-центре пропал интернет?
Большую часть разработчиков такие вопросы попросту не волнуют – ведь сервер БД стоит неподалеку (он такой родной и близкий, что не должен поломаться), да и с дисками проблем до этого не было, ну а с интернетом и сетью разве вообще бывают проблемы? 😉 Максимум, этими вопросами интересуются администраторы, да и то не факт, что всерьез занимаются ими и тестируют свои наработки на практике. Причин много и в основном все упирается в бюджет и технические навыки.
Дальше – больше. Многие разработчики не задумываются даже над доступностью внешних и внутренних сервисов при написании кода. Просто вызвал метод и готово! Это же так просто! Зачем морочить себе голову обработкой исключений, связанных с доступностью ресурсов, или придумывать сложные стратегии для обеспечения надежности? Глупости какие!
Так вот, Amazon в этом плане сразу настраивает на то, что все может перестать быть доступным в любой момент времени. И база, и диски, и сеть, и любой внешний сервис. Причем, предлагается множество интересных архитектурных и инфраструктурных решений, которые могут решить вышеуказанные проблемы. Это не всегда просто! Это не всегда легко применимо в чистом виде! Но зато это работает!!!
С Amazon для вас будут практически обязательными понятиями data backups, data replication, load balancing, recovery setup и т.д. Благодаря им, ваш продукт будет продолжать работать и зарабатывать вам деньги практически при любой проблеме у Amazon. Что будет при таких же проблемах с вашим приложением? Вероятнее всего, на восстановление работоспособности, в лучшем случае, у вас будут уходить часы или дни. И это еще неплохой вариант. Некоторые продукты могут исчезнуть навсегда, потеряв все данные.
А тестировали ли вы такие ситуации? Это не всегда легко сделать, потому что дорого, затратно по времени, да и никого не интересует. В Amazon для подобного тестирования созданы очень благоприятные условия. Вы можете эмулировать разного рода проблемы и добиваться должного уровня надежности и устойчивости для вашего приложения.
В итоге, потенциальная ненадежность Amazon играет нам только на руку в долгосрочной перспективе. Мы не превращаемся в “оптимистичных” разработчиков, код которых работает до первой проблемы. А как обстоят дела в вашем проекте?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Обсуждение (
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
0)