Instapaper werkt aan bestandsherstel na 31 uur offline te zijn geweest

Instapaper, een dienst waarmee gebruikers online artikelen kunnen opslaan en later kunnen teruglezen, is na een storing bezig zijn bestanden te herstellen. De dienst was 31 uur niet bereikbaar en zegt ongeveer een week nodig te hebben om alle bestanden volledig terug te zetten.

Instapaper meldt op zijn eigen website dat het verwacht de database uiterlijk op 17 februari weer hersteld te hebben. Om zo snel mogelijk weer online te komen, nam het bedrijf de beslissing om alleen artikelen te herstellen die in de afgelopen zes weken door gebruikers zijn opgeslagen. Alle artikelen die voor 20 december zijn opgeslagen, zijn momenteel niet toegankelijk.

In een eerder bericht deelde Instapaper mee dat de problemen ermee te maken hadden dat 'de maximale opslagcapaciteit bij de cloudprovider was bereikt'. Over de identiteit van de provider maakt de organisatie niets bekend. Door het bereiken van de limiet moest de dienst alle gegevens naar een nieuwe database verhuizen. Het bedrijf maakt geen melding van dataverlies.

Het bedrijf is verschillende malen van eigenaar verwisseld. In 2013 werd Instapaper gekocht door Betaworks, waar ook Digg onder valt. Vorig jaar werd de organisatie opnieuw overgekocht voor een onbekend bedrag, deze keer door Pinterest.

Reacties (16)

[johnkeates]

"Laten we alles aan een provider uitbesteden, dat is beter, en dan hoeven we zelf niks te weten over de stack waar we op draaien" - elke gecrashte app developer ooit.

[Ed Vertijsment]

In een ideaal scenario is je app stack agnostisch, je neemt een aanbieder van een basissysteem (virtualsatieplatform X, container software Y) of wat dan ook en gegeven die aanwezigheid kan je zelf alles uit code tevoorschijn halen (Infrasctructure As Code).

In de praktijk heb je toch altijd beperkingen:

- Aanbieder 1 vond het nodig om een "customized experience" te maken die al je zooi breekt.
- Aanbieder 2 draait op een oude versie van software Y.
- De hardware stack van de aanbieder regelt storage via netwerk terwijl scripts de firewall dichtgooien.
- etc...

Toch wil je niet zelf:

- Je rack hoeven klussen.
- Netwerk aanleggen.
- Netwerk onderhouden
- Software installeren.
- Software onderhouden.
- Hardware monitoring uitvoeren.
- Hardware vervangen.
- Om 3:17 uit je nest gaan om server n te fixen.
- etc...

Als je daarnaast nog:

- Aanbestedingstrajecten moet doen.
- Klanten moet managen.
- Offertes maken
- Contracten moet tekenen.
- Projectmanagement doen.
- Code kloppen.
- Tests schrijven.
- Deployscripts onderhouden.
- etc...

Het is dus niet vreemd (en eigenlijk heel verstandig) dat je als developer deel van je plumbing bij een provider neerzet, en soms, heel soms, geeft dat issues.

Maar vergeet niet date een zekere softwareboer bij gods gratie maar een halve dag productiedata (!) is kwijtgeraakt omdat ze zo nodig zelf hun software stack wouden beheren, een migratie te lang duurde, een sysadmin overwerkt was, en niemand ooit de backups getest had.

Dit zijn allemaal fouten die er op duiden dat deze boer geen tijd heeft om proper infra te regelen. Dan moet je dat gewoon ook niet doen. Dat heeft niets met kunde te maken, maar puur met tijd en prioriteiten.

[johnkeates]

Uiteraard, maar ik doelde voornamelijk op problemen die ik in de praktijk zie die hun oorsprong vinden in het niet willen weten waar je code op draait. Natuurlijk heeft je werk of positie een scope waar je niet perse buiten wil springen, maar veel programmeurs (en dus niet 'echte' Software Engineers) hangen wat code aan elkaar en schuiven eventuele problematiek af op de runtime, het OS, de server, infra, netwerk enz...

