Говорих с приятел консултант преди няколко седмици. Основната му роля в момента е работа по проекти за преместване на бази данни на SQL Server в облака (AWS и Azure) и на мас. Неговата история ми напомня за проекти отпреди години на P2V проекти, при които физическата памет и ядрата може просто да бъдат съпоставени с виртуална памет и виртуални ядра и след това да даде на администратора на VMWare задачата да прегледа това въз основа на потреблението, в противен случай ползите от виртуализацията бяха премахнати.
Е, при облачните миграции твърде често все още се прилага същата методология за простота и бързина, но шокът идва, когато сметките за облачни абонаменти се появят. .
По някаква причина често има нежелание собствениците на проекти да прегледат предварително текущото използване, потребление и производителност и точно да предвидят размера, който е необходим за миграция на облак. Проблемът с решаването на проблема след миграцията е, че има повече риск, повече гасене на пожари и колко бързо можете да направите това, докато сметките все още идват всеки месец.
Така че с нетърпение очакваме да чуем какво имат да кажат Денис О’Съливан и Питър О’Конъл на 14 април с тяхното уеб излъчване на живо:Точно оразмеряване и мащабиране на вашата облачна база данни.
