Падлучаны прадукт можа выглядаць завершаным задоўга да таго, як будуць завершаны адпаведныя распрацоўкі. Прататып стабільны, дадзеныя паступаюць у воблака, праграма паказвае правільныя значэнні, і першая партыя прылад ужо ў руках карыстальнікаў. На гэтым этапе бэкенд можа быць дастаткова простым, каб каманда ведала амаль кожную прыладу асобна. Забеспячэнне можна ажыццяўляць з дапамогай сцэнарыя, змены канфігурацыі можна ўносіць уручную, а калі нешта выходзіць з ладу, інжынер звычайна можа непасрэдна адсачыць праблему.
Затым яно павінна пачаць жыць у рэальным свеце. З'яўляецца другая рэвізія абсталявання. Некаторыя кліенты ўсё яшчэ карыстаюцца першай рэвізіяй. Версіі прашыўкі пачынаюць адрознівацца. Для іншага кліента або рынку патрэбна новая канфігурацыя, у той час як старыя прылады ўсё яшчэ патрабуюць абнаўленняў і падтрымкі.
Нічога не абавязкова зламалася. Праграмнае забеспячэнне, якое стаіць за прыладай, проста набыло свой уласны жыццёвы цыкл.
Гэты пераход лёгка прапусціць, бо прататып можа працягваць выдатна працаваць. Але як толькі некалькі версій аднаго і таго ж фізічнага прадукту павінны суіснаваць у палявых умовах, бэкенд перастае быць проста інфраструктурай за абсталяваннем. Ён становіцца часткай самой архітэктуры прадукту.
Працуючы падлучаны прататып яшчэ не з'яўляецца маштабуемым прадуктам
Прататып мае важную задачу: даказаць, што сістэма працуе ад пачатку да канца. Прылада выконвае сваю асноўную функцыю, прашыўка ўзаемадзейнічае з бэкэндам, тэлеметрыя паступае туды, куды павінна, каманды адпраўляюцца назад, а мабільны або вэб-інтэрфейс адкрывае функцыянальнасць карыстальніку.
Звычайна гэта не даказвала, наколькі добра адна і тая ж сістэма спраўляецца з разнастайнасцю.
Першыя дваццаць прылад могуць працаваць з аднолькавай прашыўкай, быць сабранымі на адной і той жа рэвізіі абсталявання і настроенымі аднымі і тымі ж інжынерамі. На гэтым этапе цалкам разумным можа быць ручная рэгістрацыя, непасрэдныя змены канфігурацыі або невялікі сцэнар адаптацыі. Стварэнне інструментаў вытворчага ўзроўню да таго, як прадукт зарэкамендаваў сябе, можа быць заўчасным.
Маштаб змяняе праблему. Прылады застаюцца афлайн, замяняюцца, працуюць з рознай прашыўкай і патрабуюць розных канфігурацый кліентаў. Служба падтрымкі павінна адрозніваць прыладу, якая ніколі не была правільна настроена, ад той, якая няправільна настроена або проста недаступная.
Запазычанасць па прататыпах часта пачынаецца менавіта так: не з дрэннага рашэння, а з часовага, якое застаецца ў сіле пасля таго, як прадукт пераходзіць на іншы ўзровень. І адна з першых рэчаў, якая прымушае гэты пераход кідацца ў вочы, — гэта само абсталяванне. Новая рэдакцыя не проста замяняе старую; яна павінна суіснаваць з ёй.
Кожная рэвізія абсталявання стварае праблему жыццёвага цыклу праграмнага забеспячэння
Новая рэвізія абсталявання рэдка з'яўляецца чыстай заменай старой. На практыцы абедзве версіі застаюцца ў эксплуатацыі, часам гадамі. Дадайце пераходны пакет, некалькі галін прашыўкі і канфігурацыі, спецыфічныя для кліента, і парк хутка становіцца больш разнастайным, чым прадугледжвае зыходная мадэль прадукту.
Праграмны ўзровень больш не можа разглядаць кожную адзінку як абстрактную «прыладу». Яму трэба ведаць, на што здольная гэтая канкрэтная адзінка.
Перапрацаваная плата можа выкарыстоўваць іншы датчык, модуль сувязі або кантролер. Каманда, якая дзейнічае для апошняй версіі, можа не падтрымлівацца папярэдняй. Значэнні каліброўкі могуць змяняцца. Межы канфігурацыі могуць зрушыцца. Пакет прашыўкі, прыдатны для аднаго пакалення, можа быць небяспечным для іншага.
Інжынеры фізічных прадуктаў ужо працуюць такім чынам. Два кампаненты, якія выглядаюць амаль аднолькава, неўзаемазаменныя, калі іх версіі, дапушчэнні або спецыфікацыі адрозніваюцца. Падключаныя прадукты ствараюць тую ж праблему з боку праграмнага забеспячэння: платформе патрэбен надзейны спосаб разумення, з якой версіяй фізічнага прадукту яна мае зносіны і якія правілы да яе прымяняюцца.
Уявіце сабе прадукт, у першай версіі якога выкарыстоўваецца адна працэдура каліброўкі, а ў другой — новы датчык і іншы набор параметраў. Для кліента абедзве прылады могуць быць аднолькавымі. Для платформы яны такімі не могуць быць.
Калі гэтыя адрозненні не прадстаўлены відавочна, яны, як правіла, прасочваюцца ў логіку прыкладання як асаблівыя выпадкі. Адзін працоўны працэс правярае дыяпазон серыйных нумароў. Іншы выкарыстоўвае версію прашыўкі ў якасці проксі-версіі для генерацыі абсталявання. Трэці змяшчае выключэнне, дададзенае пасля таго, як служба падтрымкі выявіла старую партыю, якая паводзіла сябе інакш у палявых умовах. Ніводнае з гэтых выпраўленняў не выглядае асабліва небяспечным само па сабе, але разам яны робяць кожную будучыню змену больш складанай для абгрунтавання.
Старое абсталяванне рэдка знікае па раскладзе. Каманды распрацоўшчыкаў прадуктаў, натуральна, засяроджваюцца на найноўшых рэвізіях, у той час як кліенты часта захоўваюць папярэднія версіі значна даўжэй, чым чакалася. Такім чынам, платформа павінна падтрымліваць некалькі пакаленняў адначасова, а не меркаваць, што ўсталяваная база калі-небудзь сыдзецца ў адзін бягучы стан.
Як толькі гэта адбудзецца, развіццё абсталявання і кіраванне жыццёвым цыклам праграмнага забеспячэння стануць непадзельнымі. Платформа павінна ведаць не толькі дзе знаходзіцца прылада і ці падключана яна да Інтэрнэту, але і што яна сабой уяўляе, што на ёй можа працаваць, як яе трэба наладзіць і якія змены бяспечна ўжываць.
І перш чым на любое з гэтых пытанняў можна будзе даць надзейны адказ, кожная прылада павінна ўвайсці ў сістэму паслядоўным чынам.
Забеспячэнне — гэта тое, дзе ручная інжынерыя спыняе маштабаванне
Калі парк прылад невялікі, працэс падрыхтоўкі выглядае проста: стварыць запіс прылады, увесці серыйны нумар, стварыць уліковыя дадзеныя, прызначыць прыладу кліенту, прымяніць канфігурацыю і рухацца далей. Для некалькіх дзясяткаў прылад ручное кіраванне часткай гэтай працы ўсё яшчэ можа быць правільным выбарам.
Аднак у вытворчым маштабе забеспячэнне знаходзіцца на скрыжаванні ідэнтыфікацыі прылады, уліковых дадзеных, уласнасці, канфігурацыі і стану жыццёвага цыклу. Памылка, дапушчаная падчас адаптацыі, можа паўплываць на тое, як прылада працуе і падтрымліваецца доўга пасля таго, як яна пакінуць завод.
Табліца можа больш не адпавядаць таму, што фактычна ўсталявана. Прылада для замены павінна мець правільную асацыяцыю з кліентам, не ўспадкоўваючы няправільную ідэнтыфікацыю. Скід да заводскіх налад стварае яшчэ адзін шлях у працэсе. Усталёўшчык можа прызначыць прыладу няправільнаму ўліковаму запісу, пакідаючы службу падтрымкі, каб вызначыць, ці не знаходзіцца яна ў аўтаномным рэжыме, ці няправільна настроена яна, ці проста мае няправільную канфігурацыю.
Пасля таго, як для адказу на гэтыя пытанні распрацоўшчык рэгулярна правяраў базу дадзеных або запускаў унутраны скрыпт, працэс перастаў маштабавацца разам з прадуктам.
Дубляванне — яшчэ адзін папераджальны сігнал. Кожны варыянт прадукту пачынае набываць свой уласны сцэнар адаптацыі, інструмент канфігурацыі або працоўны працэс усталёўшчыка. Гэтыя адрозненні могуць здавацца нязначнымі, але асноўная адказнасць аднолькавая. Забеспячэнне стала шматразовай інфраструктурай платформы, а не задачай налады, прывязанай да канкрэтнай прылады.
І гэта рэдка адзіная магчымасць, якую трэба выкарыстоўваць паўторна.
Платформавы ўзровень павінен стаць інфраструктурай паўторнага выкарыстання
Пасля таго, як некалькі прадуктаў або версій абсталявання маюць аднолькавыя асноўныя патрэбы, некаторыя праграмныя магчымасці перастаюць быць спецыфічнымі для прадукту. Добрымі прыкладамі з'яўляюцца ідэнтыфікацыя прылад, забеспячэнне, падключэнне, тэлеметрыя, дастаўка прашыўкі, стан жыццёвага цыклу, бачнасць парку прылад і дыягностыка. Іх перабудова для кожнага новага варыянту стварае больш кода і больш аперацыйных шляхоў для абслугоўвання, не робячы сам прадукт больш адметным.
Каманды рэдка спрабуюць стварыць такое дубліраванне. Невялікія адрозненні назапашваюцца вакол кожнага прадукту, пакуль каманда не будзе падтрымліваць некалькі рэалізацый таго, што стала адной і той жа інжынернай адказнасцю.
Больш выразная мяжа заключаецца ў аддзяленні прадуктовага ўзроўню ад платформеннага ўзроўню. Прадуктовы ўзровень утрымлівае паводзіны, працоўныя працэсы, інтэрфейсы, інтэграцыі і логіку дамена, якія робяць пэўную прыладу каштоўнай. Платформенны ўзровень апрацоўвае механіку, якая павінна заставацца паслядоўнай нават пры змене абсталявання.
Па меры таго, як падлучаныя прадукты выходзяць за рамкі першага выпуску, забеспячэнне прыладамі, кіраванне жыццёвым цыклам прылад, кіраванне паркам прылад і інструменты падтрымкі становяцца агульнай інфраструктурай, а не аднаразовымі дэталямі праекта. IoT PaaS для прадпрыемстваў можа забяспечыць гэты шматразовы ўзровень платформы для некалькіх прадуктаў або варыянтаў прадуктаў, апрацоўваючы стандартныя прылады і кіраванне дадзенымі з дапамогай шматразовых будаўнічых блокаў, у той час як інжынерныя каманды засяроджваюць свае намаганні на абсталяванні, працоўных працэсах і карыстальніцкім досведзе.
Агульная аснова ўсё ж павінна пакідаць месца для рэальных адрозненняў у прадуктах. Новай прыладзе можа спатрэбіцца іншая мадэль дадзеных, паток канфігурацыі, інтэграцыя або логіка кіравання, і гэтыя адрозненні павінны заставацца лёгка ўкараняльнымі. Мэта проста ў тым, каб пазбегнуць таго, каб кожнае адрозненне цягнула за сабой яшчэ адзін рэестр прылад, канвеер тэлеметрыі, механізм забеспячэння або набор інструментаў кіравання паркам прылад.
Платформа можа выглядаць як нешта непатрэбнае, пакуль каманда стварае першы прадукт, і як актыў да другога ці трэцяга. Пасля таго, як агульныя аперацыйныя механізмы будуць наладжаныя, новы варыянт можа атрымаць у спадчыну працоўную аснову, замест таго, каб пастаўляцца з іншым бэкэндам, які камандзе давядзецца падтрымліваць да канца жыцця гэтага прадукта.
Захоўвайце індывідуальную распрацоўку там, дзе прадукт сапраўды адрозніваецца
Платформа шматразовага выкарыстання не павінна рабіць падлучаныя прадукты больш агульнымі. Яе задача — пазбавіцца ад паўторнага праектавання тых частак, якія не ствараюць дыферэнцыяцыі.
Намаганні па распрацоўцы персанальных дадзеных усё яшчэ тычацца паводзін прылад, логікі, спецыфічнай для дамена, працоўных працэсаў, карыстальніцкага досведу, спецыялізаваных інтэграцый і таго, як пэўны прадукт узаемадзейнічае з фізічным светам. Гэта менавіта тыя вобласці, дзе інжынерныя рашэнні могуць зрабіць адзін прадукт значна лепшым за іншы.
Рэдка калі заслугоўвае аднолькавага стаўлення да навакольнага аперацыйнага сантэхнічнага абсталявання. Базавая і прамысловая версіі адной і той жа машыны могуць патрабаваць розных датчыкаў, элементаў кіравання і інтэрфейсаў, але яны не павінны патрабаваць асобных спосабаў ідэнтыфікацыі прылад, адсочвання версій прашыўкі або кіравання паркам прылад.
Я б аддаў перавагу бачыць, як інжынеры марнуюць гэты час на ўдасканаленне паводзін прадукту ў палявых умовах, чым на перабудову механікі, якія ўжо ёсць у каманды для іншага прадукту. Агульная аснова не памяншае магчымасці для распрацоўкі на заказ; яна абараняе гэтыя намаганні ад марнавання на інфраструктуру.
Сапраўднае выпрабаванне пачынаецца, калі каманда пачынае працаваць над прадуктам нумар два.
Добрая платформа робіць наступны прадукт прасцейшым за першы
Калі прадукт нумар два патрабуе амаль такой жа працы на платформе, як і прадукт нумар адзін, то насамрэч вельмі мала што было выкарыстана паўторна.
Новы варыянт павінен мець магчымасць успадкаваць тыя часткі аперацыйнай мадэлі, якія не змяніліся: працэсы забеспячэння, ідэнтыфікацыю, механіку жыццёвага цыклу, інструменты парку, працэсы прашыўкі, бачнасць падтрымкі і агульныя інтэграцыі. Затым інжынерныя намаганні накіроўваюцца на вырашэнне адрозненняў — магчыма, новы пакет датчыкаў, іншы працоўны працэс кіравання або інтэграцыя, спецыфічная для кліента — замест таго, каб перабудоўваць аснову.
Новае пакаленне абсталявання стварае большы ціск на тую ж ідэю. Яго магчымасці могуць істотна змяніцца, пакуль старыя прылады застаюцца актыўнымі. Дасведчаная платформа можа падтрымліваць абедзве, не прымушаючы каманду падтрымліваць два асобныя стэкі платформаў для таго, што кліенты ўсё яшчэ ўспрымаюць як адно сямейства прадуктаў.
Ні для чаго з гэтага не патрабуецца адзін маналітны бэкенд. Розным прадуктам усё яшчэ могуць спатрэбіцца выразныя архітэктурныя межы. Галоўнае — пазбегнуць паўторнай рэалізацыі той жа інжынернай задачы без важкай прычыны.
Менавіта тады платформа становіцца актывам, а не назапашанымі накладнымі выдаткамі. Служба падтрымкі мае менш паралельных інструментаў для разумення, рэлізы ідуць больш паслядоўнымі шляхамі, а даданне чарговага прадукту становіцца кантраляваным пашырэннем, а не чарговым бэкэндам, які кампанія атрымлівае ў спадчыну на нявызначаны тэрмін.
Разглядайце платформу як частку архітэктуры прадукту
Фізічныя прадукты распрацоўваюцца з улікам магчымасцей перагляду, зручнасці абслугоўвання, тэхналагічнасці і будучых змяненняў. Падключаныя прадукты патрабуюць такой жа дысцыпліны з боку праграмнага забеспячэння.
Першы бэкенд можа быць часовым. Гэтак жа можа быць і першы скрыпт падрыхтоўкі або інструмент падтрымкі. У гэтым няма нічога дрэннага. Праблемы пачынаюцца, калі гэтыя часовыя механізмы ціха становяцца пастаяннай архітэктурай, у той час як сам прадукт працягвае развівацца.
Да таго часу падлучаны прадукт — гэта ўжо не проста абсталяванне, прашыўка і праграма. Ён таксама залежыць ад інфраструктуры, якая ідэнтыфікуе кожную прыладу, разумее яе магчымасці, прымяняе правільную канфігурацыю, падтрымлівае абнаўленні і дапамагае камандам дыягнаставаць праблемы праз гады пасля адгрузкі.
Як толькі гэты ўзровень разглядаецца як архітэктура прадукту, падзел становіцца больш зразумелым: стандартныя механікі можна выкарыстоўваць паўторна, у той час як кастомная праца заключаецца ў тым, што фактычна адрознівае адзін прадукт або сямейства прадуктаў ад іншага.
Наймацнейшая платформа — гэта не проста тая, якая дазваляе стварыць першы падлучаны прадукт. Гэта тая, якая дазваляе камандзе інжынераў ствараць другі, трэці і чацвёрты, не маючы ў спадчыну кожны раз новы бэкенд.