Je ziet dezelfde problemen bij 'serverless' en 'docker' setups, waarbij de kennis en kunde gewoon niet aanwezig is om een goede applicatie te bouwen, en dan maar het probleem verlegd wordt. Stel dat je gewoon goede configuratie management zou moeten doen, maar in plaats daar van een compleet OS in een docker image duwt en het over de schutting gooit, dan ben je dus niet configuratie management aan het doen, maar begeeft zo'n developer zich eerder in 1990 Norton Ghost gebied. Hetzelfde probleem kan je dus hebben met een third party 'cloud' (eigenlijk gewoon een load balanced API) waarbij je er gemakshalve maar van uit gaat dat het altijd up is, altijd werkt, altijd de juiste request-response combinaties uitdeelt en alle verantwoordelijk daar moet liggen. "Want cloud is lekker makkelijk en dan hoef je zelf niks meer te doen." In de praktijk moet je nog steeds dezelfde controles en acties uitvoeren als of je met een normale file handle op een filesystem werkt. Controleren of het bestaat, of het in gebruik is, of er locks aanwezig zijn, of er voldoende ruimte is, zelf transacties uitvoeren, achteraf kijken of dat wat je bedoeld had ook daadwerkelijk uitgevoerd is. Natuurlijk is het anders als je een HTTP REST API vs. C FS API gebruikt, maar dat betekent niet dat je code opeens een gratis rommeltje mag zijn, en je applicatie zich als een dom stuk vreten mag gedragen ;-)

Dus, ongeacht wie wat waar uitvoert zal normale operations, configuration management, release management enz. gewoon gelden, het hopen op het niet hoeven kennen van de wereld buiten je code gaat eigenlijk nooit op. Daarom heb je in development teams vaak een of twee mensen zitten die wel weten hoe het zit, en bij een commit de code review doen en zien dat er vreemde assumpties gedaan worden. Natuurlijk is het leuker om geen code te hoeven schrijven en wel een gratis complete applicatie te hebben, maar zo werkt de wereld niet en vroeg of laat gaat een applicatie op z'n gat en ben je je data, klanten of vertrouwen kwijt. Er is niet direct wat op tegen om een serverless, docker, cloud applicatie te maken, maar dat betekent niet dat je daarmee niet zelf nog steeds zeker van je ops hoeft te zijn. Nieuwe technologie is geen vervanging van kennis.

[vbmot]

Het is juist ideaal om Docker images als deployable artifacts op te leveren, zeker in combinatie met een stack als Mesos/Marathon of Kubernetes. Voor developers is de hardware daarmee volledig abstract, een implementation detail. En sysadmins hoeven zich niet druk te maken of server x wel Java 8u40 en Python 3.1 heeft, want dat doet de developer in zijn Docker image.

Verder, als een server eens plat mocht gaan dan zorgt Marathon ervoor dat Docker images elders worden geladen. Dus hoeft niemand om 3:51 z'n bed uit om een of andere snowflake te herstellen.

[johnkeates]

Het gaat er niet om of het kan werken, maar of de specs daadwerkelijk in configuratie management opgenomen worden. Daarnaast is een Docker image met een compleet OS er in nogal idioot als je dan net zo goed een complete VM kan starten.

Stel dat je bepaalde versies van bepaalde libraries of support infra nodig hebt, dan moet je dat ergens noteren. Stel dat je dat dan al in SaltStack, Chef, Puppet of een ISO20000 CMDB zit te doen, wat voor toegevoegde waarde heeft het dan nog om dat nog een keer dunnetjes over te doen in een Docker image?

Daarnaast is orchestration en HA/Failover echt niet nieuw met Docker. De meeste gebruiken waar docker, swarm, kubernetes, Mesos enz. aangehaald worden zijn niet nieuw opzich, maar op z'n best een uiteinde aan een bestaand release- en configuratie management traject. Juist door goede management weg te laten en puur een (vaak onveilige, onvolledige en niet beheersbare) lompe binary bal als build op te leveren krijg je problemen. Daarnaast wordt het door gemakzucht vaak alleen door hippe developers gebruikt en niet door Ops, om dat die al weten dat de toegevoegde waarde op het moment nog steeds minimaal is. Stel dat je Google bent en bijv. Borg hebt als distributed applicatie coordinator, dan heeft het veel zin, maar als je semi-orginele-content-app nummer 13 in een dozijn bent kan je maar beter zorgen dat je eerst je normale management goed op orde hebt voor dat je gaat klooien met distributed resource clusters.

[vbmot]

Met docker hoef je benodigde versies dus niet nog een keer in ansible/chef/puppet te noteren. Dat zijn tools voor ops, gebaseerd op hardware, racks, datacenters. Als developer wil ik in mijn dagelijkse werk niet te maken hebben met server xxz-123.abc.datacenter.com. Dat mag jij gemakzucht noemen, voor mij is het abstractie en separation of concerns.

[johnkeates]

