Чому ринок saas йде не в ту сторону. частина перша: бази даних - 15 Березня 2011

Мій сайт

Головна
Реєстрація
Вхід

Головна » 2011 » Березень » 15 » Чому ринок saas йде не в ту сторону. частина перша: бази даних

23:13

Чому ринок saas йде не в ту сторону. частина перша: бази даних

Як і обіцяв, публікую другу статтю.

Частина перша | Частина друга

Про себе

Спочатку розповім трохи про себе. П'ять днів тому я вперше вирішив вилізти зі своєї тюменської барлогу на світло божий (хабрасвет), і ця вилазка стала ще одним цікавим подією мого життя. Спершу, звичайно ж, клацнули по носі. І я пішов у мінус. Подумав, і пізніше трапилося якесь диво, і відбулася битва добра і зла, а може відбулася битва благодушній довірливості більшості хабрачітателей і суворої обізнаності меншини хабраекспертов. Рахунок вийшов 232:119.

Взагалі в цій статті все буде неправильно. Неправильне введення. Я неправильно зізнаюся у своїй некомпетентності, хоча міг би відмінно пустити пил в очі. Я ображу багатьох дуже розумних людей, причому ображу необережно і за своєю дурості. Я викличу до себе ставлення не як до глибокого і вдумливого оповідачеві , а як до поверхневого инфантильному юнакові, ніколи не нюхали цієї важкої серверної пилу. Нарешті, я помилюся в багатьох професійних термінах, помилюся у формулюваннях і фактах, а в коментарях напишу багато рідкісної нісенітниці. І навіть час я вибрав невдалий для таких речей (вихідні ).

З'явиться кілька розсудливих людей, які скажуть: «краще б ти нічого не писав» або «не робіть так більше» (с). Так, мені дійсно зараз краще нічого не писати, а залишатися на цілком пристойному 361 - м місці Хабра, зрідка повчаючи інших. І щойно я втратив цей рейтинг, тому що порушив сказане мені в приват перше правило клубу - ніколи не говорити про карму. Хабраеффект від попередньої статті можна було добре сконвертувати в якісь навіть матеріальні речі, наприклад пристойну роботу, або як було запропоновано в тих коментарях деякі грошові плюшки. Так, рейтинг не так і багато значить для мене, і я жертвую його в обмін на свою принциповість і бажання поділитися своїми роздумами про ІТ.

Стаття

«Чому ринок SaaS йде не в ту сторону (частина 1), або чому Oracle це повна лажа і маст дай»

Ліричний відступ

Я знову повернуся в той самий 2003 рік, і знов згадаю деякі речі з розмов з друзями. Справа в тому, що по життю я невдаха, можна навіть сказати лузер. Тоді в 2002 ми закінчили університет, і мої друзі змінили практику в Тюменський банках на цілком постійні банківські посади. Я ж ніяк не міг знайти роботу. Причина, як пізніше я зрозумів, полягала в тому, що я почав підробляти (а точніше навіть працювати безкоштовно, з інтересу) вже на другому курсі університету, що і погубило мою кар'єру у фінансах. Там я навчився робити сайти (на чистому html / css), освоїв графічні програми, освоїв локальні мережі, Windows NT, інтернет, і цілком уже просунувся від енікейщіков до базових знань системного адміністрування. Точніше сказати я обслуговував один корпус нашого університету (близько 40 комп'ютерів) і зробив і підтримував сайт для нашого інституту. І пару років трохи навіть вже грав з лінуксом. Це все я написав у резюме, тому як у мене не було практики в банківській сфері. Тобто ви можете уявити, як це було смішно. Я приходжу в банк, віддаю своє резюме, і там написано ці смішні слова від Фотошопа до Лінукса, що зараз стало вже просто класикою дилетантства. Вони питали, чи знаю я Оракл, і я відповідав, що якщо треба, то вивчу :-). Цілковитий треш. Я не підходив з моєю освітою ні на роль планктону в економічний відділ, ні на роль помічника сисадміна в технічний. Коротше, я тупо не міг знайти собі роботу. І тоді, пам'ятаю, йшов я понурий по нашій площі Леніна з друзями і розмовляв. Варто мені рипатися далі (мені відмовили в десяти банках міста), або вже йти шукати роботу за компам. Вибір вийшов у бік ІТ. Я вирішив проапгрейдить свої знання сам. Розібрався з новим на той момент PHP. Розібрався в MySQL. Прочитав Хаутен і хендбукі по Лінукса і фре, і навіть вже вдома працював у слакварі як в основній OS. І через два місяці пішов найматися за оголошенням в інтернеті вже в інший наш вуз. Мене прийняли на зарплату в 4000 руб. Там не було ні PHP, ні MySQL принципово. Але через тиждень я здав першу роботу начальнику (веб-обв'язку для постгреса на perl). Пізніше я ще щось вивчав і заробляв на сайтах середнього штибу вже сам аж до 2006 року. На поточному місці роботи з напрямків СУБД я вчився на парі-трійці хороших курсів з Oracle і MS SQL (Академія АйТі, рекомендую), і зараз з базовими навичками адмін обидві СУБД на роботі в деяких ІС. Ви дивується, навіщо я це розповідаю. Та так, просто хочу сказати, що ніяких системних знань в комп'ютерній галузі у мене немає. Але досвід певний є і в Веб, і на десктопі, і він досить широкий і практичний.

