реляційні сервіси
це хмарні нативні сервіси під хмарні RDS чи, що Ви мали на увазі?
Ви вважаєте, що бізнес, особливо в IT, не розуміє ризиків рівня вуха/навушники?
Думаю, що в більшості випадків достатньо добре розуміє, мізерний відсоток, що залишається, справді потрапляє під Вашу класифікацію ) і не дуже цікавий, як клас.
так, це закони ринкової економіки, хмарні тенденції в тому числі і народилися, як варіант оптимізації існуючих рішень і це добре, що Ви, як експерт, відверто зазначаєте, що певні інженерні позиції під хмари потребуватимуть нових знань/практик — це лише один з наслідків, а не пункт зі списку першочергових цілей хмар.
Під «економією в IT» я трохи інше мав на увазі. Є системоутворюючі процеси та інженери, які здатні стратегічно страхувати прогнозовані ризики таких процесів. Коли починається економія в цьому сегменті, починаються історії виду «ми будемо сильно грати у футбол, як Манчестер Сіті», ну, ок, ось вам стадіон, поле, м’яч — грайте. І тут починається саме цікаве, як то кажуть.
так, аналіз компанія проводила, але вважаю, що не був дотичний до аналізу в тій мірі, щоб мати можливість відповісти конкретніше на Ваше запитання.
Базове — збільшити відмовостійкість рішень і cloud виглядає десь прогнозованим варіантом.
персонал
у матеріалі @Illya Reznykov дійсно згадується в контексті, який провокує тригернути.
Економія на «ІТ-персоналі» для недалекоглядного бізнесу буде, як правило, завершуватися протилежним.
«кадри таки багато чого вирішують» — банально, але по суті вірно для різних бізнесів, не лише для IT, але так само вірно, що при трансформації on-premise ---> cloud ризики для чистих on-premise БД-ів, безумовно, десь виростають, як мінімум, проект/компанія починає качати інший технологічний напрямок.
Проблеми з вашою конкретною бд він вирішити ніяк не допоможе
так, це не зона відповідальності інфраструктурного провайдера, думаю, що це кейс експертів, які прокачуватимуться у нас при міграції з MS SQL, наприклад, в RDS, etc.
мігрувати сервер БД + систему у хмару, чи створювати гібридну конфігурацію
так більшість розробок отримають таке заключення.
В проектах, до яких був дотичний безпосередньо, схиляюся до варіанту:
* Rearchitect, це вже про переробку застосунку, тобто спочатку змігрувати в хмару як є, а потім крок за кроком функціонал забирати від MS SQL Server і покривати сервісами із використанням хмарних рішень.
архітектори в процесі, першопричина — підвищення відмовостійкості, але масштабування — це додатковий серйозний аргумент у хмарах, безумовно. Хмарні вендори підсажують на свої сервіси, тому в базовому концепті трансформації черги будуть також їхні при всій повазі до RabbitMQ чи Kafka, такі технології залишаться можливо в якихось кастомних випадках, але в основі хмарного концепту вони будуть відсутні.
основна проблема загострилася 24.02 )
Покласти реалізацію під MS SQL — це треба вміти, у цієї штуки широкі можливості рихтовки факапів на рівні логіки, ну, або на старті помилково вибрати цей тип БД, коли він, наприклад, не зовсім підходив під проект.
Першочергова причина напрямку в хмари — це підвищення відмовостійкості + хмарні рішення на сьогодні все-таки в основних тенденціях, потрібно нарощувати експертний потенціал в цьому напрямку.
безумовно, але є також мета оцінити кожен з проектів під трансформацію в чисто хмарне рішення.
Є попередні напрацювання, бачення, але цікавить досвід, думка, а можливо і просто лінійне викладення, як в когось відбувалася міграція з монолітного потужно прокачаного MS SQL в той же AWS.
Дякую за статтю.
Якщо стикалися, то на вскидку, які етапи виправдані для оптимізації (фінансової/інфраструктурної/безпекової) при переході в хмару (AWS) з монолітної реляційної БД (MS SQL), яка навантажена і нативними внутрішніми інструментами виду Replication, Linked Servers, SSIS, Service Broker, etc., і ззовні різними API через connectionString, містить досить багато tables/views, часто дані обробляються сіквельними job-ами, одним словом, нормальне таке монолітне використання БД MS SQL.
це ринок, «перекупщики» беруть на себе певні ризики та і прибутки вважаю навряд чи в них з розряду «прикурити
Держава могла, безумовно, раніше дати інфу про зняття мита.
«Нова Пошта» може стати трохи лояльнішою по вартості доставки, не цяцьки для розваг в цьому випадку їдуть, але знову ж таки ринок і в них свої ризики, дай їм Бог доставити все, що замовили, може з часом якийсь дисконт для українців на такі штуки і зроблять, але це комерційна кантора зрештою. «Укрпошта», де ви? Доречі, «Укрпошті» по Україні респект, реальний конкурент НП.
Я не виправдовую «перекупщиків», вони просто явне вираження того, що відбувається з людьми фактично щоденно в більш завуальованих формах.
так, в кого є можливість, наприклад, знайому/друзі в Європі, юзають саме такі кейси: до найближчого відділення НП рейсовим бусом, а далі по тарифам перевезень територією України, оскільки ціна від НП з Європи могла би бути трохи скромнішою, особливо на такі штуки.
дякую, суттєвий акцент.
Пару днів назад НП відзвонилася мені.
Дали підтвердження, що мита не буде, пояснили, як оформити замовлення в «Особистому кабінеті», оскільки під EcoFlow там ще не допиляли (не перевіряв ще) і я спитав про вартість доставки.
Нажаль, дійсно не дешево. Орієнтовно $6 за 1 кг. ваги і якщо врахувати, що зарядні станції таки важкенькі... і це по ходу без вартості доставки постачальника на склад НП. Одним словом, навіть одну на 7 кг. дешевше відправити через колегу з Іспанії рейсовим автобусом, ніж через НП, але НП — це все таки організація процесу, тому є сенс таки заплатити «драконівську вартість» (головне, щоб ще не докинули зненацька до вартості по ходу діла, коли станції уже приїдуть до них на склад).
не да, можна, в перекущиків на OLX і на всіх інших торгових площадках, якщо «докинути грошей»
$6 за кг. ваги десь по доставці і
Дякую за детальну інформацію.
коли було зроблено замовлення і якої моделі?
яка вага EcoFlow? яка вартість доставки?
дайте, будь-ласка, якесь мило в ПП, дому що на DOU у Вас реєстрація по неіснуючому вже e-mail-у, а LinkedIn я не використовую
Ви встигли ) Наразі, в більшості торгових площадок:
Pre-order
CalendarTo be expected: End of December 2022
що співпадає з орієнтовними термінами відвантажування зі складів виробника
не спадало на думку, що «сіньор менеджер», ну, якщо це не колишній/діючий «ефективний менеджер», як ніхто вміє оцінити ресурсозатрати/результат, не варто це плутати із супротивом.
Тако ж є різниця між:
— стадний супротив змін. Це сумна історія для вашого проекту чи як Ви вживаєте дивне означення «програми», таке враження, що Ви випадкова людина в IT;
— стадне сприйняття змін. Лише трохи краще, але залежить чи є ті, хто вибивається із стада і надає контраргументами можливість адекватно валідувати на різних етапах оптимальність рішень, розвитку чи напрямку руху;
— гібридний варіант, в бльшості випадків це така собі квазі демократична історія, коли сам процес стає важливішим за реальний результат, але бувають винятки.
Так ти ж наче всі варіанти описав і всі вони наче «так собі»... Тому що так воно і є, бізнес/компанії рухають лідери, не прикормлені «зірочки» за вислугу літ чи ще за якимось критеріями, як описано в статті, а реальні драйвери, які вміють приготувати якісне пальне для розвитку з базових засад Data Driven Company, згаданих в статті і не лише з DDC.
DDC — це про аналітику даних з метою суттєвого півищення оптимальності рішень на основі фактів і однією ногою ця історія вже в ШІ.
Эвангелістам різноманітних Agail-альтернатив приготуватися )
Автору за статтю подяка.