Stary Świat
W „starym świecie” sprzętu on-premise fizyczne serwery były kluczowym elementem infrastruktury IT. Z warstwą wirtualizacji lub bez niej, były one ograniczone liczbą rdzeni CPU, transferem danych z dysków twardych i pamięci RAM. Moc maszyny stanowiła twardą granicę wszelkich optymalizacji wydajności, można było dość łatwo nawigować między optymalizacją kodu aplikacji a zakupem dodatkowego sprzętu. Nie było ryzyka eksplozji kosztów, ponieważ wszystkie inwestycje zostały poczynione z wyprzedzeniem.
Nowy Świat
Nowy świat jest nieco inny. Centra danych z tysiącami serwerów nadal istnieją, ale nie są dostępne dla użytkownika końcowego. Wszystko istnieje w nowej warstwie zwanej chmurą, gdzie fizyczny sprzęt wydaje się całkowicie oderwany od wirtualnego środowiska chmury. Możesz tworzyć, upuszczać, skalować i przywracać swoje usługi, maszyny i aplikacje za pomocą prostego interfejsu internetowego. Rachunek przyjdzie później.
Ukryta różnica
Główni producenci rzadko mówią o tym, że fizyczne maszyny wciąż tam są, a dodatkowa warstwa oprogramowania nie pomaga przyspieszyć systemu.
Przypadek #1
Nasz zespół przekonał się o tym na własnej skórze, gdy przeprowadziliśmy migrację fizycznego centrum danych naszego klienta telekomunikacyjnego do platformy Azure, stwierdzając duże spadki wydajności, mimo że specyfikacje naszych maszyn wirtualnych były lepsze niż w przypadku oryginału, z którego przeprowadziliśmy migrację. Po dokładniejszych testach odkryliśmy, że dyski twarde SSD podłączone bezpośrednio do płyty głównej serwerów zapewniały prędkość odczytu/zapisu na poziomie ponad 1 GB/s, podczas gdy dyski podłączone do sieci Azure mogły osiągnąć maksymalnie 250 MB/s. Było jeszcze wiele podobnych niuansów, które wymagały optymalizacji naszego kodu i pewnych zmian w architekturze systemów. Ostatecznie udało nam się rozwiązać wszystkie wąskie gardła bez ponoszenia dodatkowych kosztów, przenosząc niektóre usługi do PaaS. Niemniej jednak pokazało nam to drogę do nowego świata, w którym każde pole wyboru w procesie konfiguracji Azure może skutkować dodatkowymi wydatkami rzędu dziesiątek tysięcy euro rocznie.
Nowe podejście do architektury
Celem dużych dostawców jest zarabianie pieniędzy i starają się ułatwić klientom wydawanie pieniędzy. Skalowalność ich systemów jest elastyczna do pewnego stopnia. Firmy muszą inwestować w usługi o większej mocy lub starać się projektować swoje rozwiązania, dostosowując się bardziej do systemu rozliczeniowego dostawcy, niż do fizycznych możliwości platformy
Przypadek #2
Budując od podstaw nową platformę Azure Managed Services dla innego klienta telekomunikacyjnego na platformie Azure, początkowo chcieliśmy przenieść nasz wypróbowany i istniejący framework ETL na nową platformę. Doświadczenie sugerowało jednak, że mogą istnieć lepsze i bardziej optymalne sposoby zaprojektowania hurtowni danych. Zbadaliśmy wydajność i koszt PaaS Azure SQL DB vs Azure Synapse Data Warehouse vs SQL Server oparty na maszynie wirtualnej. Odkryliśmy, że Synapse faktycznie wykorzystywał wiele małych instancji SQL Server zarządzanych przez framework Synapse, co było dość ograniczające. Z drugiej strony Azure SQL DB zaczął być wystarczająco wydajny na poziomie P6, co było dość kosztowne dla wielu instancji bazy danych, ponieważ potrzebowaliśmy Staging, DWH i Operational Data Store. Metodą prób i błędów znaleźliśmy pewne obejście, które pozwoliło nam połączyć wiele baz danych Azure SQL DB niskiego poziomu z platformą ODS, która ładowała pliki z magazynu BLOB i wykonywała przetwarzanie oparte na języku T-SQL przy bardzo niskich kosztach. Następnie przesłaliśmy dane do gwiezdnego schematu Azure SQL DB w celu raportowania. W ramach naszej struktury ustanowiliśmy reguły, które skalują serwery w dół, gdy nie są używane (poza godzinami pracy).
Podsumowanie
Nowy świat „wszystkiego w chmurze” jest już dość dojrzały, a firmy rzadko biorą pod uwagę rozwiązania lokalne. Zgadzamy się z tym trendem, jednak kluczowe jest zrozumienie tego, co dzieje się pod maską rozwiązań chmurowych i zderzenie tego z modelem kosztowym proponowanym przez dostawcę. Pozwala to zaprojektować optymalną architekturę zarówno pod względem wydajności, jak i kosztów.