Prejšnji teden sem pisal o zavidljivi, petindvajseti obletnici upravitelja ConfigMgr. Danes pa bom še bolj podrobno predstavil ozadje tega izjemnega izdelka, objavil nekaj napovedi ter predstavil izjemen dokumentarec (pazi se, Sundance!), ki nudi poglobljen vpogled v nastanek in rast izdelka, ki je ustvaril panogo upravljanja PC-jev.
Novosti upravitelja ConfigMgr:
V luči izjemne obletnice želim deliti z vami zgodbo, ki je morda še niste slišali:
Kako se je vse začelo
Prejšnji teden sem znova prebral izvirno različico dokumenta ali »specifikacij« za Project Hermes. Tega dokumenta nisem videl že več let. Osupel sem bil, kako zvesta je ostala storitev ConfigMgr prvotni viziji. Osnovni gradniki, opisani v tem dokumenti, so še vedno v uporabi danes in so še vedno del temeljev izdelka.
Leta 1992 se je prvotni namen Microsofta (PC v vsak dom in na vsako mizo) bližal kritični masi. Organizacija so se začele od terminalne emulacije vse bolj premikati k modelu distribuiranega računalništva x86. Ni bilo na voljo možnosti za širše upravljanje PC-jev. Skupina se je zavedala, mora biti Project Hermes udaren.
Prva ekipa za SMS sta bila dva polno zaposlena razvijalca in pripravnik Ken Pan. Ko sem se ekipi pridružil leta 2003, je pripravnik Ken vodil celotno skupino približno 150 inženirjev. Ken je odtlej vodja inženirskih opravil pri projektih SCCM in Intune.
Zanimivost: Prva graditev strežnika Systems Management Server (SMS) je imela številko 245. Zakaj ne 1? Sistem Windows je takrat uporabljal graditev 300, skupina pa ni želela, da bi bilo videti, kot da so preveč v zaostanku. Hkrati pa so vedeli, da bi številka, ki je preblizu 300, vzbudila sum. Zato so izbrali 245.
Strežnik SMS je bil prvotno predstavljen 7. novembra 1994. Za prvo izdajo smo porabili malce več kot dve leti – danes izdajamo nove graditve za člane programa Insider vsak mesec.
Pomemben trenutek pri tej predstavitvi je bilo e-poštno sporočilo, ki ga je Bill Gates poslal vsakemu zaposlenemu pri Microsoftu z razlago razvoja strežnika SMS. Bill, nepoboljšljiv inženir, je v tem e-poštnem sporočilu izpostavil, kako po potrebi odstraniti programsko opremo SMS iz računalnika. 🙂
Če želite prebrati to e-poštno sporočilo, ga najdete na dnu objave.
Razvoj arhitekture
Različice SMS 1.0, 1.1 in 1.2 so bile izdane razmeroma hitro, s čimer smo spodbudili nastanek novega tržišča. Ekipa je brez premora nadaljevala delo z različico SMS 2.0.
Takrat pa so se stvari zakomplicirale.
In roko na srce, sprejeli smo nekaj slabih odločitev. Velik del pristopa, ki spodbuja rast, je možnost hitrega učenja – to je bil že od samega začetka osnovni gradnik ekipe SMS.
Arhitektura aplikacij odjemalec-strežnik se je od leta 1992 zelo spremenila. Ekipa je leta 1997 in 1998 pravzaprav na novo napisala infrastrukturo strežnika SMS, s katero je želela izboljšati učinkovitost strežnika SMS, poskrbeli pa so tudi za integracijo s prihajajočimi zmogljivostmi strežnika Windows Server 2000. To je bilo prvič, da je bila arhitektura strežnika SMS napisana znova. S tem smo poskrbeli, da je bila najsodobnejša za tisti čas.
Različico SMS 2.0 smo izdali januarja 1999, uvedba in uporaba pa sta se še razširili. Takrat sem delal pri največjem konkurentu strežnika SMS, projektu Novell, kjer sem bil vodja ekipe Novell ZENworks. Ne morem prešteti vseh ur, ki sem jih prebil na srečanjih s strankami strežnika SMS. Na teh srečanjih smo govorili o razlikah v primerjavi z rešitvijo ZENworks, ki se je osredotočala na uporabnike (identitete) z integracijo poglobljenega imenika.
Med pisanjem te objave sem se spomnil, da je bilo v različici SMS 2.0 skrito presenečenje. To presenečenje je bil videoposnetek z imeni in slikami ljudi, ki so delali na projektu. Ko sem si videoposnetek znova ogledal, me je prešinilo eno ime:
Terry Myerson, moj šef in izvršni podpredsednik pri Microsoftu. Očitno so se res vsa zveneča imena v svoji karieri srečala s projektom SMS. 🙂
Ekipi SMS sem se pridružil v trenutku, ko so bile v polnem teku priprave na izdajo različice SMS 2003.
V izdaji SMS 2003 je bilo veliko delov napisanih znova. Pomemben mejnik je bilo usklajevanje izdelka SMS s storitvijo WSUS za varnostne posodobitve. S tem smo Microsoftove varnostne popravke iz oblaka (Windows Update) omogočili za stranke in podjetja. Storitev WSUS je v osnovi sestavljena iz istih koščkov, ki so uporabljeni za Windows Update, vendar se izvajajo v vašem podatkovnem središču.
Windows Update je ena največjih storitev v oblaku, ki vsak mesec posodobi več kot 1 milijarde naprav. Razmislite malce o tem: Eden od dejavnikov, po katerem Microsoft izstopa v javnem oblaku, so hibridne zmogljivosti, ki omogočajo, da v svojem podatkovnem središču izvajate svoj javni oblak. Možnost izvajanja storitve Windows Update v lastnem podatkovnem središču (WSUS) je res pionirska storitev in najzgodnejši primer hibridne rešitve in povezave z oblakom. To je bilo tudi obdobje, ko se je razmahnila uporaba prenosnih računalnikov. Ustvariti smo morali novega odjemalca, ki je lahko deloval v povezanem in ohlapno nepovezanem modelu.
Ko smo se bližali izdaji različice SMS 2003, smo se vsak petek zjutraj sestali s skupino ljudi iz celotnega podjetja ter ocenili stanje projekta. Ena od ključnih skupin, ki je bila povabljena na srečanje, je bil oddelek Microsoft IT (MSIT). Ekipi za IT sem odobril veto na izdajo različice SMS 2003, če so menili, da izdelek še ni pripravljen. Vse od takrat je MSIT naša najboljša stranka kot tudi najboljši vir povratnih informacij o zgodnjih graditvah.
Danes pri Microsoftu upravljamo več kot 500.000 PC-jev in mobilnih naprav (ta številka ni vključena v 100 milijonov naprav MAD) s preprosto uvedbo storitve ConfigMgr. Z vsako mesečno izdajo pri Microsoftu razvijamo nove delce. Vsekakor uporabljamo svoje preskusne različice. Še ena zanimivost: Moja ekipa pravzaprav pregleduje interno uvedbo storitve ConfigMgr. Največ se naučiš tako, da delaš!
Med letoma 2003 in 2007 smo izdali dva »paketa funkcij«. Nismo želeli čakati na popolnoma nov izdelek, da bi lahko ponudili nove funkcije, zato smo uvedli ta nov način izdaje zmogljivosti. S prvim paketom funkcij smo dokončali usklajevanje storitve WSUS za varnostne popravke. Drugi paket funkcij smo predstavili z izdajo OS Deployment.
Eden mojih najljubših spominov na to obdobje je bila predstavitev v Evropi novembra 2003, na kateri smo predstavili nove zmogljivosti izdelka OS Deployment. Bill Gates je bil glavni govornik. Ko je začel govoriti o »novostih strežnika«, smo na zidu za njim v živo posodobili 100 PC-jev. Tej predstavitvi smo rekli »Ognjeni zid«.
Tu je slika Billa, kako spremlja predstavitev:
Tu je slika pogumnega člana ekipe SMS, ki je pripravil predstavitev:
Vpliv v panogi
Jeseni leta 2004 sta Bill in Steve gostovala srečanje brez povezave z nekaj višjimi vodji iz različnih oddelkov podjetja, na zadnji seji pa sta Bill in Steve odgovarjala na vprašanja. Nekdo je vprašal Billa, kaj je po njegovem mnenju »najpomembnejša stvar, ki se je pri Microsoftu zgodila prejšnje leto«. Bill je odgovoril: »Pri storitvi SMS in Active Directory smo se dobro odrezali – storitvi bosta odlični sredstvi za prihodnost«.
To je še vedno najlepši dan moje profesionalne kariere!
Leta 2007 smo ime »SMS« spremenili v »ConfigMgr«, da je skladno z blagovno znamko System Center. Desired State Configuration (DSC) je bil najnovejši inovativni scenarij, ki so ga zahtevale stranke. Zato smo znova razvili arhitekturo tako, ker smo želeli omogočiti ustrezno delovanje storitve DSC. Poleg tega smo popolnoma na novo napisali skrbniško izkušnjo.
Februarja 2011, sredi inženirskega razvoja storitve SCCM 2012, je Satya prevzel vodstvo storitve Server and Tools Business (STB), jo preimenoval v Cloud and Enterprise (C+E) ter postal moj šef. Za prvo osebno srečanje me je Satya obiskal v pisarni in večino časa porabil za to, da me je bolje spoznal. Več let sem delal neposredno za Satyo, kar je bila res izjemna izkušnja. V navdih mi je bila njegova izjemno zvedava osebnost, naravnanost na razvoj in spoštljiv pristop do vodstva. Satya je imel izjemen vpliv na prihodnost in arhitekturo storitve ConfigMgr med to izdajo.
V storitvi ConfigMgr 2012 smo arhitekturo zasukali na glavo, saj arhitekturo in izkušnjo prilagodili za uporabnike, ne zgolj naprave.
Stranke so nam sporočale, da bo v prihodnosti ključna mobilnost. Razumeli smo, da ne govorijo le o mobilnosti naprav, temveč tudi o mobilnosti ljudi. Kot odgovor na te informacije smo dramatično poenostavili arhitekturo tako, da je zahtevala manj strojne opreme, hkrati pa smo znatno povečali omejitve skalabilnosti. Na tej točki je naša pot v oblak postala resna. Storitev ConfigMgr smo povezali s storitvijo Microsoft Intune, Intune pa je v osnovi postal rob storitve ConfigMgr.
Ta hibridna konfiguracija je postala model, ki nam je omogočala inovativnost v oblaku. S to hibridno uvedbo smo uspeli dodati dodatno vrednost storitvi ConfigMgr na mestu uporabe. Bili smo mnenja, da bo oblak omogočal scenarije, ki bi bili v preteklosti nemogoči. Satya je videl moč oblaka za upravljanje naprav. Spodbujal nas je, da razvijamo nove rešitve na tem področju.
Storitev ConfigMgr se premakne v oblak
Naslednji razvojni korak arhitekture je bil daleč najbolj zahteven.
Ko smo spoznali, da bi lahko sistem Windows 10 ponudili v obliki storitve z več posodobitvami vsako leto, smo vedeli, da mora ConfigMgr spremljati zbirko in se premakniti v oblak.
Izziv je bil ogromen.
V preteklosti smo nove različice storitve ConfigMgr izdajali na 2 do 3 leta. Spominjam se, da je bilo na prvem načrtu za SCCM 2007 od trenutka, ko smo kodo dokončali pa do končne izdaje, 16-mesečno obdobje stabilizacije in preizkušanja različic beta. 16 mesecev! Bilo je popolnoma jasno, da bomo morali za storitev ConfigMgr uporabiti pristop SaaS, saj drugače ne bi mogli različic izdajati večkrat na leto.
Ker nas je čakala zelo zahtevna naloga, smo ročno izbrali majhno ekipo inženirjev in vodij programa, ki so dobro poznali storitev ConfigMgr, ki so imeli naravnanost k rasti storitve in ki so bili predani končnim uporabnikom. Menili smo, da lahko nalogo opravi le majhna in osredotočena ekipa, ki bi bila sposobna popolnoma predelati celotno arhitekturo ter ustvariti prvo resnično storitev v oblaku.
Ko sem pogledal časovni razpored za to nalogo, sem poleg svojega običajnega optimizma začutil tudi malo skepse. Tako malo časa za tako veliko nalogo je bilo res nekaj izjemnega.
Rezultat je bil izjemen: Ta izredno osredotočena ekipa inženirjev je presegla vsa pričakovanja in ustvarila nov pristop k upravljanju PC-jev v oblaku, s katerim smo lahko izdajali mesečne posodobitve. Za spremljanje teh posodobitev nismo uporabljali standardnih številk različic (na primer 2003, 2007, 2012 …). Namesto tega smo za poimenovanje začeli uporabljati zapis leto/mesec. Prva različica je imela številko 1511, ker je bila izdana 11. meseca leta 2015.
Od takrat naprej vsak mesec izdajamo novo različico storitve ConfigMgr za člane programa Insider, večje izdaje CurrentBranch pa približno vsake 4 mesece.
To je brez dvoma eden največjih inženirskih podvigov, pri katerih sem kdaj koli sodeloval.
Odziv uporabnikov na ta model v oblaku je bil izjemen.
Oglejte si ta grafični prikaz:
Malo več kot polovica uporabnikov storitve ConfigMgr je že izvedla nadgradnjo na trenutni model in trenutno je aktivno upravljanih več kot 100 milijonov naprav, ki vračajo podatke o telemetriji.
100 milijonov!!!!
Kolikor vem, so na svetu le 3 storitve z več kot > 100 milijoni aktivnih uporabnikov ali naprav, ki so upravljane in vračajo podatke o telemetriji: Office 365, Azure Active Directory in ConfigMgr. Kaj imajo te storitve skupnega? Vse so del integrirane ponudbe Microsoft 365.
Na tem grafikonu je prikazana uvedba velikih izdaj trenutne veje storitve ConfigMgr od izdaje 1511. Imamo nadzorno ploščo, ki prikazuje podatke v resničnem času, ta grafikon pa vsako nedeljo ob 8:30 zjutraj pošljemo celotni ekipi.
Lahko mi verjamete, da je 8:30 v nedeljo zjutraj moj najljubši čas v celotnem tednu.
To je bila najhitrejša nadgradnja storitve ConfigMgr. Vidite lahko, da uporabniki z vsako izdajo (strmina črte od leve proti desni) hitreje uvedejo posodobitve. Sprva smo bili nekoliko v dvomih, kako se bo skupnost storitve ConfigMgr odzvala na tako hitre izdaje. Zdaj pa smo enako osupli kot tudi hvaležni za zaupanje, ki ste nam ga pokazali.
Še nikoli ni bilo večjega zanimanja in strasti do projekta Project Hermes kot prav zdaj.
Kaj sledi
Pot v oblak smo začeli z izdajo 1511 storitve ConfigMgr v trenutni veji novembra 2015. Takrat je bilo jasno, da je bil to velik korak na poti do zastavljenega cilja. Jasno nam je bilo tudi, da nas čaka še veliko dela.
Hitrost inovacij se je od različice 1511 le še povečala. Organizacije se hitro premikajo v svet storitev v oblaku, povezanih z mobilnimi napravami. Ker vam želimo v tem hitro spreminjajočem se svetu ponuditi rešitve, ki jih potrebujete, mora biti infrastruktura storitve ConfigMgr resnična storitev v oblaku. Trenutno je to storitev, ki je neprestano posodobljena z novimi zmogljivostmi, uporablja tehnologijo UI oblaka, s katerimi se prilagodi vašim potrebam ter ponudi izdelek, ki ga potrebujete, poleg tega pa je na voljo kot storitev v oblaku, ki lahko vključuje več 100 milijonov naprav po vsem svetu.
To me spominja na najpogostejšo izjavo vodij IT z vsega sveta: Jezi jih zapletenost, s katero se morajo ukvarjati, da dokončajo delo. Organizacije iščejo načine, kako poenostaviti to, kar so že uvedle. Poleg tega želijo enoten način, kako omogočiti uporabnike v vseh napravah. S tem dobijo tudi upravljanje in varnost, ki jo potrebujejo. Zato smo rešitev izdelali Microsoft 365. Rešitev M365 nudi sodoben in varen delovni prostor ter integrirane storitve v oblaku, ki uporabnikom omogočajo, da dosežejo več. Zaradi zasnove rešitve lahko oddelki za IT ponudijo obogateno in spodbudno delovno okolje, ki ga imajo radi tako uporabniki kot oddelki za IT.
To je naslednji evolucijski korak vseh Microsoftovih izdelkov, ki jih že leta uporabljate – Windows, Office, Active Directory in ConfigMgr. Z rešitvijo Microsoft 365 smo vse te izdelke premaknili v oblak. Podjetja po vsem svetu se premikajo v oblak (uporabljajo Windows 10 kot storitev, Office 365 in storitve EMS). To je tudi naslednji razvojni korak arhitekture storitve ConfigMgr.
Praktično vsako podjetje in komercialna organizacija na svetu z modelom na mestu uporabe uporablja storitve Active Directory, pravilnik skupine (GP) in ConfigMgr kot orodja za upravljanje. Želja po premiku v preprostejši in bolj sodoben model je sicer velika, vendar pot do tja bila ni preprosta. Organizacija ne more preprosto tleskniti s prsti in uporabnike/naprave iz okolja AD/GP/ConfigMgr premakniti v AAD/Intune. Uporabniki so od nas potrebovali most, ki bi omogočal preprostejši, hitrejši in varnejši premik. O tem smo se veliko naučili tako, da smo opazovali, kako se organizacije premikajo iz storitve Exchange na mestu uporabe v storitev Exchange Online.
Danes z veseljem napovedujemo storitev Co-management – nov nabor zmogljivosti in most, ki bo pospešil premik v sodobno upravljanje v oblaku. S posodobitvijo Fall Creators Update je napravo s sistemom Windows 10 mogoče hkrati pridružiti storitvi Active Directory (AD) na mestu uporabe in storitvi Azure AD.
Storitev Co-management izkorišča prednosti te izboljšave ter omogoča upravljanje naprave z agentom ConfigMgr in storitvijo Intune MDM. Premik v sodobno upravljanje ni več strm vzpon, ki ga je treba premagati. S soupravljanjem lahko sami določite zahtevnost poti v oblak na način, ki ustreza vaši organizaciji.
Olajšali smo delo v konzoli ConfigMgr ter vključevanje naprav v upravljanje in včlanitev za upravljanje s storitvijo Intune. Nato lahko izberete prvo delovno obremenitev, ki jo želite premakniti v oblak (gre dobesedno za drsnik, ki ga premaknete s storitve ConfigMgr na Intune), s tem pa je delovna obremenitev premaknjena v oblak.
Ena od edinstvenih zmogljivosti rešitve Microsoft 365 v tem scenariju soupravljanja je neprestana komunikacija med storitvama ConfigMgr in Intune. Med premikanjem delovnih obremenitev jasno vidimo, kdo je skrbniški vir (Intune ali ConfigMgr) za vsak atribut uporabnikov ali naprav. Na ta način poskrbimo, da niso uporabljeni pravilniki v sporu.
To znatno pospeši premik v Windows 10 in sodobno upravljanje v oblaku.
* * * * *
Med pisanjem te objave sem obudil veliko spominov. Storitve SMS/ConfigMgr/Intune so imele veliko vlogo v mojem življenju, življenju moje družine, v življenjih več 1000 inženirjev, ki so sodelovali pri projektu, in v življenju milijonov strokovnjakov za IT, ki so storitev uporabljali in jo še vedno uporabljajo. Rad imam ta projekt in to skupnost.
Prav tako sem vesel, da je nastal današnji dokumentarni film o zgodovini storitve ConfigMgr. Toda to je šele 1. del. 2. del je precej bolj pomemben. 2. del boste namreč ustvarili vi.
Če ste na dogodku Ignite, se ustavite pri oddelku za upravljanje in varnost pri Microsoftovi stojnici in nam zaupajte svojo zgodbo. Tukaj so preprosta navodila.
Če ste na dogodku Ignite, lahko preprosto sodelujete. Zaupajte nam svojo zgodbo tako, da svoje spomine in zgodbe o storitvi ConfigMgr naložite tukaj aka.ms/ConfigMgr25. TU je nekaj osnovnih navodil.
S temi prispevki bomo ustvarili 2. del, ki ga bomo poimenovali:
»Zgodovina storitve ConfigMgr v očeh ljudi«
Komaj čakam, da si ga bom lahko ogledal.
_______________________________________________
