Публикувано на: 12 юли, 2022*Текстът е предоставен от SMSBump.
Юлиян Димитров е CTO на SMSBump и първият софтуерен инженер в компанията, който участва в изграждането на инфраструктурата и технологичната визия.
Как създадохме SMSBump?
Към днешна дата SMSBump е на 7 години, но искам да ви върна към най-ранната фаза на съществуването на продукта.
През 2015 година Михаил Стойчев и Георги Петров решиха да дадат нов облик на кратките текстови съобщения (SMS), превръщайки ги в канал за маркетинг и комуникация.
Първоначалната цел беше да направим улеснен начин за API интеграция към универсални e-commerce платформи. Създадохме SMSBump, продукт, насочен предимно към клиенти с технически познания. Това обаче постави известни ограничения, за да може клиентът да направи нужната интеграция за бизнеса си.
Именно тези ограничения ни накараха да оставим идеята на заден план за известно време, докато не взехме решение, че главната цел е продуктът да стане достъпен за онлайн магазините, а това би могло да стане само чрез създаването на нужните модули и разширения към всяка една e-commerce платформа.
2. Пътят към E-commerce платформите
Първата интеграция, която създадохме беше за платформата OpenCart, защото това беше основният пазар за компанията, а и вече имахме опит с нея. Естествено, това беше крайно недостатъчно. Пазарът беше много малък и концентриран специфично за тази e-commerce платформа.
Тогава се роди идеята да направим интеграция с BigCommerce. Платформата работеше доста сходно с модула за OpenCart, като разликата беше, че вече е самостоятелно приложение. PHP Framework-ът, който използвахме беше Slim Framework и дори беше на споделен сървър на известна българска хостинг компания.
Тук отново не пожънахме успех, тъй като пазарът на BigCommerce е предимно насочен към Enterprise компании, а ние не бяхме готови да предложим функционалностите за фирми от такава категория.
3. Първото приложение за Shopify
През 2016 година платформата Shopify стана доста популярна в сегмента за онлайн магазини и това ни накара да преосмислим целия продукт. Целта ни беше да предоставим готово решение за нашите потребители, с което бързо и лесно да създават успешни SMS кампании.
Тогава, като първия софтуерен инженер в SMSBump, започнах вече да виждам смисъл зад идеята и отделих доста време за новата версия на продукта. По спомен, около 6 месеца.
Създадохме приложението на един нает сървър (дроплет) в DigitalOcean, който съдържаше уеб сървър, PHP приложението, процеси на заден фон и база от данни. Дори тогава за първи път започнахме да използваме Version Control (Git). Използвахме Apache за уеб сървър и MySQL за съхранение на изпратените съобщения и да, отново да подчертая, всичко беше на един общ сървър. Дали беше от липса на опит, или заради нуждата от вземане на бързи решения, тогава това ни се струваше правилно.
4. Първият Черен петък
Бих го определил като наистина “черен”, защото не се справихме добре.
Въпреки че функциите на продукта не бяха много, само една беше достатъчна, за да привлече първите ни потребители: автоматизираните напомнящи съобщения за изоставени колички. Никой от нас не очакваше такъв интерес. Сървърът ни беше натоварен на 100% и не успяхме да изпратим всички кампании, а дори бих казал, че изпратихме не повече от 10-20 кампании.
От една страна това беше първият ни голям провал, а от друга беше и сигнал за нас, че идеята зад продукта е добра, но трябва да инвестираме много в стабилност и скорост.
5. Отделяне на Базата от данни от основния сървър
След провала на Черния петък наехме допълнителен сървър, който да се грижи единствено за базата от данни. В нея се пазеше абсолютно всичко за нашите клиенти: маркетингови кампанни, изпратени съобщения, потребители, цени и т.н. Започнахме да разделяме различни големи функционалности на отделни сървъри, като кодът беше абсолютно еднакъв за всички тях, с тази разлика, че стартираха различни процеси нужни за целта.
Тогава неизбежно се превърнах в системен администратор, който трябваше ръчно да оркестрира всеки един сървър, да прави нужните конфигурации и да рестартира различни процеси при промяна на кода. Имахме 5 различни сървъра, които нямаха никакви автоматизации, имаха нужда от постоянна поддръжка и в резултат забавяха разработването на нови функционалности. Не беше оптимално по никакъв начин, защото трябваше едновременно да се пишат нови функционалности и да се поддържат всички сървъри напълно ръчно. А все още бяхме само аз и Мишо.
Тогава ни стана ясно, че имаме нужда от още хора, тъй като аз като програмист и системен администратор не можех да наваксам със всичко. Към екипа се присъедини Евгени Колев, като той в момента е Team Manager в компанията и един от най-опитните ни инженери.
Откъм технологии тогава за Load Balancing използвахме HaProxy за уеб заявки и един общ Redis сървър, който се грижеше за консистентността на потребителските сесии между всички уеб сървъри. Разполагахме със споделено дисково пространство за статични ресурси, което се “закачаше” към всеки един от сървърите.
Всичко изглеждаше добре докато не дойде следващият Черен петък, който отново ни напомни, че все още не сме там, където искахме. Изпратихме доста кампании, но имаше и такива, които не успяхме да обработим. Липсваха основни концепции като автоматично скалиране, мониторинг и правилно дистрибутиране на кампаниите.
Най-интересното беше, че по време на Черния петък ръчно селектирахме кои кампании да изпратим, рутирахме ги посредством промени по кода и рестартирахме процесите, за да се обработят новите кампании. Мога да кажа, че беше ден с много стрес, но и такъв, който ни даде добър урок и ни показа как трябва да се приоритизират правилно кампаниите една спрямо друга.
Loading …
София
Fully Remote
2 000лв. – 3 000лв.
6. “Разделяй и владей”
Въпреки че повечето компоненти бяха разделени, имаше много операции, които утежняваха основната база от данни. Започнахме да разделяме информацията за платформите в друга база от данни, тъй като тогава въведохме като функционалност и сегментация на телефонните абонати, която сама по себе си е доста тежък процес.
Създадохме реплики на базите от данни, защото маркетинговите кампании започнаха да стават все повече и по-големи. Все още ги управлявахме напълно ръчно, а самите резервни копия също правихме доста примитивно, тъй като сами си пишехме скриптове, които всеки ден правиха mysqldump на базите от данни на диск за съхранение на данни.
Не залагахме много за инфраструктура. Не ставаше и дума да се използват оркестратори, контейнеризации и т.н. Docker и Kubernetes изобщо не фигурираха в плановете ни за развитие. Основната ни цел беше да се борим с конкуренцията и да сме лидери в Shopify като маркетингова платформа за изпращане на текстови съобщения с голяма възвръщаемост за клиентите. Акцент в работата ни беше да “бълваме” функционалности и да правим неща, видими за крайния потребител, защото това продаваше.
Supervisor беше основният мениджър на процесите на всички сървъри и го управлявахме отново ръчно. Създадохме си панел, който премахна нуждата да влизаме всеки път с SSH интерфейс на всеки един сървър, за да видим какво става с него, кои процеси работят и кои не. От него можехме да рестартираме процеси и да виждаме статуса на всяка една услуга.
Логовете от всички сървъри и процеси също се намираха там. Използвахме rsyslog, за да ги централизираме.
7. Първият успешен Черен петък
През 2019 година беше първият ни успешен “Черен петък”. Бяхме пораснали до 12 служители, като 6 от тях бяха технически лица, а останалите се занимаваха с маркетинг и обслужване на клиенти.
Вече знаехме, че ни очаква голям трафик и бяхме подготвени. Маркетинг екипът беше подготвил доста материали за това как клиентите правилно да подготвят кампаниите си и ги съветваха как да ги пуснат. Екипът за обслужване на клиенти беше на разположение 24/7 като имахме под 5 минути време за отговор. Техническите лица бяхме подготвили всички системи предварително като заделихме повече ресурси за нашите сървъри. Организирахме се всички да бъдем в офиса и направихме график кой за какво ще отговаря и кога. Например, аз отговарях за стабилността и мониторинга, а друг за приемане на въпроси от клиенти, свързани с функционалността.
Пътят към Yotpo и нова архитектура
В началото на 2020 година се отвори напълно нова страница за SMSBump, защото компанията беше придобита от друга маркетингова платформа – Yotpo.
Сливането с Yotpo дойде с много нови идеи, които искахме да реализираме в SMSBump, защото вече имахме сигурността на голямата компания и можехме да си позволим да изградим архитектурата, която искахме. Започнахме да мигрираме постепенно към Amazon Web Services. Наехме си DevOps, с когото поставихме основите на контейнеризацията с Docker. Използвахме концепцията Infrastructure as Code с помощта на Terraform и най-накрая въведохме възможността за автоматично скалиране на различните услуги.
Това, естествено, не беше лесно. Отне ни около 6 месеца да направим миграцията от DigitalOcean към AWS. Не можехме просто да преместим всичко от едното място на другото, защото вече решихме, че трябва да спазваме конвенциите в бранша и да използваме максимално най-новите технологии. Имаше много код за рефакториране, за да работят услугите по новия начин.
В процеса на миграция се възползвахме максимално много от услугите на AWS, което намали поддръжката на инфраструктурата от наша страна. Такива примери са: ECS, Fargate, EventBridge, SQS, OpenSearch (ElasticSearch), RDS MySQL, ElastiCache и т.н.
Използването на Serverless услуги като Lambda и ApiGateway ни дадоха по-голяма сигурност, че не е нужно да мислим за хардуера, а можехме да се концентрираме предимно върху самото изграждане на кода.
9. Къде сме сега?
Две години след придобиването SMSBump затвърди позициите си на пазара и успяхме да се задържим като най-добрата платформа за изпращане на кратки текстови съобщения.
Технологичната група не е променена. 90% от SMS продукта е на PHP, като основната версия е 7.4, но постепенно започваме да мигрираме към PHP 8. Основният PHP Framework е CakePHP.
Разполагаме с няколко по-малки serverless приложения, които са на NodeJS. Front-end частта е изцяло на ReactJS.
За бази от данни използваме MySQL RDS, Aurora MySQL, OpenSearch (ElasticSearch), ElastiCache (Redis) и DynamoDB.
За мониторинг и трейсинг имаме интеграции с Grafana, Prometheus, NewRelic и AWS CloudWatch.
Голяма част от монолитното приложение вече разделяме на различни microservice-и и това ни позволява домейнизирането на различните R&D екипи в компанията. Това ни улеснява да изградим автономност във всеки един от екипите и предоставя нужната свобода на всеки един от нас да реализира функциите си без помощта на другите екипи.
Активно пишем Unit, Component, Integration и Е2Е тестове, което означава по-голяма сигурност при пускането на новия код за потребителите.
Започнахме постепенно проучване за замяна на оркестратора от ECS към Kubernetes, защото това ще ни даде повече възможности за мониториране и по-лесна интеграция с останалите продукти на Yotpo.
10. Финални думи
Доста често ми задават въпроса дали ако бях с опита от днес бих направил нещо по-различно в миналото. Честно казано не бих, защото този начин на мислене ни помогна за много кратко време да създадем продукт, който веднага даваше стойност за потребителите. Вглъбяването в изграждането на перфектната инфраструктура щеше да ни дръпне много назад и щяхме да имаме перфектна инфраструктура, но малко клиенти.
Въпреки че вече сме близо 100 души в SMSBump, се радвам, че ДНК-то на компанията е все още същото и имаме същата мотивация както преди.
Ако намирате себе си в тази история, искате да станете част от динамичната среда и да правим иновативни неща заедно, присъединете се към Yotpo SMSBump.
