100% AI продукт които ако се направи правилно с правилните технологии а за подобен продукт Go, Rust са ключови за ядрото на Screenshot Service и Agents. Какви технологии използва този проект? База данни, Kafka ? За подобен сериозен проект ми звучи несериозно VPS сървърче?
Колко пари е изкарал има ли реални клиенти?
Подобен проект сам човек с 100 долара месечно може да го разработи за 2 месеца от до и да бъде както трябва.
Казвам го от опит с работата си по core на pingdom.
За това ме интересува как работи вашата система, какви технологии използва, репликации сървъри споделяне? Все пак няма да е ок система която следи дали други системи работят тя самата да не работи.
Поздрави
Здравей,
Благодаря за въпросите — напълно нормални са, особено ако човек гледа на проекта като на класически uptime продукт от типа Pingdom/UptimeRobot.
Само че EyeballMonitor не е просто “AI продукт” и не е само софтуер, който пингва сайтове. AI е използван като помощен инструмент в разработката, но стойността на системата не е в това. Стойността е в комбинацията от:
- реални физически агенти;
- реални ISP и мобилни мрежи;
- browser-based проверки;
- screenshot evidence;
- uptime monitoring;
- incident логика;
- API слой;
- възможност за интеграция в други панели и reseller продукти.
Да, съгласен съм, че за ядро на агентите, high-throughput screenshot service или event processing Go/Rust са много добър избор. Също така Kafka/NATS/Redis streams и отделни worker-и имат смисъл при голям обем. Това обаче е въпрос на етап и натоварване, не на това дали MVP/първата работеща версия трябва задължително да започне от enterprise архитектура.
В момента системата е изградена като работеща платформа с отделен hub/API, база данни, agent layer, screenshot storage, cron/worker логика, мониторинг резултати, админ панел, клиентски панели и интеграции. Screenshot файловете се държат извън базата и се качват в object storage. Агентите са реални машини/точки, не симулация от cloud регион.
За VPS-а — да, ако говорим за финален мащаб с хиляди клиенти и милиони проверки, един VPS не е достатъчен и никой не твърди обратното. Но за текущ етап, пилоти, API развитие, proof-of-concept и първи клиенти е напълно нормално да се започне с по-компактна инфраструктура и после да се раздели на:
- отделен API слой;
- отделна база;
- отделни worker-и;
- queue/event layer;
- object storage;
- репликация;
- monitoring на самия monitoring;
- multi-region failover.
Това е нормален еволюционен път. Много системи не започват от Kafka cluster и bare-metal HA архитектура в първия ден. Първо се доказва продуктът, use case-ът и пазарът, после се мащабира архитектурата.
Относно “сам човек със 100 долара на месец може да го направи за 2 месеца” — може да се направи демо, dashboard, ping service и някакъв screenshot worker. Това не е спорно. Но не това е трудната част. Трудната част е:
- реална мрежа от физически точки;
- SIM/ISP инфраструктура;
- поддръжка на агенти;
- браузърни screenshot проверки;
- различни държави и оператори;
- доказателствена история;
- incident flow;
- API за външни интеграции;
- търговски модел;
- договори, поддръжка и SLA;
- trust layer за клиента.
Ние не продаваме “код, който някой може да напише”. Ако беше само код, щях да се съглася с теб. Продуктът е инфраструктура + софтуер + агентска мрежа + evidence layer.
Идеята не е да се конкурира директно с Pingdom по това кой пингва най-бързо от cloud точки. Идеята е друга:
Повечето uptime системи казват: “сайтът работи”.
EyeballMonitor цели да покаже: “какво реално вижда потребителят през конкретна мрежа/ISP/локация”.
Това е особено важно при спорове от типа:
- “при нас сайтът работи”;
- “при клиента не се отваря”;
- “проблемът е в CDN”;
- “проблемът е в DNS”;
- “проблемът е само при конкретен мобилен оператор”;
- “проблемът е регионален”.
Точно там screenshot evidence от реална точка има стойност.
Относно клиенти и приходи — проектът е в преход от техническо изграждане към търговска фаза. Има интерес и разговори за B2B интеграции, включително сценарии за вграждане през API в други панели/услуги. Не го представям като зряла компания с голям текущ оборот, а като работеща система с изградена инфраструктура, която вече влиза в етап на реални партньорства и commercialization.
Съгласен съм, че ако проектът трябва да стане enterprise-grade, ще трябва:
- по-сериозна HA архитектура;
- queue layer;
- service separation;
- отделни worker pools;
- observability;
- replication;
- disaster recovery;
- ясни лимити на API;
- forensic-grade логика;
- вътрешен monitoring на самия EyeballMonitor.
Това е и пътят, по който ще се развива.
Но според мен не е коректно да се свежда до “AI продукт за 2 месеца и 100 долара”. Демо може. Реална мрежа от агенти, ISP/browser evidence, работещ API слой и бизнес около това — не е същото нещо.
Поздрави.
