Programmering

5 tåbelige grunde til, at du ikke bruger Heroku

Russell Smith er medstifter og CTO for Rainforest QA.

Når jeg fortæller andre CTO'er og ingeniører, at vi er meget afhængige af, at Heroku driver vores forretning, har de altid den samme reaktion: Hvorfor? Hvorfor ikke AWS? Laver du sjov? Har du hørt om Google Cloud? Er du en idiot?

Dette sker uden fejl. Med. Ud. Svigte. Argumentet går normalt sådan her: Hvorfor betale mere for en PaaS, når du selv kan bygge den på Google eller AWS - og have det, som du vil have det? Som jeg siger: Poppycock. Disse mennesker mangler de reelle fordele ved PaaS, og måske også nogle grundlæggende økonomiske sanser.

Vi har brugt Heroku meget i Rainforest QA siden begyndelsen af ​​2012 til at køre vores automatiserede QA-testtjeneste. Vi implementerer næsten alt i Heroku - til produktion, iscenesættelse og QA til de fleste apps. Det er stabilt, det giver økonomisk mening, og det passer præcist til vores behov.

Her er de vigtigste argumenter, jeg hører mod Heroku, og hvorfor jeg synes, de er (for det meste) vildfarne.

# 1. Heroku er NIH (ikke opfundet her)

Hvis det ikke kærligt samles af vores team, kan det ikke være perfekt for os, derfor er det ikke godt nok. Standard i disse dage er at bruge AWS (som forresten også er NIH) og derefter ansætte folk til at samle den nuværende hip-my-startup-is-a-snowflake-infrastruktur på toppen. Denne tankegang har flere mangler:

  • Dit ingeniørhold mangler tid til at lære færdighederne og udføre jobbet korrekt - medmindre du ansætter flere personer, der er ekstremt kloge.
  • Du kan ikke ansætte flere personer, der er ekstremt kloge. Store mennesker er meget dyre, svære at finde og arbejder sandsynligvis allerede et andet sted.
  • Du har sjældent brug for at bygge en infrastruktur kun en gang. Når dine behov ændres, skal du bygge det igen.
  • Din tilpassede infrastruktur bliver ikke kamptestet, før du har testet den. Eller rettere, indtil dine kunder og ingeniører har gjort det. Undlad at sætte dem igennem det. Bare gør det ikke.

Hvis du tror, ​​du kan ansætte de allerbedste mennesker til at samle din infrastruktur, tuller du selv. Men selvom du kunne, bevæger din tid til at bygge denne infrastruktur sjældent, hvis nogensinde, dit produkt fremad (medmindre selve infrastrukturen er en central del af dit tilbud).

Her er hvorfor jeg foretrækker min rute:

  • Heroku lader os fokusere på, hvad vi gør bedst - at opbygge en automatiseret QA-platform.
  • At have nogle arkitektoniske begrænsninger pålagt dig kan faktisk være en god ting. De befri dig fra valg og analyse lammelse.
  • Heroku tilføjer konstant funktioner, der faktisk gør flyt vores produkt fremad.

Her er blot nogle få af de Heroku-funktioner, vi elsker:

  • Postgres med høj tilgængelighed
  • Kryptering for Postgres aktiveret som standard
  • Logafløb (en standard måde at lave logindsamling og videresendelse)
  • Gennemgå apps (som kører koden i enhver GitHub-pull-anmodning i en komplet engangsapp på Heroku)
  • Heroku-tilføjelsesmarkedet

