Nepatogi debesų priklausomybės ekonomika
Nuolaida, tapusi strategija
Pirmoji debesų kompiuterijos sąskaita, kuri iš tikrųjų rūpi, retai būna pati pirmoji. Pirmoji paprastai būna palengvėjimas. Nereikia pirkti serverio, nereikia laukti pirkimo ciklo, nereikia kalbėtis su infrastruktūros skyriumi dėl aušinimo, nereikia herojiškos skaičiuoklės apie pajėgumus ateinantiems trejiems metams. Komanda atidaro paskyrą, įdiegia paslaugą, stebi, kaip ji veikia, ir jaučiasi tarsi gravitacija būtų laikinai sustabdyta. Sąskaita atrodo civilizuotai. Finansų skyrius linkteli. Architektūra ištaria žodį elastinga. Visi grįžta namo su švelniu kompetencijos spindesiu.
Tada sistema tampa naudinga. Būtent tada pasikeičia ekonomika. Duomenys auga. Registravimas auga, nes kažkas pagaliau nori sužinoti, kas įvyko. Valdoma duomenų bazė tampa vieta, kur gyvena operacinė atmintis. Žinučių eilė įjungiama į vėlesnes sistemas. Tapatybės sluoksnis tampa pagrindinėmis durimis. Duomenų sandėlis gauna eksportus, nes analitikai irgi žmonės. Keletas specializuotų paslaugų tampa įprasta technologijų rietuvės dalimi. Mėnesinė sąskaita vis dar yra tik vienas skaičius, bet dabar joje slypi kelios ateitys.
Priklausomybė nuo debesų kompiuterijos tampa nepatogi, nes prasideda kaip patogumas, o subręsta į derybinę poziciją. Klausimas ne tas, ar debesų kompiuterija yra gera ar bloga. Toks rėminimas pernelyg tingus suaugusiems žmonėms, turintiems gamybines sistemas. Klausimas, ar organizacija supranta, kurios išlaidos yra matomos, kurios atidėtos, kurie pajėgumai išslydo iš jos rankų ir ko reikėtų pakeisti kursą nesustabdant darbo, kuris dabar priklauso nuo platformos.
Brangiausia priklausomybės dalis dažnai nėra nurodyta kaina. Tai pasirinkimo laisvės praradimas. Pasirinkimo laisvė yra galimybė iš naujo derėtis, perkelti, supaprastinti, pristabdyti, pakeisti ar atsisakyti nepaversdama organizacijos krizių centru. Debesų kompiuterija gali anksti nupirkti naudingos pasirinkimo laisvės: greitus eksperimentus, laikinus pajėgumus, valdomas saugumo funkcijas, pasaulinį pasiekiamumą. Ji taip pat gali vėliau išleisti pasirinkimo laisvę, kai duomenys, tapatybė, operacijos ir įgūdžiai taip tvirtai įsitvirtina aplink vieną teikėją, kad išėjimas tampa projektu, turinčiu savo orų sistemą.
Priklausomybė nuo debesų kompiuterijos nėra debesų kompiuterijos naudojimas
Naudotis debesijos paslaugomis yra įprasta. Priklausyti nuo debesijos paslaugų taip pat įprasta. Problema prasideda tada, kai priklausomybės nemato žmonės, priimantys sprendimus. Darbo krūvis, veikiantis nuomojamoje infrastruktūroje, nėra automatiškai užfiksuojamas. Darbo krūvis, kurio duomenų modelis, tapatybė, stebėjimas, diegimo procesas, saugumo būsena, atsarginių kopijų strategija, analitika ir darbuotojų įpročiai yra susieti su vienu tiekėju, yra kitas reikalas. Viena yra talpinimas. Kita yra veiklos modelis, kurio centre yra tiekėjas.
Priklausomybė turi sluoksnius. Yra komercinė priklausomybė: nuolaidos, įsipareigojimai, rezervuoti pajėgumai, kreditai, rinkos sutartys, palaikymo pakopos ir pirkimų kalendoriai. Yra techninė priklausomybė: patentuotos API, valdomos duomenų bazės, įvykių sistemos, tapatybės paslaugos, diegimo šablonai, stebėjimo agentai ir saugyklos semantika. Yra organizacinė priklausomybė: mokymai, veiklos vadovai, įdarbinimo profiliai, incidentų įpročiai, derinimo procesai ir raminantis įsitikinimas, kad portalas yra sistema. Kiekvienas sluoksnis gali būti racionalus. Kartu jie nusprendžia, kiek derėtis dėl ateities.
Daugelis organizacijų neįvertina organizacinio sluoksnio, nes jis neatsiranda architektūros diagramose. Inžinieriai įgyja sklandumą viename tiekėjuje. Saugumo komandos išmoksta jo politikos modelį. Finansai išmoksta jo sąskaitų kalbą. Pirkimai išmoksta jo sutarčių ritualus. Incidentų komandos išmoksta jo valdymo skydelius. Tas sklandumas turi vertę. Jis taip pat sukuria perėjimo išlaidas. Antras tiekėjas gali būti techniškai įmanomas ir ekonomiškai absurdiškas, jei niekas neturi darbinio žodyno juo naudotis esant spaudimui.
Štai kodėl į priklausomybę reikėtų žiūrėti kaip į valdomą riziką, o ne kaip į moralinę nesėkmę. Ligoninė gali pagrįstai naudoti valdomas debesijos paslaugas ne kritinei analitikai ir vis tiek išlaikyti klinikinį tęstinumą arčiau savęs. Mažmenininkas gali priimti didelį platformos susiejimo laipsnį dėl greito mastelio keitimo. Viešoji įstaiga gali pasirinkti griežtesnį perkeliamumą piliečių įrašams. Klaida nėra priklausomybės pasirinkimas. Klaida yra pasirinkti ją atsitiktinai ir sužinoti kainą tik tada, kai kas nors paprašo išeities.
Ekonominis paviršius yra didesnis nei skaičiavimo ištekliai
Debesijos pokalbiai dažnai prasideda nuo skaičiavimo išteklių ir saugyklos, nes juos lengva suskaičiuoti. Tai tarsi vertinti restoraną pagal bulvių kainą. Ekonominis paviršius apima tapatybę, tinklo srautą, žurnalus, atsargines kopijas, replikavimą, stebėjimą, saugumo nuskaitymą, raktų valdymą, valdomas duomenų bazes, eiles, analitiką, duomenų perdavimą, palaikymą, atitikties įrodymus, darbuotojų laiką, migracijos darbus ir išlaidas, susijusias su atsisakymu numatytiesiems nustatymams. Sąskaita yra tik ta sistemos dalis, kuri mandagiai atkeliauja kaip PDF.
Valdomos paslaugos gali būti puikios, nes sudėtingą operacinį darbą paverčia paslaugos riba. Valdoma duomenų bazė gali būti saugesnė ir pigesnė nei prastai valdoma vietinė duomenų bazė. Valdoma eilė gali sutaupyti inžinerijos savaites. Valdomas tapatybės sluoksnis gali sumažinti katastrofiškų klaidų skaičių. Tačiau konversija nėra išnykimas. Darbas persikelia. Atsakomybė persikelia mažiau. Organizacija vis tiek atsako už duomenų kokybę, prieigos politiką, atsarginių kopijų paskirtį, saugojimo laiką, atkūrimo laiką, įrodymus ir sutrikimo pasekmes. Ji išsinuomojo raumenis, o ne sprendimą.
Pavojingiausias debesijos verslo atvejis yra tas, kuris įkainoja paslaugą ir ignoruoja jos sukurtą elgesį. Kai saugykla yra lengvai prieinama, komandos laiko daugiau. Kai žurnalai pakankamai pigūs, komandos registruoja be klasifikavimo. Kai duomenų kopijavimas yra vienas mygtukas, kopijos dauginasi. Kai valdoma analitika yra prieinama, atsiranda neapdoroti eksportai. Kai visos komandos gali kurti išteklius, pavadinimų taisyklės tampa folkloru. Patogumas yra vertingas, tačiau patogumas be inventorizacijos tampa maža mokesčių institucija architektūros viduje.
Gera debesų kompiuterijos ekonomika todėl prasideda nuo paslaugų žemėlapio, o ne nuo nuolaidų lentelės. Kurios darbo krūvio grupės yra kritinės. Kurie duomenys turi teisinį ar misijos jautrumą. Kurios paslaugos yra nuosavybinės. Kurias galima pakeisti. Kurie duomenys kerta mokamas ribas. Kurie žurnalai reikalingi kaip įrodymai. Kurios atsarginės kopijos yra išbandytos. Kurie įsipareigojimai susieti su realia paklausa. Kurie žmonės gali valdyti sistemą, kai portalas lėtas, sąskaita stebina arba tiekėjas pakeičia numatytąją reikšmę.
Egress mokesčiai nėra skandalas, jie yra simptomas
Egress mokesčiai sulaukia daug dėmesio, nes atrodo nemandagūs. Mokėti už duomenų išvedimą iš vietos, į kurią sumokėjote juos įdėti, emociškai primena mokėjimą už išėjimą iš susitikimo. Susierzinimas suprantamas. Tačiau egress nėra visa problema. Tai matomas didesnio ekonominio dizaino simptomas: duomenys tampa vertingesni tiekėjui, kai lieka, ir brangesni klientui, kai juda.
Duomenų gravitacija iš dalies techninė. Didelius duomenų rinkinius lėta perkelti. Išvestinius duomenų rinkinius reikia suderinti. Indeksai, teisės, schemos, metaduomenys ir kilmė nekeliauja automatiškai. Žemupio sistemos remiasi keliais. Analitikai kuria užrašų knygeles. Darbo eigos priklauso nuo vietų. Judėjimo kaina apima pralaidumą, bet taip pat ir žmogiškąjį darbą, kad perkeltas dalykas po atvykimo reikštų tą patį. Kiekvienas, kas yra migravęs duomenų visumą, žino, kad baitai dažnai yra mažiausiai sarkastiška to proceso dalis.
Duomenų gravitacija taip pat politinė. Komanda, norinti palikti platformą, gali sulaukti prieštaravimų iš kiekvienos grupės, kuri aplink ją kūrė. Saugumas klausia apie kontrolės priemones. Analitika klausia apie dujotiekius. Produktas klausia apie delsą. Finansai klausia, kodėl nenaudojamas esamas įsipareigojimas. Teisės klausia, ar keičiasi duomenų tvarkytojai. Operacijos klausia, kas laikys sietyną. Nė vienas iš šių prieštaravimų nėra kvailas. Kartu jie sudaro likimo ekonomiką.
Rimta architektūra įkainoja judėjimą dar prieš jam prireikiant. Ji laiko kritinius duomenis atvirais formatais. Ji fiksuoja schemų versijas ir kilmę. Ji atskiria šaltinio įrašus nuo išvestinių patogumo sluoksnių. Ji išbando eksportą ir atkūrimą. Ji neleidžia kiekvienai analitinei kopijai tapti nauja priklausomybe. Ji dokumentuoja, kas sugestų migracijos metu. Tas darbas augimo metu gali atrodyti pesimistiškas. Jis atrodo mažiau pesimistiškas, kai organizacija gauna atnaujinimo pasiūlymą su automobilio stovėjimo baudos šiluma.
Įsipareigojimai naudingi, kol netampa politika
Rezervuota talpa, įmonės nuolaidos, įsipareigotas išlaidų lygis ir debesijos kreditai gali būti ekonomiškai prasmingi. Jie mažina vieneto sąnaudas, kai paklausa yra reali ir stabili. Jie taip pat keičia elgseną. Įsipareigojimas gali virsti tyliu nurodymu naudoti daugiau vienos platformos, nes pinigai jau buvo pažadėti. Tada architektūra seka sutartį, o ne darbo krūvį. Tai ne korupcija. Tai aritmetika su skiriamuoju ženklu.
Įsipareigojimai ypač keblūs dirbant su dirbtiniu intelektu ir duomenimis, nes paklausa neaiški. Bandomajam projektui gali prireikti protrūkių pobūdžio eksperimentų. Gamybos inferencijos darbo krūvis gali stabilizuotis. Mokymui gali prireikti retkarčiais vykdomų didelių užduočių. Registravimas ir vertinimas gali plėstis, bręstant valdysenai. Saugykla gali kauptis, nes ištrynimui reikia daugiau disciplinos nei kūrimui. Įsipareigojus per anksti, organizacija gali pradėti optimizuoti prognozių teatrą. Įsipareigojus per vėlai, galima iššvaistyti pinigus. Bet kuriuo atveju įsipareigojimas turėtų būti traktuojamas kaip rizikos pozicija, o ne vien kaip pirkimų pergalė.
Kreditai nusipelno atskiro atsargumo. Nemokama ar subsidijuojama talpa gali būti naudinga, ypač eksperimentams ir viešojo intereso darbams. Ji taip pat gali pasėti priklausomybę, kol organizacija dar neįkainojo pastovios būsenos. Komanda kuria paslaugas, kurios laikinai pigios, giliai integruojasi, o vėliau atranda įprastą sąskaitą. Pirmieji metai nebuvo kaina. Jie buvo masalas prognozėje. Jokios piktybės nereikia. Skaičiuoklė atliko darbą neveidmainiaudama.
Gera valdysena klausia, ką įsipareigojimas reiškia operaciniu požiūriu. Kurie darbo krūviai apimami. Kurie neįtraukiami. Kas atsitinka, jei paklausa sumažėja. Kas atsitinka, jei kitur egzistuoja geresnė paslauga. Ar nuolaida atgraso nuo perkeliamumo. Ar ji blogina tvarumą, skatindama perteklinį vartojimą. Ar ji slepia vietinės kompetencijos išlaikymo kainą. Nuolaida, silpninanti būsimus pasirinkimus, turėtų būti apskaitoma ir kaip sutaupymas, ir kaip rizika. Finansai supranta tokią kalbą. Architektūra taip pat turėtų.
Valdomos paslaugos perkelia darbą, o ne atskaitomybę
Stipriausias debesijos argumentas vis dar yra veiklos kokybė. Dauguma organizacijų nenori visko valdyti pačios, ir daugelis neturėtų. Pasaulyje pakanka prastai prižiūrimų serverių, pamirštų pataisų langų, pusiau išbandytų atsarginių kopijų ir didvyriškų administratorių, kurie žino per daug, nes niekas nieko neužrašė. Valdoma infrastruktūra gali pagerinti patikimumą, saugumą, greitį ir susitelkimą. Apsimesti kitaip yra nostalgija su stovo schema.
Tačiau „valdoma“ nereiškia „perduota“ teisine ar institucine prasme. Jei valdoma duomenų bazė praranda duomenis, organizacija vis tiek atsako vartotojui. Jei valdomos tapatybės konfigūracija suteikia per daug prieigos teisių, organizacija vis tiek yra pažeidimo savininkė. Jei valdoma dirbtinio intelekto paslauga saugo užklausas taip, kad tai pažeidžia politiką, organizacija vis tiek turi paaiškinti savo sprendimą. Tiekėjas gali dalytis atsakomybe, tačiau misija neperkeliama tiekėjui. Ji ir toliau lieka nepatogiai lokali tai institucijai, kuri pažadėjo teikti paslaugą.
Tas skirtumas svarbus sąnaudoms. Valdomos paslaugos gali sumažinti personalo poreikį atliekant kai kurias užduotis, tačiau padidinti architektūros, saugumo, tiekėjų valdymo, duomenų valdysenos, FinOps ir audito kompetencijos poreikį. Jei verslo atvejis pašalina senąją eksploatacijos komandą ir pamiršta finansuoti naują kontrolės darbą, organizacija nesutaupė pinigų. Ji pavertė matomą darbą paslėpta rizika. Sąskaita atrodo tvarkinga iki pirmojo incidento, kai dingę žmonės tampa keistai brangūs.
Todėl brandus debesijos veiklos modelis išlaiko pakankamai vidinės kompetencijos, kad veiktų kaip pajėgus užsakovas. Jis supranta, kaip paslauga veikia tokiu lygiu, kokio reikia konfigūruoti, stebėti, kvestionuoti, atkurti ir išeiti. Jis turi veiksmų vadovus, kurie aprašo daugiau nei tai, kurį mygtuką spausti. Jis moka skaityti žurnalus, keisti raktus, testuoti atsargines kopijas, riboti prieigą ir užduoti tiekėjams tikslius klausimus. Nereikia kurti kiekvieno komponento. Reikia netapti keleiviu savo pačių infrastruktūroje.
Atsparumas yra komercinė pozicija
Atsparumas dažnai apibūdinamas kaip inžinerinė savybė: perteklinės zonos, atsarginės kopijos, perjungimas, eilės, pakartotiniai bandymai, grandinės pertraukikliai, atsigavimas po nelaimių. Visa tai svarbu. Tačiau atsparumas taip pat yra komercinis. Ar organizacija gali toliau veikti kilus sutarties ginčui, vėluojant palaikymui, regioniniam sutrikimui, kainų padidėjimui, produkto nutraukimui, politikos pasikeitimui, eksporto apribojimui ar paskyros sustabdymui. Tai ne vien teisiniai scenarijai. Tai gedimų režimai su pirkimo užsakymų numeriais.
Kai kurie atsparumo modeliai yra ir techniniai, ir komerciniai vienu metu. Autoritetingų įrašų laikymas perkeliamais formatais yra ir duomenų valdymas, ir derybos. Nepriklausomi žurnalai yra ir stebėjimas, ir įrodymai. Vietinė raktų kontrolė yra ir saugumas, ir derybinė galia. Daugiaregionis dizainas yra ir prieinamumas, ir jurisdikcinė rizika. Išbandytas atkūrimas už pagrindinės platformos ribų yra ir atsigavimas po nelaimių, ir priminimas, kad išėjimas įmanomas. Kategorijos patogios, kol realybė jų nepaiso.
Daugi debesija kartais siūloma kaip automatinis atsakymas. Ji gali padėti konkrečiais atvejais, ypač kai darbo krūviai sukurti perkeliamumui, o komandos finansuojamos valdyti papildomą sudėtingumą. Ji taip pat gali tapti brangiu teatru: dvi platformos, du įgūdžių rinkiniai, du saugumo modeliai, dviguba sumaištis ir jokio realiai išbandyto išėjimo. Daugi debesija pati savaime nėra dorybė. Dorybė yra patikimas pasirinkimas. Kartais tai pasiekiama atvirais formatais, konteinerizuotais darbo krūviais, perkeliamomis duomenų bazėmis, nepriklausoma tapatybe ir tiekėjų drausme, o ne simetrišku dubliavimu.
Atsparumo klausimas turėtų būti praktiškas. Kurie darbo krūviai turi išgyventi tiekėjo stresą. Kiek ilgai jie gali degraduoti. Kurie duomenys turi būti prieinami vietoje. Kurios valdymo plokštumos priklausomybės yra priimtinos. Kurie avariniai veiksmai gali būti atlikti be tiekėjo patvirtinimo. Kurie išėjimai buvo išbandyti. Kurios komandos juos praktikavo. Jei atsakymas daugiausia yra pasitikėjimas, organizacija turi nuotaikų lentą, o ne atsparumą.
Išėjimo planas yra sąskaitos dalis
Exit planning is often treated as pessimism. It should be treated as accounting. An exit plan does not mean the organisation plans to leave tomorrow. It means the organisation knows what leaving would involve, which reduces the chance that staying becomes compulsory. The plan can be modest: inventory critical services, classify portability, document data formats, preserve independent evidence, test export, identify replacement patterns, and rehearse restoration for the few workloads that truly matter.
Exit does not have to be all-or-nothing. A good plan identifies partial exits. Move analytics before core operations. Replace a proprietary queue in one workflow. Keep backups outside the primary cloud. Retain an independent identity recovery path. Rebuild the most expensive storage tier. Separate AI evaluation data from a provider-specific tool. Each partial exit lowers dependency pressure. The point is not dramatic independence. The point is reducing the number of ways the organisation can be cornered.
The uncomfortable part is that exit costs money even when unused. Open formats need discipline. Portable designs can be less convenient. Staff need training. Tests consume time. Independent logs require storage and access control. Procurement needs stronger clauses. Architecture reviews take longer. This is why exit should be priced explicitly. If leaders decide not to pay for it, that is a decision. If nobody prices it, the system quietly chooses dependency and calls it efficiency.
There is a useful rule: the more critical the workload, the more boring the exit evidence should be. Not a slide saying portable. Not a contract paragraph promising reasonable assistance. A recent export. A restored sample. A measured duration. A list of lost features. A named owner. A known cost. If that sounds unromantic, good. Romance is not a recovery strategy.
Local skill is financial control
One of the quietest costs of cloud dependency is skill narrowing. Teams become very good at one provider's console, policy language, deployment model, managed services, and support rituals. That is productive until it becomes the only language available. When a supplier proposes a new service, the team evaluates it fluently. When a board asks whether another path exists, the answer is slower, vaguer, and usually more expensive because the organisation has not practised thinking outside the platform.
Įgūdžiai yra derybinė galia. Komanda, kuri supranta duomenų bazes, gali ginčyti valdomos duomenų bazės projektą. Komanda, kuri supranta tinklus, gali kvestionuoti duomenų perdavimo modelius. Komanda, kuri supranta tapatybės valdymą, gali nepriimti teikėjo numatytųjų nustatymų kaip saugumo politikos. Komanda, kuri supranta sąnaudų modelius, gali pastebėti, kada nuolaida keičia architektūrą. Komanda, kuri supranta atkūrimą, gali reikalauti įrodymų, o ne paguodos. Ekspertizė nereiškia, kad viską reikia daryti pačiam. Reikia žinoti pakankamai, kad posėdyje išliktumėte pavojingi, geriausia iki pietų.
Mokymai todėl turėtų apimti pagrindines galimybes, o ne tik teikėjo sertifikavimą. Kas yra eilė. Ką reiškia idempotentiškumas. Kaip žlunga atsarginės kopijos. Kas daro žurnalą naudingu kaip įrodymą. Kaip šifravimo raktų kontrolė keičia valdžią. Kas yra duomenų gravitacija. Kaip įsipareigojimai veikia elgesį. Kaip matuojame sąnaudas vienam naudingam sandoriui. Teikėjo įrankiai yra svarbūs, bet į juos reikėtų žiūrėti kaip į platesnių koncepcijų įgyvendinimus. Priešingu atveju organizacija supainioja meniu su virtuve.
Tai ypač aktualu viešajame ir pusiau viešajame sektoriuose. Institucijos, turinčios ilgalaikes pareigas, negali leisti, kad jų veiklos kalba būtų visiškai išnuomota. Savivaldybė, ligoninė, mokykla, vandens tiekėjas ar reguliavimo institucija gali gerai naudotis debesijos paslaugomis, bet vis tiek turi suprasti galimybes, nuo kurių priklauso. Priešingu atveju viešoji atsakomybė tampa palaikymo bilietu su logotipu, ir visi per vėlai supranta, kad valdymas per bilietų eilę turi ribotą konstitucinį žavesį.
Nepatogi išvada
Priklausomybė nuo debesijos yra nepatogi, nes tai ne blogiuko istorija. Debesija gali būti teisingas atsakymas. Ji gali sumažinti švaistymą, pagerinti saugumą, paspartinti pristatymą, paremti mokslinius tyrimus, susidoroti su apkrovų pikai ir leisti mažoms komandoms atlikti darbus, kurių kitaip jos negalėtų imtis. Daugelis debesijos kritikų tyliai daro prielaidą, kad egzistuoja vietinės veiklos meistriškumo lygis, kurio iš tikrųjų nėra. Blogai valdoma privati platforma nėra suverenumas. Tai tik intymesnis gedimas.
Nepatogumas kyla iš poreikio sąžiningai įvertinti. Patogumas turi vertę. Pristatymo apribojimai turi vertę tiekėjui. Išėjimas kainuoja. Įgūdžiai kainuoja. Įrodymai kainuoja. Perkeliamumas kainuoja. Įsipareigojimai turi ir sutaupymų, ir apribojimų. Valdomos paslaugos sumažina dalį darbo ir sukuria kitą darbą. Rimtas pokalbis viską padeda ant to paties stalo. Jis atmeta ir fantaziją, kad išsinuomota infrastruktūra automatiškai yra išlaisvinimas, ir fantaziją, kad nuosava techninė įranga automatiškai yra kontrolė.
Gera debesijos strategija priklausomybę pasirenka sąmoningai. Ji naudoja valdomas paslaugas ten, kur jos sukuria realią vertę. Ji nubrėžia griežtesnes ribas aplink kritinius duomenis, įrodymus, tapatybę ir atkūrimą. Ji finansuoja vidinę kompetenciją. Ji traktuoja sutartis kaip architektūros dalį. Ji išbando eksportą prieš derybas. Ji žino, kurios darbo krūvio dalys gali būti glaudžiai susietos, o kurios turi išlikti perkeliamos. Ji į debesijos sąskaitą žiūri ne kaip į bausmę, o kaip į signalą apie tai, kaip organizacija pasirinko veikti.
Pamoka pakankamai aiški, kad būtų naudinga. Debesijos ekonomika yra nepatogi, nes ji įkainoja ateitį, o ne tik dabartį. Pigus kelias gali būti pigus todėl, kad kažkas kitas laiko išėjimo duris. Brangus kelias gali būti brangus todėl, kad jis išsaugo pasirinkimo laisvę. Nė vienas faktas pats savaime nenulemia atsakymo. Institucija nusprendžia įvardydama, kas turi likti jos kontrolėje, kas gali būti išnuomota, kas turi būti perkeliama ir kokią kainą ji nori mokėti už galimybę pakeisti nuomonę.