Met Docker moet je dat dus wel. Dat moet je met alles. Als developer kan je wel heel veel willen, maar je moet ten alle tijden weten van alles wat je hebt draaien wat de versies zijn. Als ergens ooit een CVE of patch voor uit komt moet je toch zeker wel uit een feed kunnen vissen of een versie die je gebruikt toevallig een security issue bevat...

Developers denken vaak dat na het programmeren de software zichzelf wel redt, maar zo werkt het niet. Tot dat alle software perfect geschreven wordt is er constant onderhoud nodig, en niet alleen voor nieuwe features of bugfixes, maar ook security en performance fixes. Tegenwoordig trekt iedereen lekker lukraak van ongecontroleerde bronnen maar wat zooi binnen en als het op de dev machine werkt 'zal het wel goed zijn'. Maar zo zit de realiteit dus niet in elkaar.

Wat betreft abstractie, sepco enz., dat is dus ook waar je configuration management voor hebt. Niet per file, per server of per instance, maar per configuratie item bepalen wat het moet zijn. Stel dat je applicatie op postgres bouwt, dan moet je weten welke postgres. Ten eerste om dat je anders niet kan controleren of er security issues zijn, en ten tweede om dat je anders niet kan controleren of je software gaat werken met de applicatie. Dus in plaats van te zeggen 'een random postgres server ergens', zal je een specifieke versie moeten kiezen, bijvoorbeeld 9.4.3-0+deb8u1 als je een downstream stable versie draait in een Debian-afgeleide. Dat je dat als developer niet leuk vind of te specifiek vind is dan jammer, maar als je het niet doet kom je alleen maar in de problemen. Of je dat dan daarna in een docker image probeert te stoppen of in een vm of op bare metal maakt voor configuratie management niet uit. Als je een Chef of SaltStack of Puppet configuratie setup hebt kan je het allemaal probleemloos uitpoepen, ook op non-Linux targets, embedded en bijv. apparatuur die locked op oudere hardware draait om dat het bijv. op radiation-hardened chips moet draaien.

Docket is niet waar je begint, maar een van de vele uiteindes waar je code en configuratie kan eindigen. Dat betekent dus niet dat je de rest lekker kan overslaan.

[kristofv]

Het gaat in zijn comment om het verkeerd gebruiken van containers. Als je in je container ook je data gaat opslagen of je OS zelf dan ben je in feite niets anders aan het doen dan een virtuele machine al jaren doet. Dat helpt dus niemand, ook jezelf niet.

[GrooV]

Of je houdt gewoon de capaciteiten van je cloudprovider in de gaten. Instapaper is namelijk in 2016 overgestapt naar Amazon AWS en die kunnen echt wel een database kwijt hoor. Spotify, Netflix, AirBNB, Yelp, Slack draaien ook allemaal op AWS.

Ik neem aan dat ze het zelf gewoon verkeerd hebben ingericht, net zoals slashdot die ooit tinyint's gebruikte voor id's

[mrdemc]

vreemd; als systeembeheerder moet je dat in de gaten houden of laten houden. Al die cloud providers zitten vol met alerts die in te stellen zijn voor van alles en nog wat. Je weet hoe groot de opslag is (neem ik aan want je neemt een bepaalde instance-grootte) en je weet hoeveel data je hebt... 1-1 = ?

[Reactie gewijzigd door mrdemc op 27 juli 2024 02:00]

[thof]

Bij mij komt dit eerder over als een cloud provider waarbij je een X-pakket afneemt met een maximum size, waarbij je al voor je je maximum size behaalt hebt fouten begint te krijgen omdat het platform van de cloud provider zelf niet genoeg storage heeft om de dienst te leveren.

[kristofv]

Bij vrijwel elke cloud provider heb je ook nog "overcommitment", Je kan doorgaans voor een korte periode nog x % extra resources aanspreken bovenop datgene waarvoor je betaalt.

Dit net om scenario's zoals dit hier te vermijden.. het geeft de systeembeheerders tijd om voor een oplossing te zorgen.

Dus het is inderdaad wel vrij bizar dat niemand dit schijnbaar ooit opgemerkt heeft.

[MrKuromili]

Ik vindt het interessant om te zien hoe bedrijven hun data weer proberen te herstellen. Zoals bijvoorbeeld bij gitlab toen. Ze hadden een live stream opgezet met bepaalde medewerkers om te laten zien hoe zij te werk gaan, Ik heb zowat een uur of twee naar die livestream zitten te kijken.

[wica]

Misschien had gitlab meer gehad, als ze een live stream hadden, bij het opzetten van de infra. Had misschien een hoop ellende voorkomen.

[Jogai]

Hulde voor het 'screenshot'