Кому адресується ця стаття. Це стаття зовсім не адресується веб-програмістам або адміністраторам СУБД. Це стаття адресується тим, хто продає якісь софтові або залізні речі на ринку SaaS, хто торгує (не адмін) хостингом і VPS, хто збирається випустити свої хороші й добрі програми з архітектури клієнт-сервер, заробляти на продажу інформації кінцевим споживачам або ж продажу інформаційних сервісів для інших сайтів.

Ретроспектива, аналіз архітектурних рішень СУБД і трохи філософії

Якщо озирнутися назад, то, здавалося б, нічого надважливого не відбулося з ринком СУБД за останні двадцять, а може бути і тридцять років. Ринок СУБД, саме поняття СУБД, це спроба розмежувати інтелектуальні ресурси для побудови інформаційної системи. Іншими словами, СУБД звільняє архітектора інформаційної системи від головного болю з приводу зберігання великих обсягів даних, вирішує питання продуктивності чужим геніальним розумом, вирішує питання безпеки і розподілу ролей. Це з одного боку. З іншого, в клієнт-серверної моделі СУБД дозволяє відокремити інформацію від програмної частини. Тобто у нас є інформація, яка знаходиться в центрі всієї інформаційної системи, і у нас є якісь механізми подання цієї інформації в людському вигляді, тобто фронт-енд ... Ще трохи відверну вас, і знову повторюся, що і цю статтю можна було вмістити в твіттер, причому умістити просто назвавши ... одне число. У мережі інтернет є багато знакових чисел. Особливих, спеціальних чисел. І є одне прокляте число для СУБД. Число, яке рушіло основи того, що залишили нам попередні покоління розробників.

Взагалі, в комп'ютерах набагато більше людського, ніж ми думаємо. У комп'ютерах намішані всі людські страхи, людські образи, звички і зобов'язання. Я абсолютно не психолог, але я постійно звертаю увагу на цей момент. Важливим відкриттям тут є те, що комп'ютерні технології змінюються разом з характером суспільства, змінюються услід за зміною менталітету. У наступних статтях я спробую поставити запитання - чому ми, нове покоління, зрадили мережу Інтернет. Ми його зрадили і в протоколах, і в архітектурі, і в залізі. Це буде образлива стаття для Циско.
Зараз стаття про Оракл, і я назву це число, хоча впевнений, багато хто вже здогадалися. Це число 127.0.0.1.
Зараз, в 2010 році відбулася колосальна деградація СУБД. СУБД, хоч і є основою для переважної більшості інтернет-сайтів, не виконують своєї споконвічної ролі абсолютно. Що відбувається в інтернеті. В інтернеті відбувається RSS і батько його XML. Я не буду зараз так глибоко копати в бік XML, скажу лише, що це саме ідіотське, що можна було придумати для обміну даними. Наші комп'ютерні дідуся сміялися б над нами, якби їм було цікаво дізнатися як влаштований інтернет зараз. Факт залишається в наступному: Розробники, Архітектори, Адміністратори баз даних бояться відкривати доступ до своєї СУБД. Я, як і ви, бачив багато реальних працюючих сайтів, але я чесно не бачив жодного разу, щоб хтось надавав чужим людям доступ безпосередньо через клієнт SQL, тобто безпосередньо до лістенеру або порту. Дають все що завгодно. Дають XML. Дають дампи баз. Дають і розробляють спеціальні формати обміну даними. Але от до СУБД доступ не дає ніхто. Бояться.

Докладніше

