Cześć!

Czas to pieniądz. Truizm znany każdemu. Każdy rozumi, każdy wi. W dzisiejszych czasach chmura przestała być “buzz word”. Kiedy ktoś mów “używam Azure”, “używam AWS” raczej kwitujemy to wzruszeniem ramion. No OK. Cechą rozwiązań wchodzących w stan dojrzewania jest to, że zaczynamy rozumieć ich właściwe cechy, charakterystykę. W “Czarnoksiężniku z Archipelagu” Ursula Le Guin napisała, że jak poznamy czyjeś prawdziwe imię to zyskujemy nad nim kontrolę.

Chmura ma kilka imion, jedno z nich to pieniądz. Podstawą jest to, że płacimy za każdą sekundę obliczeń, przesyłu danych. Nic nie jest za darmo. Też truizm. Doskonale wiemy, że im więcej używamy chmurę tym więcej zapłacimy. Poza oczywistym faktem są też inne, które na początek nie widać. Sama kwestia kosztu poszczególnych usług oraz ich cech charakterytycznych będzie wpływać na naszą architekturę. Jakiś czas temu życie było prostsze. W zasadzie do dyspozycji mieliśmy 3 bazy danych na krzyż. Były płatne, były open source. Jak nasza firma była oparta o .NET braliśmy MSSQL, płaciliśmy i wio. Jak mieliśmy SAPa to braliśmy Oracle, jak chcieliśmy taniej to MySQL albo MSSQL. Jak chcieliśmy dokumentową bazę to Mongo lub RavenDB.

Szczególnie jeśli baza była Open Source to programista decydował. Bo np. się na tej konkretnej bazie znał, albo chciał sobie CV usprawnić. Teraz w chmurze nawet za technologie Open Source musimy płacić. Wybór staje się bogatszy ale i trudniejszy.

Przykład z mojego projektu. Używamy AWS - najchętniej chcielibyśmy używać DynamoDB ( baza klucz wartość, CosmosDB z Azure to jej klon) do wszystkiego w warstwie zapis. Nie używamy jej jednak wszędzie, głównie do konfiguracji i operacji, które muszą być szybkie. Do biznesowych danych używamy AuroraDB - rozproszonej bazy relacyjnej. Dlaczego? Bo jest tańsza, a jest wystarczająca do naszego problemu. Dlatego też decyzje architektoniczne nie mogą być już podejmowane według wygody i widzimisie programistów, ale też suchych wyliczeń w Excelu.

Innym aspektem jest wydajność. Coś co jest spychane bardzo często w naszych projektach na koniec. Powiedzmy, że 1 sekunda na odpowiedź z naszego endpointa jest “good enough”. Teraz przyjmimy, że niespecjalnie przykładaliśmy do tego wagi i nasz request trwa 10 sekund. Jeśli ten problem dotyczy większości naszych zapytań to okazuje się, że możemy płacić 10 razy więcej za nasze usługi niż powinniśmy. To często dla startupu typu SASS może się okazać języczkiem u wagi - być albo nie być. Zatem czy na pewno powinniśmy wydajność zachowywać na koniec?

Jeszcze inna ciekawostka. Warto dobrze umieć to przeliczać, bo np. w AWS możemy na lambdę/funkcję ustalić zasoby. Im więcej zasobów przeznaczymy tym więcej zapłacimy za czas procesowania. Ale! Okazuje się, że często bardziej się opłaca przydzielić więcej zasobów, bo przetworzą zapytanie krócej i w ostatecznym rozrachunku zapłacimy mniej.

Obstawiam, że już niedługo dobrze płatnym zawodem bedzie konsultant z liczydłem, któremu powiemy co potrzebujemy w naszym systemie, a on wypluje nam optymalny kosztowo zestawa usług chmurowych. A może już takim jest?

A jakie są Twoje doświadczenia w tym zakresie?

Przypominam też o środowym webinarze - https://www.meetup.com/dev-LDZ/ (116 osób zapisanych na ten moment - o matko!)

Pozdrawiam Oskar

p.s. W zeszłym tygodniu odbyła się konferencja MSBuild. Oto garść linków z niej:

• podsumowanie ogólne - https://news.microsoft.com/build-2020-book-of-news/,
• podsumowanie typowo dla programistów - https://fuqua.io/blog/2020/05/microsoft-build-2020-highlights-for-net-developers,
• .NET 5 coraz bliżej - https://devblogs.microsoft.com/dotnet/announcing-net-5-preview-4-and-our-journey-to-one-net/,
• i to co mnie najbardziej jara C#9 i nowości czyli immutability, dekonstrukcja obiektów itd. - https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/.