Palvelimeton ensin -arkkitehtuuri

Serverless-first soveltuu huonosti yli 15 minuuttia kestäviin pitkäkestoisiin prosesseihin, työkuormiin, jotka vaativat pysyviä WebSocket-yhteyksiä, sovelluksiin, joissa on jatkuva suurikapasiteettinen liikenne ja joissa varattu kapasiteetti on edullisempaa, sekä järjestelmiin, jotka tarvitsevat matalan tason OS- tai verkkomäärityksiä. MicrocosmWorks arvioi jokaisen työkuorman näitä rajoituksia vasten arkkitehtuurisuunnittelun aikana ja suosittelee hybridejä lähestymistapoja, joissa serverless hoitaa API-rajapintoja ja tapahtumankäsittelyä, kun taas containers- tai VMs-ratkaisut ajavat työkuormia, jotka tarvitsevat pysyvää computea. Tämä käytännönläheinen lähestymistapa välttää yleisen virheen pakottaa jokainen komponentti serverless-ratkaisuun silloin kun se ei sovi.

MicrocosmWorks lieventää Lambdan kylmäkäynnistyksiä käyttämällä provisioned concurrency -toimintoa kriittisissä päätepisteissä, funktion pakettien optimointia käynnistysajan lyhentämiseksi, sekä strategista Lambda SnapStartin käyttöä Java-kuormituksissa, mikä lyhentää kylmäkäynnistykset sekunneista millisekunneiksi. Suunnittelemme sovellukset myös siten, että viiveherkät polut käyttävät kevyitä suoritusympäristöjä, kuten Node.js tai Python, minimaalisilla riippuvuuksilla, pitäen kylmäkäynnistykset alle 200 ms:ssa myös ilman provisioned concurrency -toimintoa. Päätepisteissä, joissa jopa tuo viive on liian suuri, käytämme Lambda@Edgea tai CloudFront Functionsia alle 10 ms:n vasteisiin.

MicrocosmWorks pystyttää paikallisia kehitysympäristöjä käyttäen työkaluja kuten SST (Serverless Stack), LocalStack tai Serverless Frameworkin offline-tilaa, jotka emuloivat pilvipalveluita kehittäjän koneella lähes tuotantotason tarkkuudella. Toteutamme integraatiotestisarjoja, jotka ajetaan tilapäisissä pilviympäristöissä, jotka käynnistetään jokaisen pull-pyynnön yhteydessä, jotta kehittäjät voivat validoida todellisia AWS-palveluita vastaan jakamatta staging-ympäristöä. Tämä kaksiosainen lähestymistapa tarjoaa nopeat paikalliset iterointisyklit kehitykseen samalla kun se löytää pilvikohtaiset ongelmat ennen kuin koodi saavuttaa tuotannon.

MicrocosmWorks on havainnut, että serverless on huomattavasti edullisempi sovelluksille, joilla on vaihtelevat tai piikikkäät liikennemallit – usein 70-90 % edullisempi kuin vastaavat aina päällä olevat container-käyttöönotot – mutta kustannusetu kapenee, kun kuukausittainen throughput ylittää 10-20 miljoonaa invocationia. Rakennamme kustannusennustemalleja arkkitehtuurisuunnittelun aikana, jotka vertaavat serverlessin invocation-kohtaista hinnoittelua varattuun container-kapasiteettiin sinun erityisiä liikennemallejasi varten, mukaan lukien piilokustannukset, kuten API Gateway -maksut ja data transfer -maksut. Optimointipalvelumme, joka on saatavilla hintaan $10-$35/tunti konsultointihinnoin, tarkistaa säännöllisesti serverless-laskutuksen tunnistaakseen hukkaa, joka johtuu yli-allokoidusta muistista, liiallisista function durationeista tai tarpeettomasta API Gatewayn käytöstä.

MicrocosmWorks käyttää yhteyspoolaus-välityspalvelimia (connection pooling proxies) kuten Amazon RDS Proxy tai PgBouncer, jotka on otettu käyttöön pysyvänä kerroksena Lambda-funktioiden ja tietokannan välissä, ja jotka multipleksoivat tuhansia Lambda-yhteyksiä hallittavaksi pooliksi todellisia tietokantayhteyksiä. Suunnittelemme myös palvelimettomia sovelluksia suosimaan DynamoDB:tä tai muita yhteydettömiä tietokantoja korkean samanaikaisuuden työkuormille, joissa yhteyspoolaus loisi silti pullonkauloja. Sovelluksille, joiden on pakko käyttää relaatiotietokantoja, toteutamme yhteyksistä tietoisia skaalausrajoituksia, jotka rajoittavat samanaikaisia Lambda-kutsuja vastaamaan tietokannan yhteyskapasiteettia.