I øjeblikket tilbyder vi kun compute, men vi har planer om at tilføje Mongo NoSQL- og PostgreSQL-databaser snart. Og senere file storage og caching.
Nej. En af fordelene ved Merrymake er, at vi sørger for, at images er opdaterede og ikke har sikkerhedsproblemer. En anden grund er, at vi er nødt til at injecte vores caching mekanisme, hvilket ikke ville være muligt for alle images.
Message queues tjener to formål. Først og fremmest starter de service instances, hvorfor de er essentielle. Desuden afkobler de caller og callee, hvilket gør det meget nemmere at opdele en service i separate repositories/deployment units, hvis de bliver for store. Fordi det er let at opdele services, kan beslutningen om hvordan koden skal opdeles udsættes til det senest mulige tidspunkt.
I følge Twelve-Factor Apps guidelines skal der kun være én mekanisme for concurrency i et system. I Merrymake, opnåes concurrency gennem at poste mange messages til rapids. Det simplificerer de enkelte services og gør dem nemmere at vedligeholde. Og kombineret med vores råd om at bruge row-immutable data stores undgås det meste af kompleksiteten ved distribuerede systemer.
Pipelinen inkluderer en smoke test, der køres i Produktion, hvor det sikres, at filer og tredjepartsforbindelser er tilgængelige, og deployeringen stoppes hvis ikke de er. Da servicen har lov til at eksekvere custom code i denne fase, kan der tilføjes ethvert check, der ønskes.
Når det er sagt, skal den indbyggede pipeline betragtes som en deployment pipeline, ikke en integration pipeline. Denne pipeline er sandsynligvis tilstrækkelig til et ungt projekt, men efterhånden som koden modnes, vil der sandsynligvis tilføjes mere test og statisk analyse. Gennem Git-protokollen integrerer Merrymake godt med alle CI/CD-platforme, herunder GitLab, Azure DevOps, GitHub og BitBucket.
Med hensyn til et DEV-miljø, så har Merrymake en indbygget simulator, der kan spinde enhver del af systemet op, og simulere, hvordan det ville opføre sig i clouden. Denne simulator giver udviklere mulighed for at teste og debugge deres kode lokalt (endda offline), før den skubbes til Produktion.
Med hensyn til TEST og STAGING, så sigter Merrymake efter at fremme den nuværende bedst kendte praksis for softwareudvikling. Merrymake har indbygget simpel feature toggling, så det er nemt at udsætte nogle funktioner for bestemte brugere og ikke andre, hvilket giver os den samme opførsel som flere miljøer ville, uden ulemperne ved at forsøge at holde to eller flere miljøer synkroniseret.
Sikkerhed er altafgørende for en platform som vores, og selvom absolut sikkerhed er umulig, gør vi alt for at beskytte vores kunders data og oppetid.
Merrymake er designet med skalering i tankerne, så platformen starter ganske enkelt flere instances for at håndtere den øgede trafik, helt op til vores hardwaregrænse. Efterhånden som vores brug vokser, mindskes sårbarheden over for denne type angreb for alle vores kunder. Selvfølgelig kan tredjepartstjenester som databaser kæmpe under det øgede pres. Du kan selv begrænse, hvor mange parallelle instances du vil have i Merrymake.
Merrymake CLI'et og Git bruger SSH til al kommunikation, hvilket sikrer, at brugerne er autentiske, og ingen kan lytte til trafikken.
Vores no-code interface er afhængig af et magisk link sendt til en e-mail, og hvis e-mailen er sikker, så er det magiske link og dermed no-code interfacet.
Derudover kan du angive nøjagtigt, hvilke brugere der har adgang til hvilke funktioner i Merrymakes adgangskontrol.
De mest følsomme oplysninger er hemmelige envvars, såsom database connection strings. I Merrymake er de end-to-end krypteret, hvilket betyder, at de er krypteret på udviklerens enhed og kun dekrypteret inde i containeren, der kører koden. Kun denne container har adgang til både nøglen og den krypterede værdi, så det er kun udviklere i din egen organisation, der muligvis kan få fat i oplysningerne. Platformen forhindrer også visning af disse oplysninger for at undgå utilsigtet lækage, selvom dette kan omgås af bevidst ondsindede udviklere i din organisation.
Det næste niveau af følsomhed er messages under transit, som også er krypteret. Message payloads behandles som byte-streams, og derfor kan disse også krypteres for yderligere sikkerhed, men dette gøres ikke af platformen.
Slutteligt, da hastighed er et af vores primære mål, gemmes de fleste ting på den kritiske vej - mellem request og response - som plaintext. Det inkluderer kildekode (det ændres måske senere), ikke-hemmelige envvars og eventet.
