Russell Smith er medstifter og CTO i Rainforest QA.
Når jeg forteller andre CTOer og ingeniører at vi stoler sterkt på Heroku for å drive virksomheten vår, har de alltid den samme reaksjonen: Hvorfor? Hvorfor ikke AWS? Tuller du? Har du hørt om Google Cloud? Er du en idiot?
Dette skjer uten feil. Med. Ute. Mislykkes. Argumentet går vanligvis omtrent slik: Hvorfor betale mer for en PaaS når du kan bygge den selv på Google eller AWS - og ha den akkurat slik du vil ha den? Som jeg sier: Poppycock. Disse menneskene mangler de virkelige fordelene med PaaS, og kanskje også noen grunnleggende økonomiske sanser.
Vi har brukt Heroku mye i Rainforest QA siden tidlig i 2012 for å kjøre vår automatiserte QA-testtjeneste. Vi distribuerer nesten alt i Heroku - for produksjon, iscenesettelse og kvalitetssikring for de fleste apper. Det er stabilt, det gir økonomisk mening, og det passer akkurat våre behov.
Her er hovedargumentene jeg hører mot Heroku, og hvorfor jeg tror de er (for det meste) feilaktige.
#1. Heroku er NIH (ikke oppfunnet her)
Hvis det ikke er kjærlig sammensatt av teamet vårt, kan det ikke være perfekt for oss, derfor er det ikke bra nok. Standard i disse dager er å bruke AWS (som for øvrig også er NIH), og deretter ansette folk til å sette sammen den for tiden hip, my-startup-is-a-snowflake-infrastrukturen på toppen. Denne tankegangen har flere feil:
- Ingeniørteamet ditt mangler tid til å lære ferdighetene og gjøre jobben riktig - med mindre du ansetter flere personer som er ekstremt smarte.
- Du kan ikke ansette flere personer som er ekstremt smarte. Flotte mennesker er veldig dyre, vanskelig å finne og jobber sannsynligvis allerede et annet sted.
- Du trenger sjelden å bygge en infrastruktur bare en gang. Når behovene dine endres, må du bygge det på nytt.
- Den tilpassede infrastrukturen din blir ikke kamptestet før DU har testet den. Eller rettere sagt, til kundene og ingeniørene dine har gjort det. Ikke sett dem gjennom det. Bare ikke gjør det.
Hvis du tror du kan ansette de aller beste menneskene til å sette sammen infrastrukturen din, tuller du selv. Men selv om du kunne, vil tiden du bruker på å bygge denne infrastrukturen sjelden, eller aldri, flytte produktet ditt fremover (med mindre selve infrastrukturen er en sentral del av tilbudet ditt).
Dette er grunnen til at jeg foretrekker ruten min:
- Heroku lar oss fokusere på det vi gjør best - å bygge en automatisert QA-plattform.
- Å ha noen arkitektoniske begrensninger pålagt deg kan faktisk være en god ting. De frigjør deg fra valg og analyse lammelse.
- Heroku legger stadig til funksjoner som faktisk gjøre flytte produktet vårt fremover.
Her er bare noen få av Heroku-funksjonene vi elsker:
- Postgres med høy tilgjengelighet
- Kryptering for Postgres er slått på som standard
- Loggavløp (en standard måte å gjøre loggsamling og videresending)
- Gjennomgå apper (som kjører koden i en hvilken som helst GitHub-pull-forespørsel i en komplett, engangsapp på Heroku)
- Heroku-tilleggsmarkedet
Et nylig viktig tillegg som er verdt å nevne er Heroku Shield, som gir oss en BAA (forretningsavtale for HIPAA-overholdelse fra Salesforce.com. Det har noen problemer med tennene, men hvis vi selv skulle bygge HIPAA-overholdelse, ville det tatt et par ingeniører måned eller mer arbeid. I stedet beveger ingeniørene vårt produkt fremover og gjør kundene lykkeligere.
# 2. PaaS er for dyrt
Men Heroku er sååå dyrt! Dette er flokktenking og ignorerer kostnadene ved å finne, rekruttere og trene store devops mennesker til å bygge og vedlikeholde snøfnugginfrastrukturen. For ikke å nevne kostnadene ved å beholde disse menneskene, sette dem på et kontor og skaffe bordtennisbord eller hva som helst annet som trengs for å holde dem lykkelige.
Deretter er det mulighetskostnaden for å ansette folk i devops og sysadmin-roller i stedet for produktteknikk. Og kostnadene øker lineært når virksomheten din skaleres. Med Heroku har du reduserende marginalkostnader i stor skala.
Og ikke glem tilleggskostnadene ved mangel på fokus. Hvis du har å gjøre med perifer infrastruktur, er du ikke fokusert på å gjøre produktet bedre.
Å betale Heroku betyr at du ikke trenger å bekymre deg for å bygge infrastrukturen din og holde den tilgjengelig til enhver tid - og det koster fortsatt det samme eller mindre enn å ansette og beholde de ekstra ops-personene.
# 3. PaaS er for begrensende
Men ... men ... snøfnaken min! Mange tror applikasjonen eller arkitekturen deres har unike behov. I de fleste tilfeller gjør det ikke det - og hvis det gjør det, burde det sannsynligvis ikke. Jeg er imidlertid forberedt på å godta noen legitime grunner til at du kanskje ikke kan bruke Heroku. Her er de:
- Du trenger massevis av CPU eller RAM. Heroku skaleres ikke så langt som AWS, og konfigurasjoner er litt mindre fleksible. Hvis du virkelig trenger tusenvis av servere, kan AWS (eller til og med bart metall) være mer økonomisk. Men Heroku støtter noen ganske store forekomster. For de fleste burde det være mer enn nok.
- Du trenger bare-metall-servere eller spesialprosessorer. Hvis du driver med maskinlæring eller annet GPU-intensivt arbeid, kan det hende at Heroku ikke passer bra. Imidlertid kan du fortsatt ta en hybrid tilnærming som vi gjør. Vi bruker Heroku, men også bare-metal-servere for å få best mulig ytelse for vår virtualiseringsplattform.
- Du trenger ikke-HTTP-RPC, for eksempel gRPC. Innkommende trafikk som ikke er WebSocket, HTTP eller HTTPS, støttes ikke av Heroku-ruteren i dag.
- Du kan ikke arbeide innenfor de støttede applikasjonsmodellene. For eksempel, hvis du trenger internode-kommunikasjon, slik at en gruppe app-servere kan oppføre seg som en for noe som Erlang eller Elixir, eller hvis du trenger et unikt rutingsoppsett, så er ikke Heroku noe for deg.
Det kan være noen andre grunner, men ofte er de ikke avgjørende for din virksomhet. Hvis du kan designe applikasjonen din slik at den passer inn i Heroku-modellen, får du mange fordeler. Den viktigste er konsistens på tvers av applikasjoner - fra distribusjon, overvåking, logging og skalering.
# 4. Heroku gjør ikke Docker
Men jeg må ha Docker! Frykt ikke mer. Siden begynnelsen av september kan du distribuere Docker-bilder til Heroku. Allerede før det inkluderte Heroku noe lignende funksjoner som Docker, slik at du kan sende rundt containeriserte apper av appen din. Det samsvarte ikke med Docker-funksjonen for funksjonen, men du kunne tenke deg at Heroku var en vert, administrert versjon av Docker. Uansett er bekymringen nå borte.
# 5. Heroku er ikke sikker nok
Men Heroku er ikke sikker! LOL. Med mindre du er i en sterkt regulert bransje, som økonomi, eller du trenger en bestemt sertifisering som ikke støttes av Heroku, bør dette ikke være et problem. Det er ingen grunn til å tro at Heroku er meningsfylt mindre sikker enn AWS. Den har et helt team viet til å administrere sikkerheten til plattformen sin; Gjør du? I tillegg kommer du til å ta massevis av engangsbeslutninger mens du ruller din egen infrastruktur, hvorav ingen vil bli testet. Heroku tok disse beslutningene lenge før deg, og de har blitt testet i en skala de fleste selskaper bare kan forestille seg.
I tillegg til, i motsetning til ditt tilpassede miljø, er Heroku jevn og ensartet. Den har grenser som er tydelig definert, noe som betyr at angrepsoverflaten din blir mindre. Det betyr også at det er lettere å forstå, så det er mindre sannsynlig at du gjør noe ved et uhell som skaper en sårbarhet.
Og forresten, ingeniører elsker et jevnt distribusjonsmiljø, av alle slags grunner i tillegg til sikkerhet.
Til slutt må hvert selskap ta den beste avgjørelsen for sin virksomhet og sine kunder. Men husk at disse kundene ikke bryr seg om du er på et banebrytende, hjemmelaget kunstverk eller et generelt formål PaaS. De bryr seg om at tjenesten din fungerer, at den forbedrer seg over tid, og at du ikke blir hacket. Heroku har fungert veldig bra for oss, og sannsynligvis ville det for deg.
—
New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til[email protected].
