Russell Smith je soustanovitelj in tehnični direktor Rainforest QA.
Ko rečem drugim tehničnim direktorjem in inženirjem, da se pri našem poslovanju močno zanašamo na Heroku, imajo vedno enak odziv: Zakaj? Zakaj ne AWS? Ali se šališ? Ste že slišali za Google Cloud? Si idiot?
To se zgodi brez okvare. S. Ven. Ne uspe. Argument se ponavadi glasi nekako takole: Zakaj bi morali plačati več za PaaS, če ga lahko zgradite sami v Googlu ali AWS - in naj bo takšen, kot želite? Na kar rečem: Poppycock. Ti ljudje pogrešajo resnične koristi PaaS in morda tudi nekaj osnovnega ekonomskega smisla.
Heroku veliko uporabljamo pri Rainforest QA od začetka leta 2012 za izvajanje naše avtomatizirane storitve testiranja kakovosti. V Heroku namestimo skoraj vse - za produkcijo, uprizoritev in zagotavljanje kakovosti za večino aplikacij. Je stabilen, ima ekonomski smisel in natančno ustreza našim potrebam.
Tu so glavni argumenti, ki jih slišim proti Herokuju, in zakaj mislim, da so (večinoma) zmotni.
# 1. Heroku je NIH (tukaj ni izumljen)
Če ga naša ekipa ne ljubeče sestavlja, ne more biti popoln za nas, zato ni dovolj dober. Danes je privzeto uporabiti AWS (ki je mimogrede tudi NIH), nato pa najeti ljudi, da na vrhu sestavijo trenutno moderno infrastrukturo mojega zagona-snežinke. Ta vrsta razmišljanja ima več napak:
- Vaši inženirski ekipi primanjkuje časa, da bi se naučili veščin in pravilno opravili delo, razen če najamete dodatnih ljudi, ki so izjemno pametni.
- Ne morete najeti dodatnih ljudi, ki so izjemno pametni. Odlični ljudje so zelo dragi, težko jih je najti in verjetno že delajo nekje drugje.
- Redko morate zgraditi infrastrukturo samo enkrat. Ko se vaše potrebe spremenijo, jih boste morali znova zgraditi.
- Vaša infrastruktura po meri ne bo preizkušena, dokler je Niste preizkusili v bitki. Oziroma, dokler tega ne storijo vaše stranke in inženirji. Ne postavljajte jih skozi to. Samo ne.
Če mislite, da lahko najamete najboljše ljudi, da sestavijo vašo infrastrukturo, se hecate. A tudi če bi lahko, čas, ki ga porabite za gradnjo te infrastrukture, le redko, če sploh kdaj, premakne vaš izdelek naprej (razen če je sama infrastruktura osrednji del vaše ponudbe).
Evo, zakaj imam raje svojo pot:
- Heroku nam omogoča, da se osredotočimo na to, kar najbolje počnemo - na izgradnjo avtomatizirane platforme za zagotavljanje kakovosti.
- Nekatere arhitekturne omejitve, ki so vam naložene, so dejansko lahko dobra stvar. Osvobodijo vas paralize izbire in analize.
- Heroku nenehno dodaja funkcije, ki dejansko naredi premaknite naš izdelek naprej.
Tu je le nekaj funkcij Heroku, ki jih imamo radi:
- Postgres z visoko razpoložljivostjo
- Šifriranje za Postgres je privzeto vklopljeno
- Odtoki dnevnikov (standardni način zbiranja in posredovanja dnevnikov)
- Pregled aplikacij (ki zaženejo kodo v kateri koli zahtevi za vlečenje GitHub v popolni aplikaciji za enkratno uporabo na Heroku)
- Tržišče dodatkov Heroku
Nedavni pomemben dodatek, ki ga je treba omeniti, je Heroku Shield, ki nam daje BAA (pogodba poslovnega partnerja o skladnosti s sistemom HIPAA s strani Salesforce.com. Ima nekaj težav z zobmi, toda če bi morali sami graditi skladnost s HIPAA, bi potrebovali nekaj inženirjev. en mesec ali več dela. Namesto tega ti inženirji premikajo naš izdelek naprej in osrečujejo naše stranke.
# 2. PaaS je predrag
Toda Heroku je takoooo drag! To je čredno razmišljanje in ne upošteva stroškov iskanja, zaposlovanja in usposabljanja odličnih devops ljudi za gradnjo in vzdrževanje vaše infrastrukture za snežinke. Da ne omenjam stroškov zadrževanja teh ljudi, namestitve v pisarno in zagotavljanja miz za namizni tenis ali česar koli drugega, da bi bili zadovoljni.
Potem gre za oportunitetne stroške najema ljudi v vlogah devops in sysadmin namesto produktnega inženiringa. In ti stroški se linearno povečujejo glede na vaše poslovanje. Z Herokujem se vam obrobni stroški zmanjšujejo.
In ne pozabite na dodatne stroške pomanjkanja osredotočenosti. Če se ukvarjate z zadevami zunanje infrastrukture, niste osredotočeni na izboljšanje izdelka.
Plačilo Herokuja pomeni, da vam ni treba skrbeti za izgradnjo infrastrukture in njeno stalno razpoložljivost - in še vedno stane enako ali manj kot najem in zadrževanje teh dodatnih operaterjev.
# 3. PaaS je preveč omejujoč
Ampak ... ampak ... moja snežinka! Veliko ljudi misli, da ima njihova aplikacija ali arhitektura edinstvene potrebe. V večini primerov ne - in če se, verjetno ne bi smel. Vendar sem pripravljen sprejeti nekaj upravičenih razlogov, da Heroku morda ne boste mogli uporabljati. Tukaj so:
- Potrebujete tone CPU ali RAM-a. Heroku ne bo meril do AWS, konfiguracije pa so nekoliko manj prilagodljive. Če res potrebujete na tisoče strežnikov, je AWS (ali celo gola kovina) lahko bolj ekonomičen. Toda Heroku podpira nekaj precej velikih primerov. Za večino ljudi bi moralo biti več kot dovolj.
- Potrebujete golokovinske strežnike ali posebne procesorje. Če se ukvarjate s strojnim učenjem ali drugim GPU-intenzivnim delom, Heroku morda ne bo najbolj ustrezal. Še vedno pa lahko uporabite hibridni pristop kot mi. Za najboljšo zmogljivost naše platforme za virtualizacijo uporabljamo Heroku, pa tudi golokovinske strežnike.
- Potrebujete RPC, ki ni HTTP, na primer gRPC. Usmerjevalnik Heroku danes ne podpira nobenega vhodnega prometa, ki ni WebSocket, HTTP ali HTTPS.
- Ne morete delati v podprtih modelih aplikacij. Če na primer potrebujete komunikacijo med vozlišči, tako da se lahko skupina strežnikov aplikacij obnaša kot ena za nekaj, kot je Erlang ali Elixir, ali če potrebujete edinstveno nastavitev usmerjanja, potem Heroku ni za vas.
Obstaja lahko nekaj drugih razlogov, ki pa pogosto niso bistveni za vaše podjetje. Če lahko svojo aplikacijo oblikujete tako, da ustreza modelu Heroku, imate številne ugodnosti. Najpomembnejša je doslednost aplikacij - od uvajanja, spremljanja, beleženja in skaliranja.
# 4. Heroku ne dela Dockerja
Moram pa imeti Dockerja! Fret nič več. Od začetka septembra lahko Dockerjeve slike namestite v Heroku. Že pred tem je Heroku vključeval nekoliko podobne zmogljivosti kot Docker, kar vam omogoča, da pošiljate kontejnerske gradnje svoje aplikacije. Ni se ujemal s funkcijo Docker za funkcijo, vendar bi lahko Heroku mislili kot gostujočo, upravljano različico Dockerja. V vsakem primeru te skrbi zdaj ni več.
# 5. Heroku ni dovolj varen
Toda Heroku ni varen! LOL. To ne bi smelo biti težava, razen če ste v močno urejeni panogi, na primer finančni, ali če potrebujete posebno potrdilo, ki ga Heroku ne podpira. Ni razloga, da bi verjeli, da je Heroku bistveno manj varen kot AWS. Ima celotno ekipo, ki je namenjena upravljanju varnosti svoje platforme; kajne Poleg tega se boste med oblikovanjem lastne infrastrukture odločili za množico enkratnih odločitev, od katerih nobena ne bo preizkušena. Heroku je te odločitve sprejel že pred vami in so bili preizkušeni v obsegu, ki si ga večina podjetij predstavlja.
Poleg tega je Heroku za razliko od vašega okolja po meri dosleden in enoten. Ima jasno opredeljene meje, kar pomeni, da bo vaša napadalna površina manjša. To tudi pomeni, da ga je lažje razumeti, zato je manj verjetno, da boste slučajno storili kaj, kar ustvarja ranljivost.
In mimogrede, inženirji imajo radi doslednega okolja za uvajanje iz vseh razlogov, poleg varnosti.
Na koncu mora vsako podjetje sprejeti najboljšo odločitev za svoje poslovanje in svoje stranke. Ampak ne pozabite, da je tem strankam vseeno, ali ste na vrhunskem, domačem umetniškem delu ali na splošno PaaS. Skrbi jih, da vaša storitev deluje, da se sčasoma izboljša in da vas ne vdrejo. Heroku je zelo dobro delal pri nas in verjetno bi tudi pri vas.
—
Forum New Tech ponuja prizorišče za raziskovanje in razpravo o nastajajoči podjetniški tehnologiji v globini in širini brez primere. Izbor je subjektiven in temelji na našem izboru tehnologij, za katere menimo, da so pomembne in najbolj zanimajo bralce. ne sprejema tržnih zavarovanj za objavo in si pridržuje pravico do urejanja celotne prispevane vsebine. Vsa vprašanja pošljite na[email protected].