Я думаю все вже зрозуміло, і про що піде мова далі, але все ж опишу сьогоднішній бардак докладніше. У інтернетних базах даних, так само і в десктопних є система користувачів, є система ролей і схем доступу до даних. Є управління правами на основі користувачів. Є управління правами на основі уявлень. Є багато чого, і насправді в сучасних СУБД є навіть занадто багато всього відразу. Як ці можливості використовуються на практиці. Правильно. Створюється один користувач, часто навіть з ім'ям root, якому дають доступ до бази даних в режимі RW. І вже цей користувач використовується в подальшій програмної логіці і постачання даних у фронт-енд. Ви скажете, що це справа кожного, як організовувати доступ до своєї бази даних - на рівні додатку або на рівні СУБД, і я погоджуся, але зазначу, що з причини людської ліні, якихось психологічних, інтелектуальних моментів роблять саме за першою схемою, тобто один користувач на весь сайт. Сміливі, або навпаки ледачі програмісти роблять одного юзера а потім вже самі з вусами програмують свій сайт або програму, визначаючи доступ там. До чого це призводить. Це призводить до деградації ролі СУБД. Вона зараз виконує одну функцію, а саме є просто хорошим і швидким движком для зберігання плоских великих таблиць. І саме в цьому, в тому, що програмісти не довіряють СУБД, бояться всього спектру її можливостей, саме тому вони пишуть свою систему доступу, на рівні скриптів PHP, JS, PERL, Python, ASP та інше всім добре відомому - в цьому проблема великих баз даних. У цій практиці Оракл в 2000-і роки в інтернеті просто звалився під всією своєю вагою знань. Розробники бояться Оракл. Так, він швидше, він надійніший, він розумніший і продумано. У ньому ну просто гігантська купа всіх можливостей, яку не знають повністю ні адміністратори баз даних, ні тим більше програмісти. І тому інтернет вибрав MySQL. Він його вибрав просто жартома, як ще одну безкоштовну програмку з виробів OpenSource. Веб-програмістам не потрібен Оракл. Їм потрібна всього лише можливість швидко тягати дані з однієї-двох плоских таблиць для своїх невеликим систем. І в цьому MySQL переміг двічі. Він безкоштовний. Він простий. І хоча часто він вередує і падає під великим навантаженням - це питання далекого завтрашнього дня, який абсолютно не важлива для невеликих стартапів. Тепер я можу зробити другий висновок. Oracle загине. Точно так само, як збанкрутували і загинули фірмові операційні системи Sun, Novell, IBM, SCO. Ці могутні операційки з великими понтами програли маленькому, злегка глючной, але безкоштовним Пінгвіни. Точно так само і Оракл та інші його могутні брати в 2000-і програли глючной і Малахольна «м'язи» в Інтернеті. Звичайно, зараз Сан, а потім, відповідно Оракл прибрали цього «гігантського» малюка до рук. Але їх доля все одно незавидна, з простої причини, що архітектура і принцип продажу їх великих продуктів суперечить психології і стилю роботи розробників. Навіть якщо вони зараз будуть безкоштовно втюхувати свої безкоштовні Express версії, я не думаю, що тепер WEB підсяде на цей їхній наркотик.

Практична інформація

Йдемо далі. Я не буду горювати - добре це чи погано, що вийшло ось так, насправді це всього лише проблема Оракл і нікого більше.
Але я постараюся звернути увагу на цей момент тих, хто займається комерцією в інтернеті. Зараз є ну просто дуже гарний шанс вивести на ринок ще одну СУБД або переробити існуючу. Про що я кажу. Я кажу про те, що якщо ринок вибере (а він уже де-факто вибрав) XML / SOAP для обміну даних, то ми будемо ще двадцять років мучитися з цією фігньою. Так само, як ми тридцять років мучимося з e-mail, а саме зі спамом і долхлимі скриньок, тому що спочатку було не все продумано (не в той бік пішов, повертаюся). Іншими словами, зараз є можливість побудувати відмінні сайти (у первинному значенні цього терміна) з доступом не по HTML або XML, а з доступом по SQL. Так, це виглядає дико, смішно і безглуздо. Я не знаю чому не розвивається ця тема, можливо, я десь не побачив ну просто гігантську вагому причину чому так робити не можна. Так, все мені дадуть відповідь: «Та як ти посмів відкривати SQL назовні?! Це ж взагалі смішно і небезпечно! Його ж «завалять» через півгодини! »Так, завалять. Але це не проблема мови SQL, це проблема існуючих програмних продуктів.
А на основі SQL-сайтів можна робити дуже гарні речі, як з безкоштовною, так і платною інформацією. Тут кожен може пофантазувати сам, що саме можна продавати як базу з інформацією. Фінансові речі, котирування. Прогноз погоди. Геоінформаційні дані. Чи можна продавати через SQL дані про товари і послуги. Чи можна віддавати через SQL блоги або новини. На цю інформацію в такому зручному вигляді знайдеться багато бажаючих, як серед бізнесу site-to-site, так і серед бізнесу site-to-app. Тут нехай кожен подумає, а якщо хоче - зробить цікавий експеримент з не вимагає великих витрат старт-апом.

