-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #17 from aryll/master
Fixy irytujących elementów
- Loading branch information
Showing
9 changed files
with
243 additions
and
49 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,115 @@ | ||
--- | ||
title: "Azure Solutions Architect Q&A" | ||
categories: | ||
- "Architecture Meetings" | ||
tags: | ||
- "Q&A" | ||
author: | ||
- kaluzaaa | ||
--- | ||
# #azure-solutions-architect Q&A #1 | ||
|
||
Date: 2020-06-04 | ||
|
||
[Add to calendar](https://evt.mx/Rm12eTAB) | ||
|
||
[Meeting link](https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZWYyNTg3N2UtZjA4NC00ZTQ1LTljMzQtODhmZTA0MTI0YzUz%40thread.v2/0?context=%7b%22Tid%22%3a%22cc58971a-0481-4ec0-bf8d-bb2e265db003%22%2c%22Oid%22%3a%22f907c950-2a9a-4012-b163-af67be63b5d6%22%7d) | ||
|
||
[Recording](https://youtu.be/PwWhQFa8Ekg) | ||
|
||
# Agenda | ||
|
||
Proponowane wątki: | ||
1. Praktyczne podejście do adresacji sieci w większej skali: | ||
- Czy stosuje się w praktyce mniejsze podsieci niż VNET /16 i Subnet /24 | ||
- Adresować inaczej niż od 10.0.0.0? Łatwo o nachodzenie przy spinaniu z kimś, jednak stosnkowo łatwiej niż w on-prem o readresację | ||
|
||
2. Mozna jakoś oskryptować stworzenie Organizacji DevOps albo tenanta B2C? Głebiej już się coś daje, a ich (chyba) nie | ||
|
||
3. Ile jest pisania kodu w pracy Solution Architect, a ile klepania YAML np. pod AKS? | ||
|
||
|
||
4. Jakaś dobra praktyka kiedy już nie rozpatrywać smaego ACI i pora przejść na AKS? | ||
Wybór między SF, SF Mesh, AKS dla super prostego mikroserwisu | ||
|
||
|
||
5. Jak praktycznie zacząć projektowanie rozwiązania w Azure (dokumentacja, wybór usług, PoC)? | ||
|
||
6. Jak podejść do tematu architektury dla startupu, który nie wiadomo jak pójdzie i nie do konca da się przewidzieć które funkcjonalności będą kluczowe (= nie mamy liczb, ale zazwyczaj mamy mało hajsu i malo czasu)? | ||
|
||
7. Jaką przyjąc strategię dla serwisów multinenant: kontrola podziału na poziomie bazy danych, tworzenie osobnych kopii serwisu per tenant , inne ? | ||
|
||
# Discussion | ||
|
||
## 1. Praktyczne podejście do adresacji sieci w większej skali: | ||
- W przypadku rozwiązania bez przewidywanych interakcji z innymi sieciami bez znaczenia | ||
- W przypadku koniecznych interakcji: decyzja administratorów sieci | ||
- Bywają przypadki, gdzie VNet musiał być większy niż /16 | ||
- Konieczne jest nauczenie się korzystania z notacji [CIDR](https://pl.wikipedia.org/wiki/Classless_Inter-Domain_Routing) | ||
Kalkulatory podsieci: | ||
http://42.pl/ | ||
http://www.subnet-calculator.com/ | ||
|
||
## 2. Czy można oskryptować tworzenie Organizacji DevOps lub tenanta B2C | ||
- Nie ma takiej potrzeby ze względu, że to pojedyńcze elementy, których się nie powiela | ||
- Możliwość bezpośredniego utworzenia nowego tenanta AzureAD bez potrzeby autoryzacji i podpinania karty: https://account.azure.com/organization | ||
|
||
## 3. Charakterystyka pracy Solution Architecta | ||
- Stosunkowo mało pracy z kodem | ||
- Większość pracy na etapie tworzenia środowisk i migracji | ||
- Tylko 10-20% to praca na środowiskach produkcyjnych - raczej tylko w przypadku dużych problemów | ||
|
||
Najistotniejsze aspekty, o które należy zadbać: | ||
- Uśrednianie projektu do poziomu zespołu tworzącego i utrzymującego | ||
- Budowanie zastępowalności poprzez przekazywanie wiedzy | ||
- Umiejętność przekazywanie do analizy poszczególnych aspektów rozwiązania innym | ||
- Rozwijanie umiejętności miękkich | ||
|
||
[KISS](https://en.wikipedia.org/wiki/KISS_principle) | ||
|
||
[Occam's Razor](https://en.wikipedia.org/wiki/Occam%27s_razor) | ||
|
||
|
||
|
||
## 4. Jakaś dobra praktyka kiedy już nie rozpatrywać smaego ACI i pora przejść na AKS? Wybór między SF, SF Mesh, AKS dla super prostego mikroserwisu | ||
- Jak coś super prostego to po prostu Azure Functions albo AppService (łatwy Continuous Deployment, masa języków programowania, taniość) | ||
- ACI i AppService'y otrzymają sporo nowych funkcjonalności od strony sieci rozwiązujących wcześniejsze problemy z łącznością prywatną | ||
- Service Fabric jest cudowny, jednak ma wysoki próg wejścia by wykorzystać pełnię możliwości - konieczny C# i architektura systemów rozproszonych | ||
- AKS wymaga pilnowania bezstanowości service'ów i minimalizacja użytych elementów (branie gotowych od dostawcy) | ||
- Kluczowe jest nie nastawianie się na konkretną technologię, tylko problemy jakie należy rozwiązać - niekoniecznie mikroserwisy są lepsze od monolitu. Na przykładzie [MongoDB](https://www.youtube.com/watch?v=b2F-DItXtZs) i [Dilberta](https://i.redd.it/8v9fopt6wlx31.jpg) | ||
|
||
|
||
|
||
## 5. Jak praktycznie zacząć projektowanie rozwiązania w Azure (dokumentacja, wybór usług, PoC)? | ||
- Zacząć od porzadnego rozpoznania wymagań, ale z naciskiem na kontekst biznesowy a nie techniczny | ||
- Jeśli nie jest wymagany multicloud/agnostyczność to optymalizować pod Azure (prościej przepisać w razie potrzeby zmiany niż utrzymywać neutralność kosztem optymalizacji) | ||
- Jeśli jest wymagana przenośność to najprościej IaaS | ||
- Uwzględniać w projekcie permanentny stan awarii (tworzyć pętle reconnect itd.) | ||
- VM w Azure są droższe tylko na pierwszy rzut oka, jednak po uwzględnieniu wszystkiego co daje Public Cloud jest on tańszy (wiele replik danych, self-healing, disaster recovery, network, security). TCO chmury powinno być korzystniejsze niż on-prem. | ||
- Korzystanie na produkcji z funkcjonalności, a tym bardziej usług w Preview niewskazanane, chyba, że jesteśmy w stanie uzyskać wsparcie produkcyjne - zawsze najbezpieczniej trzymać się sprawdzonych wersji. | ||
- Optymalizować koszty, chyba że możemy je uzasadnić i wybronić chociażby mniejszym obciążeniem administracyjnym | ||
- Pamiętanie o backupach (i odtwarzaniu), compliance i security | ||
- [Jim Keller: Most People Don't Think Simple Enough](https://www.youtube.com/watch?v=1CSeY10zbqo) | ||
|
||
|
||
## 6. Jak podejść do tematu architektury dla startupu, który nie wiadomo jak pójdzie i nie do konca da się przewidzieć które funkcjonalności będą kluczowe (= nie mamy liczb, ale zazwyczaj mamy mało hajsu i malo czasu)? | ||
- Najlepiej zacząć tanio/prosto od Azure Functions (lub AppService), Service Bus (jeśli potrzebny), jakiś Storage i najtańszy SQL odpowiednio izolowany. jak wypali to potem najwyżej przepisać | ||
- Mentoring stał na GitHub Pages (static + JS), Azure Functions (Python) podpietym do Azure Storage Tables | ||
|
||
|
||
## 7. Jaką przyjąc strategię dla serwisów multinenant B2B: kontrola podziału na poziomie bazy danych, tworzenie osobnych kopii serwisu per tenant , inne ? | ||
- Separacja storage (osobne konta) i DB (SQL Elastic Pool, [Citus](https://github.com/citusdata/citus)) | ||
- Appy wspólne (żeby nie zabić rentowności), ale dbając o odpowiednią uwagę na przepływ wrazliwych danych pod kątem compliance | ||
|
||
## 8. Opinie na temat Azure AD B2C | ||
- Dobre pod kątem compliance i dostepnych providerów w porównaniu do realizowania tego samodzielnie | ||
- Im bardziej Business tym przyjemniej, im bardziej Customer tym zdarzają się konieczne rzeźby | ||
|
||
# Links | ||
|
||
- [Most People Don't Think Simple Enough](https://www.youtube.com/watch?v=1CSeY10zbqo) | ||
- [Migrate your IaaS resources to Azure Resource Manager by March 1, 2023](https://docs.microsoft.com/en-us/azure/virtual-machines/classic-vm-deprecation) | ||
- [Episode 1 - Mongo DB Is Web Scale](https://www.youtube.com/watch?v=b2F-DItXtZs&feature=youtu.be) | ||
- [Occam's razor](https://en.wikipedia.org/wiki/Occam%27s_razor) | ||
- [KISS](https://en.wikipedia.org/wiki/KISS_principle) | ||
- [Nie do końca udokomentowane zakładanie nowego AAD bez konta w Azure](https://account.azure.com/organization) |
80 changes: 80 additions & 0 deletions
80
_posts/2020-06-18-azure-solutions-architect-program-mentoringowy.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,80 @@ | ||
--- | ||
title: "Analiza stosu technologicznego aplikacji obsługującej Program Mentoringowy." | ||
categories: | ||
- "Architecture Meetings" | ||
tags: | ||
- "Review sessions" | ||
author: | ||
- kaluzaaa | ||
--- | ||
# #azure-solutions-architect Mentoring tech stack | ||
|
||
Date: 2020-06-18 | ||
|
||
[Add to calendar](https://evt.mx/uUMzNr9T) | ||
|
||
[Meeting link](https://teams.microsoft.com/l/meetup-join/19%3ameeting_MjhiZmE3ZjEtMDliNy00OTQwLTg5ZmMtYTQ2NDhlMzJhMTkw%40thread.v2/0?context=%7b%22Tid%22%3a%22cc58971a-0481-4ec0-bf8d-bb2e265db003%22%2c%22Oid%22%3a%22f907c950-2a9a-4012-b163-af67be63b5d6%22%7d) | ||
|
||
[Recording](https://www.youtube.com/watch?v=ydag3Z4oWk0) | ||
|
||
# Agenda | ||
|
||
1. Analiza stosu technologicznego aplikacji obsługującej Program Mentoringowy. | ||
2. Q&A. | ||
|
||
# Discussion | ||
|
||
## Analiza stosu technologicznego aplikacji obsługującej Program Mentoringowy. | ||
|
||
1. Stos mentoringowy | ||
* Quick and dirty, w niektórych miejscach good enough, w niektórych bardzo dirty ;) | ||
2. Strona | ||
* Fork [DevConf-Theme](https://github.com/xriley/DevConf-Theme) | ||
* Miał jedną wadę, był całkowicie statyczny. | ||
* Przerzucono go na [Jekyll](https://jekyllrb.com/), a całość hostowano na [GitHub Pages](https://pages.github.com/). | ||
* Dane na strone, np. lista mentorów były generowane z listy w YAML przez Jekyll. | ||
* Aplikowanie ze strony - przez Microsoft Forms | ||
* Przy takich szybkich rozwiązania dobrze korzystać z gotowców. | ||
* Forms miał tylko zbierać dane, ale nie miał być docelowym miejscem gdzie miały być one przechowywane. | ||
3. Logic App | ||
* Na każde zgłoszenie odpalała się Logic Apka | ||
* Dodawała dane do MailerLite, żeby potem wysyłać emailing do uczestników. | ||
* Klucz wyciągała z Key Vault | ||
* Zrobione ręcznie przez HTTP Request z MSI Logic App, bo Logic App nie ma dobrej integracji z KV używając MSI. | ||
* Kroku, gdzie wyciągany jest klucz do MailerLite, skonfigurowany jest w taki sposób, że dane wrażliwe nie są pokazywane w logach. | ||
* Do Forms nie ma porządnego API. | ||
* Następnie było tworzone Issue na GitHub z danymi z formularza. | ||
* Potem Issue było przypisywane do tworzonej karty w projekcie. | ||
* Dalej zgłoszenie było zapisywane do Table na Azure Storage. | ||
* Przy tej ilości zgłoszeń API GH było bardzo wolne, dlatego też te zgłoszenia trafiały do Table. | ||
* Dalej poprzez przenoszenie kart w projekcie na GitHub wstępnie sortowano uczestników, którzy mieli być przekazani mentorom. Były zdefiniowane odpowiednie tagi i proces. | ||
4. Kod | ||
* W Pythonie, napisane quick and dirty, bo po prostu miało działać :) | ||
* Jeżeli któraś karta w projekcie na GitHub miała +4, to leciała już do mentora. | ||
* Dla każdej karty jak wyżej robiono request do API GitHub żeby wyciągnąć karty z +4 i zapisywano w odpowiedniej tabeli na Storage, gdzie był tylko partition key i row key. | ||
5. Strona dla mentorów | ||
* Kolejna [prosta stronka](https://github.com/AzureCommunityPL/azurecommunitypl.github.io/blob/master/mentoring.html) w czystym JSie. | ||
* Pod spodem Function App, która po uwierzytelnieniu się kluczem (każdy mentor miał swój klucz), pokazywała kandydatów dla niego. | ||
* Mentor był jako partition key, żeby można było wyciągnąć całego mentora w jednym zapytaniu. | ||
* Kiedy mentor wybrał swoich podopiecznych, to było wykonywane zapytanie, które zapisywało wybranych do odpowiedniej tabeli na Storage. | ||
* Przy okazji była wysyłana wiadomość na Slacka przez kolejkę. | ||
6. Po wybraniu | ||
* Kiedy kandydat był jako wybrany, to odpowiednim zapytaniem był przesuwany z +4 na Selected w projekcie na GitHub. | ||
* Aktualizowanie danych na MailerLite | ||
* Analogicznie dla mastermind - wszyscy z +4 i +3 - odpowiedni update w MailerLite. | ||
|
||
|
||
## Q&A | ||
* Coś byś zmienił? | ||
* Przerzucić na darmowe CosmosDB, żeby nie latać po tylu tabelach. | ||
* Sprzątanie przy dostępie danych dla mentora - ładniejsze załadowanie i przechowanie struktury z ACL | ||
* Link z dostępem i kluczem ważnym np. godzinę. | ||
* W niektórych miejscach bardziej zdarzeniowo. | ||
* Mógłby być kawałek panelu administracyjnego, żeby np. jak mentor chciał jeszcze raz wybrać, to żeby nie czyścić ręcznie tego z palca. | ||
* Poprawienie UX aplikacji. | ||
* Jak pracować z LogicApp w wiele osób - branche itd. | ||
* Niedługo będzie można pisać [kod do LogicApp w C#](https://github.com/Azure/logicapps/tree/master/preview)! | ||
* Do merge conflict dochodzi, kiedy scope zadań się przecinają - może trzeba tutaj zobaczyć co tu nie działa? Albo pull requesty za długo leżą. | ||
* Application Gateway Ingress Controller | ||
* Jest w preview, ma parę raków pod spodem, nieprodukcyjnie, dopóki nie będzie GA (support). Ma słabszą konfigurację niż NGINX Ingress Controller albo Traefik. | ||
* Najlepiej zwykły, klasyczny Ingress Controller NGINX. Ewentualnie Traefik. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.