Kilka tygodni temu rozmawiałem ze znajomym konsultantem. Jego główną rolą w tej chwili jest praca przy projektach przenoszenia baz danych SQL Server do chmury (AWS i Azure) oraz na masowych. Jego historia przypomina mi projekty sprzed lat dotyczące projektów P2V, w których pamięć fizyczna i rdzenie mogą być po prostu mapowane na pamięć wirtualną i rdzenie wirtualne, a następnie dając administratorowi VMWare zadanie sprawdzenia tego w oparciu o zużycie, w przeciwnym razie korzyści z wirtualizacji zostaną zanegowane.
Cóż, w przypadku migracji do chmury ta sama metodologia jest nadal zbyt często stosowana ze względu na prostotę i szybkość, ale szok pojawia się, gdy pojawiają się rachunki za subskrypcję w chmurze. Ponownie może to być strata pieniędzy, której można uniknąć, w tym przypadku opex, w przeciwieństwie do nakładów inwestycyjnych. .
Z jakiegoś powodu właściciele projektów często niechętnie sprawdzają z wyprzedzeniem bieżące wykorzystanie, zużycie i wydajność oraz dokładnie przewidują rozmiar wymagany do migracji do chmury. Problem z rozwiązywaniem problemu po migracji polega na tym, że istnieje większe ryzyko, więcej gaszenia pożarów i jak szybko można to zrobić, gdy rachunki wciąż przychodzą co miesiąc.
Nie możemy się więc doczekać, aby usłyszeć, co Denis O'Sullivan i Peter O'Connell mają do powiedzenia 14 kwietnia w ramach ich transmisji internetowej na żywo:Dokładne skalowanie i skalowanie bazy danych w chmurze.