Як треба робити сучасні ІС

Тепер далі, трошки про інше. Про модель SaaS в інтернеті і на десктопі. Зрозуміло, що модель SaaS це спочатку інтернет-рішення. І зараз, із зростанням ширини інтернет-каналів відбувається якась конвергенція технологій і напрацювань зі світу Web і зі світу серверних додатків. Сама Microsoft і інші активно підтягуються до цього процесу.
Якщо подивитися на сучасний хостинг або продаж програмних рішень в офіс. Що пропонує хостер або девелопер. Він пропонує по суті один свій сервер, на якому є движок PHP або Python, або щось інше, неважливо. І він пропонує цей же сервер з базою даний. Іншими словами, сучасний хостер або девелопер пропонує свій сервер з проклятим числом 127.0.0.1. І тут мені здається, що є дуже велика ніша для підвищення продуктивності та безпеки продуктів. Що якщо прокачати базу даних, і трохи пересунути інтелектуальне рівновагу в бік СУБД ...

Інсталяція Оракл це жахливий процес. Оракл настільки кривий і незрозумілий розробнику середнього штибу (тобто мені), що я ніколи б не вибрав його, будь він хоч тричі безкоштовний. Але що якщо Oracle буде продавати готові СУБД, як зараз хостери продають готові MySQL на пару з phpAdmin ...
Тут доречно згадати про Amazon S3 або Google App Engine. І мікрософт зі своїми хмарами. Звичайно, поки це більше іграшки в ІТ, ніж реальні моделі заробляння грошей. Просто з причини, що поки девелопери не навчилися добре і свідомо кодіть під ці речі.
Але бази даних під існуючі десктопні мови можна продавати вже зараз.

Колись у 2003 році (так що ж це за рік такий) я робив сайт для Тюменського іподрому. Це був маленький сайтик з простою СУБД, практично одна табличка. І коштував він смішні п'ять тисяч рублів. У минулому році він зник за несплату, але бажаючі можуть на нього поглянути web.archive.org / web / * / http://ippodrom.tyumen.ru
Це дійсно маленький нічим не примітний сайтик. Якби не одне але. Цей сайт випробував на собі міцність невловимого джо MySQL. Всі ці роки цей сайт працював і редагували не тільки через Web-адмінку (з'явилася пізніше), але і через десктопну програму. Коли я його зробив, мені було дуже ліньки писати адмінку. Я працював в одній кімнаті з колегою, який писав велику систему на Дельфі. І мені раптом прийшла в голову ідея віддати цю роботу на аутсорс. Я відкрив базу MySQL назовні, тобто поставив%. А він за 1500 крб і за два дні накидав обв'язку до сайту, ось таку.

Чому ринок saas йде не в ту сторону. частина перша: бази даних

І ось таку CMS я віддав замовнику, а іноді і сам редагував сайт через неї. Дуже зручно. Навіщо я розповів ці дрібниці. Потім, що зараз з розвитком ринку SaaS на ринку праці буде ну просто велика армія незатребуваних фахівців з десктопних систем. І в цьому випадку, якщо піти за такою ж моделлю, можна зробити дві чудові речі. По-перше скоротити витрати на розробку програми, зробити його інтерфейс ідентичним Windows. А по-друге вказати СУБД її початкове місце, яке їй визначили наші діди. Тобто в центрі системи СУБД, а навколо різноманітні клієнти з доступом по SQL. Я, правда, не дуже впевнений, що ця модель буде головною. І навіть не впевнений що вона взагалі буде. Корпорації як і раніше будуть клепати сумовите гівно, імітуючи у своїх SaaS продуктах інтерфейс Windows на HTML. І як і раніше будуть продавати бідним бухгалтерам сервери з проклятим числом 127.0.0.1
Наступного разу розповім які саме додатки і як можна продавати методом SaaS вже зараз.

Власне, ось і весь розповідь. Спасибі за увагу :-)

UPDATE
Я бачу, що все-таки ця стаття зацікавила в першу чергу розробників, та обговорення перемістилося у бік оцінки ролі AJAX в сучасному інтернеті.