А вот по моему скромному мнению — главный элемент умного города это интероперабельность всех систем умного города. Первыми об этом заговорили англичане выпустив первые стандарты (BSI PAS 182_2014). Европа очень активно подхватила и сейчас лидирует. В прошлом году у нас в стране даже перевели первую порцию европейских стандартов под статусом предварительных национальных стандартов (как пример ПНСТ 441-2020). Но после общения с людьми из команды технического комитета «Кибер-физические системы» у меня сложилось впечатление что стандарты недопоняты. А один из основополающих смыслов стандартов в том, что все системы должны строится как интероперабельные на основе модели связанных данных. У нас же об это не думает ни кто. Наши предварительные стандарты видимо загнутся как не востребованные. А жаль, считаю что начинание в рамках цифровой трансформации было отличное и я бы даже сказал удивительное! Но у нас в стране очень умеют правильные начинания превращать в формальную ерунду.
Москва активно движется по чек-листу как завоевать больше баллов в рейтинге умных городов. Отсюда в т.ч. пилоты по беспилотникам и по AR-очкам для полицейских. Работа по открытым данным в Москве поражает масштабом. Но когда об этом зашел разговор в ДИТ, то там признались, что эти открытые данные маловостребованы. А для чего они нужны? А они нужны чтобы поставить в чек-листе галочку и сделать Москву «умней». А по стандарту открытые данные должны быть в машинопонимаемом формате RDF/OWL, чтобы системы Умного города могли самостоятельно ими пользоваться и предоставлять полезные сервисы населению. Вот когда будут востребованные населением системы, основанные на модели связанных данных и открытые данные в машинопонимаемом формате, вот тогда открытые данные и будут востребованы.
Все системы «Умного города» в Москве строятся и пилотируются как локальные. А вот в Европе начали с того, что создали открытую платформу на основе контекстного брокера сообщений и модель связанных данных которые используют все участники проекта. И получается что каждый участник создает свою независимую систему, которая изначально способна к взаимодействию с другими системами.
1. А разве микросервисы не позволяют автоматически масштабировать сайты? Вроде оркестрация контейнерами вполне рабочая штука и для микросервисов.
2. Да есть даже лозунг «каждому микросервису по своей базе данных». Но разве нельзя создать микросервис который может собирать данные по всем бизнес-каналам, обращаться к изолированным наборам данных и выполнять анализ больших данных в рамках единой базы данных? В чем преимущество serverless?
3. Я понимаю преимущества serverless при работе с такими IoT-устройствами как коммунальные счетчики передающие показания раз в месяц в один и тот же день. Но даже в этом примере на микросервисах можно вполне держать один докер и масштабировать его при увеличении нагрузки. Конечно если есть 10 счетчиков передающих данные раз в месяц то держать serverless в облаке будет конечно выгодней. А если число счетчиков исчисляется десятками или сотнями тысяч то далеко не факт.
Я понимаю, что serverless позволяет быстрей стартовать разработку и быстрей разрабатывать. Я понимаю что serverless нельзя превратить в монолит, даже если очень захочется. Я понимаю преимущества работы по редким событиям. Но не понимаю чем они лучше для высоконагруженных систем и почему их рассматривают как серебряную пулю в решении проблемы спагетти-интеграции присущую ESB и микросервисам. Почему связи между функциями не рассматривают как спагетти-интеграцию?
Москва активно движется по чек-листу как завоевать больше баллов в рейтинге умных городов. Отсюда в т.ч. пилоты по беспилотникам и по AR-очкам для полицейских. Работа по открытым данным в Москве поражает масштабом. Но когда об этом зашел разговор в ДИТ, то там признались, что эти открытые данные маловостребованы. А для чего они нужны? А они нужны чтобы поставить в чек-листе галочку и сделать Москву «умней». А по стандарту открытые данные должны быть в машинопонимаемом формате RDF/OWL, чтобы системы Умного города могли самостоятельно ими пользоваться и предоставлять полезные сервисы населению. Вот когда будут востребованные населением системы, основанные на модели связанных данных и открытые данные в машинопонимаемом формате, вот тогда открытые данные и будут востребованы.
Все системы «Умного города» в Москве строятся и пилотируются как локальные. А вот в Европе начали с того, что создали открытую платформу на основе контекстного брокера сообщений и модель связанных данных которые используют все участники проекта. И получается что каждый участник создает свою независимую систему, которая изначально способна к взаимодействию с другими системами.
Этот фреймворк очень хорошо смотрится в рейтинге
https://www.techempower.com/benchmarks/
2. Да есть даже лозунг «каждому микросервису по своей базе данных». Но разве нельзя создать микросервис который может собирать данные по всем бизнес-каналам, обращаться к изолированным наборам данных и выполнять анализ больших данных в рамках единой базы данных? В чем преимущество serverless?
3. Я понимаю преимущества serverless при работе с такими IoT-устройствами как коммунальные счетчики передающие показания раз в месяц в один и тот же день. Но даже в этом примере на микросервисах можно вполне держать один докер и масштабировать его при увеличении нагрузки. Конечно если есть 10 счетчиков передающих данные раз в месяц то держать serverless в облаке будет конечно выгодней. А если число счетчиков исчисляется десятками или сотнями тысяч то далеко не факт.
Я понимаю, что serverless позволяет быстрей стартовать разработку и быстрей разрабатывать. Я понимаю что serverless нельзя превратить в монолит, даже если очень захочется. Я понимаю преимущества работы по редким событиям. Но не понимаю чем они лучше для высоконагруженных систем и почему их рассматривают как серебряную пулю в решении проблемы спагетти-интеграции присущую ESB и микросервисам. Почему связи между функциями не рассматривают как спагетти-интеграцию?