Team-First na Serverless Engineering gamit ang Laravel at Bref

Rekording

https://www.youtube.com/watch?v=41JNqwdVmfk

Serverless Development sa Pamamaraang Platform Engineering

• Kahulugan ng CNCF: Pagbuo at pagpapatakbo ng mga application nang hindi namamahala ng mga server.
• Mga Benepisyo:
• [ 1 ] Mas kaunting operational overhead.
• [ 2 ] Mas mababang gastos.
• [ 3 ] Mas mabilis na development experience.
• [ 4 ] Hindi na kailangang maglaan ng mga server.

Mga Layunin at Panuntunan sa Adoption

• [ 1 ] Mga Layunin:
• Lutasin ang mga tunay na problema ng customer.
• [ 2 ] Mga Panuntunan:
• Lumikha ng tunay na halaga.
• Umayon sa paraan ng pagtatrabaho ng mga PHP team.
• Dapat kayang i-maintain ng buong team, hindi lamang ng isang tao.

Mga Case Study at Natutuhan

• [ 1 ] Simpleng API para sa Partner Data:
• Gumamit ng API Gateway at Lambda upang mag-save ng data sa S3.
• Matagumpay na nakayanan ang 200 ulit na paglaki ng traffic nang walang problema sa performance.
• Nakatagong Problema: Isang tao lamang ang kayang mag-maintain nito.
• Aral: Hindi ang language (Python) ang problema kundi ang hindi pagtugma sa team culture at paggamit ng mga hindi pamilyar na tool.
• [ 2 ] Serverless Platform para sa Machine Learning:
• Nakatipid ito at nagustuhan ng mga data scientist.
• Problema: Hindi ito magamit ng pangkalahatang development team.
• Aral: Kailangan ng solusyon para sa pangunahing grupo ng mga developer, hindi lamang sa mga specialist.
• [ 3 ] AWS Amplify:
• Naputol ang mga detalye ng eksperimento sa AWS Amplify, ngunit malamang na isa rin itong pagtatangkang humanap ng napapanatiling serverless solution para sa mas malawak na team.

Mahahalagang Aral

• [ 1 ] Pinagsasaluhang Pananagutan:
• Nangangailangan ang tunay na tagumpay ng shared ownership at paggalang sa kultura ng team.
• [ 2 ] Pagiging Angkop sa Team:
• Kailangang umayon ang mga solusyon sa paraan ng pagtatrabaho ng team at kayang i-maintain ng buong team.

Konklusyon

• Ang paglalakbay tungo sa epektibong serverless adoption ay nangangailangan ng pag-unawa at paggalang sa team culture, pagtiyak sa maintainability, at paglikha ng tunay na halaga para sa lahat ng stakeholder.

Mga Hamon sa mga Bagong Prototype

• [ 1 ] Paunang Reaksyon:
• Tinutulan ng mga lab team ang mga bagong prototype na gumagamit ng serverless dahil lumilihis ang mga ito sa nakasanayang "muscle memory" sa mga pamilyar na tool.
• [ 2 ] Natutuhan:
• Mahalagang may tiwala at komportable muna ang team sa mga pamilyar na tool bago magpakilala ng malalaking pagbabago.

Magkakaibang Karanasan ng mga Team

• [ 1 ] Ruby Team:
• Matagumpay na gumamit ng serverless.
• [ 2 ] Mga PHP Team:
• Nahirapan dahil sa mataas na cognitive load.
• [ 3 ] Napagtanto:
• Ang pagkakaiba sa tagumpay ay dulot ng cognitive load at pagiging pamilyar sa mga tool.

Bagong Estratehiya sa Paglipat sa Platform Engineering

• Lumipat tungo sa platform engineering upang gawing madaling gamitin at i-maintain ng buong team ang serverless.

Muling Pagsusuri sa mga Layunin

• Dating Layunin: Mag-release lamang ng mga serverless project.
• Bagong Layunin: Mag-release ng mga serverless project na kayang patakbuhin ng buong team.
• Sukatan ng Tagumpay: Kumpiyansa ng team sa halip na bilang ng mga function.

Pagpapagana ng Serverless para sa mga PHP Team

• Pangangailangan sa mga Pamilyar na Tool:
• Kailangan ng mga PHP developer ang mga tool na komportable silang gamitin.
• Mga Custom Runtime:
• Nagsimulang gumamit ng mga custom runtime para sa PHP sa Lambda noon pang 2018.

Solusyon: Laravel at Bref

• [ 1 ] Laravel:
• May tiwala na ang mga developer sa Laravel at pamilyar na sila rito.
• [ 2 ] Bref:
• Pinamahalaan nito ang mga komplikasyon ng pagpapatakbo ng PHP sa Lambda.
• [ 3 ] Pinagsamang Solusyon:
• Nagbigay-daan upang mapanatili ang mga kasalukuyang workload habang sinusubukan at nakukuha ang mga benepisyo ng serverless.

Unang Aplikasyon sa Production

• [ 1 ] Aplikasyon:
• Pagproseso ng malalaking CSV file.
• [ 2 ] Mga Teknolohiyang Ginamit:
• Gumamit ng Amazon S3 Select upang salain ang data sa Lambda at matiyak ang predictable na performance.
• [ 3 ] Mga Resulta:
• Mabilis na processing time at hindi na kailangan ang server management.

Adoption at Tagumpay ng Team

• [ 1 ] Mga Junior Developer:
• Nakabuo at nakapag-deploy sila ng mga serverless app sa pamamagitan ng pagsunod sa documentation.
• [ 2 ] Pagbabago ng Tungkulin:
• Nagbago ang tungkulin ng tagapagsalita: mula sa pagiging bottleneck, naging coach siya.
• [ 3 ] Kakayahang Ulitin:
• Naging paulit-ulit na magagamit ang pamamaraan at hindi na ito nakadepende sa iisang expert.

