Üks tehnoloogiakulu, mida te ei mõõda – see võib säästa miljoneid

Üks suurimaid nihkeid pilvele üleminekul on see, kuidas me tehnoloogia ja rakenduste eest maksame. Tööstus on läinud üle kohapealsete andmekeskustega serveris kõikehõlmavalt töötlemiselt muutuja- ehk utiliidi arvutusmudelile. Vastavalt hiljutisele Apptio aru, see tähendab, et "mikrooptimeerimine võib toimuda meeskonna tasemel iga päev, et muuta pilvekulude kuju... See on maailm, kus kapitalikulud (kapitalikulud) asemel on OpEx (tegevuskulud), mis muudab täielikult finantsaruannete esitamise viisi. ja sai hakkama."

Selle tulemusena on traditsiooniline kulude hankemudel ümber pööratud, pannes kulujõu inseneride kätte, kes arendavad ja haldavad neid rakendusi ja infrastruktuuri, võttes väga vähe arvesse, kui palju see ettevõttele tegevuskulusid maksma läheb. Kõik, kes täna tehnoloogiakaevikutes töötavad, on keskendunud siin ja praegu oma konkreetsele omandivaldkonnale, tagades, et süsteem saab iga päevaga hakkama ilma katkestusteta. Keegi ei mõtle sellele: Kas me saaksime teha seda, mida teeme rakendustes ja protsessides kiiremini, paremini, targemalt, st tõhusamalt?

Apptio, tarkvara tootjad, mis on mõeldud IT-teenuste kulude hindamiseks ja teavitamiseks planeerimise, eelarve koostamise ja prognoosimise eesmärgil, kirjeldab selle olukorra sünget reaalsust veelgi kui "insenerid, kes võtavad pilve jaoks rahalisi kohustusi, mis mõjutavad nende ettevõtte lõpptulemust samal ajal." finantsmeeskonnad näevad vaeva, et kulutuste tempo ja täpsusega sammu pidada.

Enamik insenere ei kontrolli kirjutatavat koodi ega mõista seda täielikult; nad lihtsalt lisavad infrastruktuuri, et juhtida kõike, mida tootmisse reklaamitakse.

Tööstuses ei ole tavapärane arvutada oma tehnoloogilise keskkonna kogukulusid sadade rakenduste või tehnoloogia jaoks, mida teie meeskond toetab. Seda on vaja muuta. (Märkus: ma ei räägi robotitöötluse automatiseerimisest-RPA-st, mis kasutab roboteid digitaalsete ülesannete automatiseerimiseks.) Minu lähenemine on keskendunud rakenduste, koodi ja protsesside tõhususele, mitte automatiseerimise kaudu saavutatavale tõhususele.

Miks on koodi kogumaksumuse mõõtmine oluline?

Rakendused on loodud selleks, et muuta protsessid ärikasutaja jaoks lihtsaks. Rakendusel kulub vastuse andmiseks palju ressursse ja keerukust, isegi kui reageerimisaeg on vaid mõni sekund. Nüüd korrutage see tuhandete või miljonite rakendusepäringute arvuga sekundis tuhandetes teie ettevõtte serverites. Kui korraga toimub nii palju asju, on lihtne asi kättesaamatuks muutuda ja see on seotud ka kuludega. Kui rakendust käitavad serverid peaksid kestma kolm aastat, kuid kestavad vaid ühe, kuna nende võimsus on otsas – kui suur on selle rakenduse tegelik hind? Seda peavad finantsjuhid ja teised teadma, sest neil on paigas eelarved, mida tuleb täita.

Tõhus ja terve süsteem nõuab sama töökoormuse töötlemiseks vähem ressursse kui ebatõhus süsteem. Koodi optimeerimine vabastab veelgi rohkem ressursse.

Peaaegu igal süsteemil on potentsiaali võimsuse ratsionaliseerimiseks vähemalt 30–40 protsenti ja koodi optimeerimine võib anda veel 20–80 protsenti kulude kokkuhoidu.

See tähendab, et väiksemates serverites saab käitada sama töökoormust, vähendades pilve- ja litsentsimiskulusid. Sellise säästu väärtus ei ole lihtsalt lühiajaline, vaid pikema aja jooksul, kuna enamik rakendusi elab praegu 5–20 aastat või kauem. Küsimus ei ole ainult lõpptulemuses, vaid selles, mida saaks selle vabanenud kapitaliga täna äritegevuse KPI-de jaoks ette võtta.

Kujutage ette koodi kogumaksumust 20 aasta jooksul ja kaaluge: "Kas oleksime saanud selle koodi 20% tõhusamaks muuta ja kui jah, siis kui palju oleksime võinud 20 aasta jooksul säästa?"

Siis on üleminek pilve ja pay-as-you-go versus ettemaks mudel, mis kulutab andmesüsteemide käitamiseks ja hooldamiseks kiiremini, kui suudame neid koguda ja analüüsida. Apptio aruanne toob esile, kuidas kõik kaotavad, kui pilveteenuste kulud pole läbipaistvad:

• Insenerid kulutavad rohkem, kui vaja, kulutõhususest vähe aru saades.
• Finantsmeeskonnad näevad vaeva, et mõista – ja sellega kursis olla –, mida kulutatakse uskumatult paljudele valikuvõimalustele (ainuüksi AWS-il on umbes 300,000 XNUMX SKU-d ja tuhandeid uusi funktsioone aastas).
• Juhtimisel ei ole piisavalt panust sellesse, kui palju kulutatakse ega võimet prioriteete mõjutada.
• Hanked ei osale tahtlikult oma allhangetes.

Säästu prognoosimine, kui optimeerite kooditüki enne, kui see muudab teie süsteemi ebaefektiivseks (parimal juhul) või põhjustab katkestuse (halvimal juhul), nõuab veidi rohkem planeerimist ja ülevaadet. Kuid see on vajalik, kui tahame ettevõtete praeguse kasvutempoga sammu pidada.

Järgmises artiklis räägin sellest, kuidas saame mõõta koodi kogukulu, säästes sellega miljardeid ebatõhusate protsesside pealt. Oled sa minuga?