Bieži gadās, ka programmatūras izstrādātāja galvenais uzdevums ir nodrošināt noteiktu lietotnes funkcionalitāti. Zaļā poga ir zaļa, un sarkanā poga ir sarkana un, piespiežot šīs pogas, tiek ierosināti noteikti procesi. Jautājumi, cik izmaksā pamatā esošā infrastruktūra, kas ir nepieciešama lietotnes izmantošanai, īpaši noteiktā mērogā, reizēm tiek aizmirsti, jo tie vairs nav izstrādātāja problēma. Izstrādes laikā lietotnes īpašnieks nereti ir nepatīkami pārsteigts, uzzinot faktiskās lietotnes darbības izmaksas, mērogojamības ierobežojumus neatbilstošas arhitektūras dēļ, kā arī ar lietotnes mērogošanu saistītās izmaksas, ja tādas rodas. Iespējamie situācijas attīstības scenāriji: sākt visu no jauna (izniekotas izmaksas un zaudēts laiks), mainīt izstrādātāju (ļoti nevēlami, jo parasti neviens negrib uzņemties atbildību par cita radītajām nekārtībām) un mēģināt salabot lietotni, iegādāties daudz jaunas tehnikas, lai uzturētu esošo, neparocīgo lietotni, vai vērsties pie mākoņpakalpojuma sniedzēja, lai vismaz būtu kāds, ko vainot, ja lietotne joprojām nedarbojas, kā nākas, vai tās uzturēšanai ir jātērē kaudzēm naudas.

Kompetenti pircēji parasti nepieļauj šādas situācijas, definējot izstrādātājiem precīzus uzdevumus un spējot izsekot progresam, kā arī pārbaudīt rezultātus. Taču, ko darīt, ja jums pašam nav šādas kompetences? Ļoti vienkārši. Atrodiet infrastruktūras partneri, iespējams, mākoņpakalpojumu sniedzēju, kas jūs pavadīs visā sarežģītajā lietotnes izstrādes procesā. Infrastruktūras partneris neizstrādās lietotni izstrādātāja vietā. Taču tas pievērsīs jūsu un viņa uzmanību noteiktām lietām, kas ir jāņem vērā, piemēram, kā lietotne tiks galā ar neparedzētu darbības kulmināciju? Kā tā sabalansēs pieprasījumu slodzi? Vai tā būs horizontāli vai vertikāli mērogojama, ja kāds no šiem variantiem ir iespējams? Vai tā spēs mijiedarboties ar slodzes stabilizatoriem? Vai tā varēs integrēties CDN tīklā? Vai kods ir pietiekami mazs, lai to varētu izpildīt bezservera skaitļošanas vidē? Vai mājaslapa ir pietiekami pilnveidota, lai taupītu datplūsmu? Vai lietotni var izmantot augstas pieejamības režīmā vai pat ģeogrāfiski dublētā augstas pieejamības režīmā? Un daudzas citas lietas atkarībā no situācijas.

Nobeiguma ieteikumi. Nodrošiniet ciešu saikni starp programmatūras izstrādes un infrastruktūras plānošanas procesiem. Tomēr nodaliet tos, jo programmatūras izstrāde un infrastruktūras ieguve no viena avota visticamāk radīs nepieciešamību pēc papildu resursiem programmatūras uzturēšanai.