Konklusyon

• Nangailangan ang matagumpay na serverless adoption ng pag-unawa sa team dynamics, paggamit ng mga pamilyar na tool, at paglikha ng environment kung saan may kumpiyansa ang buong team na magpatakbo ng mga serverless application.

Mga Bagong Hamon sa Serverless

• Mga Isyung Partikular sa Serverless:
• Cold start, timeout, at memory limit.
• Nagdulot ng mga hamon ang pagpapatakbo ng buong Laravel app sa iisang Lambda (Lambda Lift), gaya ng malalaking package size at kumplikadong permission.

Mga Praktikal na Solusyon

• [ 1 ] Mga Hakbang sa Pagbabawas ng Epekto:
• Gumamit ng Lambda Layers at magkakahiwalay na IAM role para sa mga sensitibong function.
• Gumamit ng production concurrency para sa mga timer at event-driven na pamamaraan upang pamahalaan ang mga cold start.
• [ 2 ] Pagpapatunay:
• Pinatunayan ng mga talakayan at validation mula sa mga respetadong engineer na praktikal ang pagpapatakbo ng mga monolith sa Lambda.

Mga Natutuhan

• [ 1 ] Microservice kumpara sa Monolith:
• Hindi palaging kailangan ang perpektong microservices architecture.
• Para sa mga team, praktikal ang Lambda Lift dahil nagbigay-daan ito sa shared ownership at mabilis na feature release.
• [ 2 ] Kumpiyansa ng Team:
• Mas mahalaga ito kaysa sa partikular na arkitektura.

Pag-scale ng Solusyon

• Mga Reusable Template at Standard Command:
• Gumawa ng mga reusable template at standard command upang hindi na kailangang magsimula sa wala ang mga bagong team.
• Nabawasan ang support load ng platform team.

Platform Engineering

• [ 1 ] Kahulugan:
• Pagbuo ng mga shared service upang tulungan ang mga development team na mas mabilis na mag-release ng mga feature nang may mas mababang cognitive load.
• [ 2 ] Mga Gabay na Prinsipyo:
• Sinunod ang pinakamahuhusay na kasanayan sa industriya, gaya ng CNCF white paper tungkol sa mga platform.
• [ 3 ] Team Topologies Model:
• Layunin nitong makapagpokus ang mga susunod na team sa mga feature habang binabawasan ng platform team ang kanilang cognitive load sa pamamagitan ng mga standard na solusyon sa mga karaniwang problema.

Pagdidisenyo ng Platform

• [ 1 ] Pag-angkop sa mga Kasalukuyang Team:
• Dinisenyo ang platform upang umayon sa kasalukuyang istruktura at kultura ng team.
• [ 2 ] Pagbawas sa Cognitive Load:
• Iniwasan ang mga kumplikadong serverless architecture na maaaring magdulot ng pangamba.
• Gumamit ng mga load balancer upang iruta ang traffic sa tamang computing target (halimbawa, pamilyar na Lambda para sa mga PHP team).
• [ 3 ] Pagpili ng Database:
• Pinili ang TiDB, isang MySQL-compatible service, upang magamit ng mga developer ang mga pamilyar na SQL command nang kakaunti lamang ang pagbabago.

Karanasan sa Local Development

• Mga Tool:
• Gumamit ng Docker at LocalStack upang mapatakbo ng mga developer ang buong application sa kanilang laptop gamit ang parehong mga PHP command.
• Lubhang nabawasan ang hirap sa adoption.

Mga Resultang Nagdulot ng Pagbabago

• [ 1 ] Pagbabago ng Tungkulin:
• Nagbago ang tungkulin ng tagapagsalita: mula sa pagiging bottleneck, naging enabler siya.
• [ 2 ] Tagumpay sa Pag-scale:
• Na-scale ang pattern sa iba't ibang team.
• Lubhang bumilis ang onboarding ng mga bagong team sa mga serverless project.

Konklusyon

• Binago ng platform engineering approach ang kakayahan ng team na gumamit at mag-scale ng mga serverless technology sa pamamagitan ng pagtutok sa pagbawas ng cognitive load, paggamit ng mga pamilyar na tool, at pagbibigay ng mga reusable template at standard na solusyon.

Mahahalagang Katangian ng Platform

• [ 1 ] Sistemang Self-Service
• Mga command at automated CI/CD pipeline.
• Inaalis nito ang mga support ticket at hinahayaan ang mga developer na magpokus sa kanilang trabaho.
• [ 2 ] Mga Guardrail
• Mga tool tulad ng structured logging at Sentry na may mga alert.
• Kabilang dito ang mga Lambda function na may gabay kung paano lutasin ang mga problema.

Pag-unlad ng Platform

• Paunang Yugto: Masinsing pakikipagtulungan.
• Kasalukuyang Yugto: Lumilipat tungo sa modelong "X as a Service," kung saan isang self-service product ang platform.
• Layunin: Gawing likas na bahagi ng kultura ang self-service.

Mga Patuloy na Pagsisikap

• Pagsasama sa Proseso:
• Isama ang mga serverless pattern sa sprint planning, code review, at retrospective.
• Tiyaking may kumpiyansa ang buong team sa system.

Roadmap sa Tatlong Hakbang

• [ 1 ] Mag-angkop:
• Magsimula sa mga template at coaching.
• [ 2 ] Gawing Pamantayan:
• I-automate ang testing at deployment hanggang maging standard ang mga ito.
• [ 3 ] Mag-scale:
• Palawakin ang pattern sa mas maraming product at patuloy itong paghusayin.
• [ 4 ] Resulta:
• Ginagawa ng simpleng cycle na ito na produktibo at handa sa hinaharap ang mga team.