ASM i ARM Storage Accounts

Tak wypadło z moją krótką wciąż karierą Azurową, że załapałem się na sporo różnych zmian, które do teraz mają wiele konsekwencji w usługach i potrafią stanowić nie lada irytację.

Jedna z tych rzeczy to “stare” (tzw. Classic) i “nowe” Storage Accounts. Jasna cholera mnie bierze, że te konta są w dwóch “zakładkach” i stare nie mają po prostu przycisku “Migrate”. Może za mało wiem o tym co tam się z tyłu dzieje, ale to jest okropnie upierdliwe. Na szczęście jest mądry człowiek prowadzący bloga, który opisał jak to zrobić. Starczy podobno starczy trochę pomachać PowerShellem, o tak.

Warto sprawdzić, ja z pewnością to zbadam i dam znać co i jak.

Szybsza baza, to lepsza baza!

No takie newsy to ja mogę czytać. Piłka jest krótka – Microsoft postanowił dać noworoczny prezent wszystkim, którzy odpowiedzialni są za kontrolowanie i optymalizację obciążenia baz Azure SQL oraz optymalizację kosztów, które one generują.

Od dziś podwojono wydajność zapisu na wszystkich tierach usługi Azure SQL, a bardziej wymagające systemy, opierające się o tiery Premium dodatkowo zyskują podwojoną wydajność odczytu. I wszystko w tej samej cenie, co wcześniej.

Można? Można 🙂

Źródło: https://azure.microsoft.com/pl-pl/blog/azure-sql-database-is-increasing-the-read-and-write-performance/

Ułatwienie w Storage Queues

Takie proste, a takie fajne. Trick polega na tym, że do tej pory po włożeniu wiadomości do kolejki (AddMessage), trzeba było ją ponownie odczytać (GetMessage), żeby otrzymać jej “pop receipt”. Teraz odpowiednie property obiektu CloudQueueMessage jest ustawiane już przy wkładaniu wiadomości do kolejki. Tak więc od razu mamy możliwość przeprowadzania zmian na wiadomości w kolejce czy jej usuwania z kolejki (ogólnie – robienia wszystkiego do czego pop receipt jest potrzebny).

Niby takie nic, ale jak się spojrzy w kod, że jest teraz czysty, elegancki, bez nic nie wnoszących linijek. W dodatku zmiana wprowadzona przy naciski u i usilnych żądaniach community.

Przykład tutaj. Byle tylko więcej funkcjonalności proponowanych przez community.

A czy Ty zmigrowałeś swoje funkcje?!

Azure Functions weszło jakiś czas temu w GA, więc zespół App Service’owy chce się pozbyć wersji preview (<1.0). Oficjalnie ogłoszono je jako deprecated i zapowiedziano proces usuwania wersji 0.x, który rozpocznie się 1 lutego 2017. Na szczęście, zakładając, że w tych 0.x nie używamy funkcjonalności, które nada są w preview (np Powershella czy F#), nasze funkcje zostaną po prostu automatycznie podniesione do wersji 1.0. Jeśli chcemy pozostać przy jakiejś “starej” wersji – kolejne wprowadzały braking changes, więc może tak być, że komuś będzie na tym zależało – należy sprawdzić krótkie FAQ (pod linkiem na dole) albo zgłosić się do teamu (adres też w treści źródła).

Ustawienie wersji na szczęście jest per Function App, więc jeśli używamy stagingu przepuszczając nasz kod najpierw przez “pośrednią” usługę, to możemy najpierw sprawdzić efekt zmiany do 1.0 na tej wersji.
Co także jest ważne – w razie problemu da się wrócić do wersji preview (0.x) przez ustawienie FUNCTIONS_EXTENSION_VERSION.

Wygląda na to, że zespół od funkcji całkiem dobrze przemyślał kwestię migracji i ewentualnych jej konsekwencji dając użytkownikom pewien wachlarz możliwości do sprawdzenia jak zachowa się ich usługa.

Źródło: Azure App Service Team Blog

Nowy blog na horyzoncie!

Nawet nie na horyzoncie tylko już całkiem blisko, na wyciągnięcie ręki. RSSy doniosły mi dziś o pierwszym wpisie na nowym blogu w serwisie MSDN Blogs – “Architekci Chmury. Jak zbudować chmurę dobrze.” Blog otwierany przez plejadę gwiazd 😉 z polskiego oddziału Microsoft.

Części autorów miałem przyjemność posłuchać na żywo, a z publikacjami większości miałem jakąś styczność. Zapowiada się bardzo ciekawie – raz, że grono doświadczone, dwa, że z racji miejsca pracy ma ułatwiony dostęp do grup produktowych i zna mnóstwo interesujących, a jak wspomniał w intro Michał, niezbyt dobrze udokumentowanych, myków i trików.

Blog zasubskrybowany, już niecierpliwie czekam na pierwsze wpisy z mięskiem.

DevOps Cognitive Bot Assistant?

IBM organizuje wśród swoich pracowników wewnętrzne konkursy, które mają podnieść kreatywność, pobudzić pęd ku innowacjom i w efekcie naturalnie przyciągać klientów do firmy. Nie byłoby w tym nic szczególnie niebywałego, ale jeden z projektów, który znalazł się w ścisłym gronie finalistów jednego z konkursów brzmi bardzo interesująco:

Cognibot is a ChatBot-driven conversational experience with which DevOps users solve complex middleware problems using natural language questions. Users get only the data they need, not the full, data heavy-dashboard. This way, they can dig into the institutional knowledge of the organization and reduce downtime.

Infrastructure as Code, wersjonowanie, automatyzacja, continuous integration… ale bot? Koncepcja brzmi bardzo interesująco, ale aż prosi się o więcej szczegółów. Za tydzień ma się pojawić video z twórcami najlepszych projektów, liczę, że zobaczę tam coś więcej.

Źródło: https://www.ibm.com/blogs/cloud-computing/2017/01/contenders-connect-cloud-cognitive-build/