NĂ« kĂ«tĂ« artikull do tĂ« doja tĂ« flasĂ« pĂ«r mĂ«nyrĂ«n si ne kemi ndryshuar qasjen ndaj orkestrimit nĂ« projektin tonĂ« tĂ« startupit, pse e bĂ«mĂ« kĂ«tĂ« dhe cilat probleme zgjidhĂ«m gjatĂ« kĂ«tij procesi. Kjo artikull nuk pretendohet tĂ« jetĂ« unik, por gjithsesi mendoj se mund tĂ« jetĂ« e dobishme pĂ«r dikĂ«, pasi gjatĂ« zgjidhjes sĂ« detyrĂ«s, materiali u mbledh nga ne me njĂ« pĂ«rkushtim tĂ« konsiderueshĂ«m. Â
ĂfarĂ« kishim dhe pĂ«r çfarĂ« bĂ«het fjalĂ«? Ishim nĂ« njĂ« projekt startup me rreth 2 vjet histori zhvillimi nĂ« fushĂ«n e reklamimeve. Projekti fillimisht u ndĂ«rtua si njĂ« mikros layanan dhe pjesa servere e tij Ă«shtĂ« shkruar nĂ« Symfony + pak Laravel, Django dhe NodeJs tĂ« natyrshĂ«m. ShĂ«rbimet pĂ«rbĂ«jnĂ« kryesisht API pĂ«r klientĂ«t mobilĂ« (nĂ« projekt janĂ« 3) dhe SDK-nĂ« tonĂ« pĂ«r IOS (integrimi nĂ« aplikacionet e klientĂ«ve tanĂ«), si dhe ndĂ«rfaqe web dhe tabela tĂ« ndryshme pĂ«r kĂ«ta klientĂ«. TĂ« gjitha shĂ«rbimet u dockerizuan fillimisht dhe punuan nĂ«n menaxhimin e docker-compose.
E vërteta është, docker-compose u përdor vetëm në mjedisin lokal të zhvilluesve, në testin serveri dhe brenda pipeline gjatë ndërtimit dhe testimit të shërbimeve. Ndërsa në mjedisin production u përdor Google Kubernetes Engine (GKE). Për më tepër, konfigurimi i GKE në fillim të projektit u bë plotësisht përmes ndërfaqes së tij web, që ishte mjaft e shpejtë dhe, siç na dukej atëherë, e përshtatshme. Procesi i ndërtimit të imazheve docker për nisjen e shërbimeve në GKE ishte i automatizuar.
