Простой перенос инфраструктуры в облако не сделает унаследованные приложения гибкими, масштабируемыми и интеллектуальными, пишет генеральный директор операционной платформы данных на основе искусственного интеллекта Splice Machine Монти Звибен на портале eWeek. Как только вы перешли в облако, включается счетчик.
В 2019 г. многие CIO занимались переходом на различные облачные сервисы, модернизацией заказных приложений и инвестициями в работу с данными. Ведь новые ИТ — это средство удовлетворения потребностей в обслуживании любого, кто вступает в контакт с онлайновыми активами компании.
Таким образом, сейчас осуществляется переход на цифровые технологии или цифровая трансформация. Однако, как и в случае с другими важными начинаниями, следует соблюдать осторожность и избегать некоторых ошибок, которые легко не заметить.
1. Переход в облако без четкого плана
Простой перенос инфраструктуры в облако не сделает унаследованные приложения гибкими, масштабируемыми и интеллектуальными. Как только вы перешли в облако, включается счетчик. Компании, поспешившие с переходом в облака, завершили первую фазу своих проектов и обнаружили, что операционные расходы возросли, потому что стоимость облачных вычислительных ресурсов для приложений, которые обычно используются в онлайновом режиме, превысила экономию на оплате труда. Следует предварительно сформулировать цель, которой вы стремитесь достичь, перенося инфраструктуру в облако.
2. Переписывание унаследованных приложений с чистого листа
Важнейшие приложения работают медленно, потому что объем данных, который они должны обрабатывать, стремительно возрос. Главное в том, что объем и скорость онлайновых транзакций требуют, чтобы эти приложения были интеллектуальными и функционировали в реальном времени без вмешательства человека.
Но нет необходимости переписывать их с чистого листа. Сохраняя приложение в целости и сохранности и создавая для него современную основу, вы сохраняете интерфейс и бизнес-логику, которые являются секретным оружием вашей компании, и избегаете втягивания в дорогостоящий, длительный и рискованный проект.
3. Отказ от СУБД на базе SQL в пользу NoSQL
Прежде чем заменять серверную СУБД на базе SQL на СУБД типа NoSQL с целью модернизации приложения, примите во внимание, что вы можете подвергнуться значительному риску, а масштаб проекта может заметно увеличиться. Отсутствие полной поддержки SQL в NoSQL-СУБД потребует переписывания значительного объема кода, а найти специалистов по NoSQL не так легко. Кроме того, NoSQL-СУБД обычно прекрасно справляются с короткими операционными запросами, но их производительность при обработке аналитических запросов может быть низкой и не удовлетворяющей потребностям приложения.
4. Перенос работы с данными за кулисы
Специалисты по данным, инжинирингу данных и разработке приложений просто не обладают достаточно глубокими знаниями бизнеса, чтобы использовать модели в производственных условиях. Наука о данных — коллективный вид спорта, которым должны заниматься представители всех трех специальностей в тесном сотрудничестве с теми, кто хорошо знает бизнес-процессы, чтобы создать интеллектуальное приложение, которое принесет ощутимые бизнес-результаты.