En nylig vigtig tilføjelse, der er værd at nævne, er Heroku Shield, som giver os en BAA (forretningsassocieringsaftale for HIPAA-overholdelse fra Salesforce.com. Det har nogle børnesygdomme, men hvis vi selv skulle bygge HIPAA-overholdelse, ville det tage et par ingeniører en måned eller mere arbejde. I stedet bevæger disse ingeniører vores produkt fremad og gør vores kunder lykkeligere.

# 2. PaaS er for dyrt

Men Heroku er sååå dyr! Dette er floktænkning og ignorerer omkostningerne ved at finde, rekruttere og træne store devops mennesker til at opbygge og vedligeholde din infrastruktur til snefnug. For ikke at nævne omkostningerne ved at fastholde disse mennesker, sætte dem på et kontor og levere bordtennisborde eller hvad der ellers kræves for at holde dem glade.

Derefter er der mulighed for at ansætte folk i devops- og sysadmin-roller i stedet for produktteknik. Og disse omkostninger stiger lineært, når din virksomhed skaleres. Med Heroku har du faldende marginale omkostninger i skala.

Og glem ikke de ekstra omkostninger ved din manglende fokus. Hvis du har problemer med perifer infrastruktur, er du ikke fokuseret på at forbedre dit produkt.

At betale Heroku betyder, at du ikke behøver at bekymre dig om at opbygge din infrastruktur og holde den tilgængelig til enhver tid - og det koster stadig det samme eller mindre end at ansætte og fastholde disse ekstra ops-folk.

# 3. PaaS er for begrænsende

Men ... men ... min snefnug! Mange mennesker tror, ​​at deres anvendelse eller arkitektur har unikke behov. I de fleste tilfælde gør det ikke - og hvis det gør det, burde det sandsynligvis ikke. Jeg er dog parat til at acceptere et par legitime grunde til, at du muligvis ikke kan bruge Heroku. Her er de:

  • Du har brug for masser af CPU eller RAM. Heroku skaleres ikke så langt som AWS, og konfigurationer er lidt mindre fleksible. Hvis du virkelig har brug for tusindvis af servere, kan AWS (eller endda bare metal) være mere økonomisk. Men Heroku understøtter nogle ret store forekomster. For de fleste mennesker skal det være mere end nok.
  • Du har brug for bare metal-servere eller specialprocessorer. Hvis du laver maskinindlæring eller andet GPU-intensivt arbejde, passer Heroku muligvis ikke godt til. Du kan dog stadig tage en hybrid tilgang som vi gør. Vi bruger Heroku, men også bare metal-servere for at få den bedste ydeevne til vores virtualiseringsplatform.
  • Du har brug for ikke-HTTP RPC, såsom gRPC. Enhver indgående trafik, der ikke er WebSocket, HTTP eller HTTPS, understøttes ikke af Heroku-routeren i dag.
  • Du kan ikke arbejde inden for de understøttede applikationsmodeller. For eksempel, hvis du har brug for internode-kommunikation, så en gruppe af app-servere kan opføre sig som en for noget som Erlang eller Elixir, eller du har brug for en unik routing-opsætning, så er Heroku ikke noget for dig.

Der kan være et par andre grunde, men ofte er de ikke vigtige for din virksomhed. Hvis du kan designe din applikation, så den passer til Heroku-modellen, får du mange fordele. Den største er konsistens på tværs af applikationer - fra implementering, overvågning, logning og skalering.

# 4. Heroku gør ikke Docker

Men jeg må have Docker! Fret ikke mere. Siden begyndelsen af ​​september kan du distribuere Docker-billeder til Heroku. Selv før det inkluderede Heroku noget lignende funktioner som Docker, så du kan sende rundt i containeriserede builds af din app. Det matchede ikke Docker-funktion for funktion, men du kunne tænke på Heroku som værende en administreret version af Docker. Under alle omstændigheder er denne bekymring nu væk.

# 5. Heroku er ikke sikker nok

Men Heroku er ikke sikker! LOL. Medmindre du er i en stærkt reguleret branche, såsom finansiering, eller du har brug for en særlig certificering, der ikke understøttes af Heroku, bør dette ikke være et problem. Der er ingen grund til at tro, at Heroku er meningsfuldt mindre sikker end AWS. Det har et helt team dedikeret til at administrere sikkerheden på sin platform; gør du? Derudover tager du masser af engangsbeslutninger, mens du ruller din egen infrastruktur, hvoraf ingen er blevet testet. Heroku tog disse beslutninger længe før dig, og de er blevet testet i en skala, som de fleste virksomheder kun kan forestille sig.

Plus, i modsætning til dit tilpassede miljø, er Heroku konsekvent og ensartet. Det har grænser, der er klart definerede, hvilket betyder, at din angrebsoverflade bliver mindre. Det betyder også, at det er lettere at forstå, så du er mindre tilbøjelige til at gøre noget ved et uheld, der skaber en sårbarhed.

Og forresten elsker ingeniører et ensartet implementeringsmiljø af alle mulige årsager udover sikkerhed.

I sidste ende skal enhver virksomhed træffe den bedste beslutning for sin virksomhed og sine kunder. Men husk, disse kunder er ligeglad med, om du er på et banebrydende, hjemmelavet kunstværk eller et PaaS til generelle formål. De bryr sig om, at din service fungerer, at den forbedres over tid, og at du ikke bliver hacket. Heroku har fungeret meget godt for os, og det ville sandsynligvis gøre for dig.

New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle henvendelser til[email protected].

$config[zx-auto] not found$config[zx-overlay] not found