Make թե Zapier․ նույն հոսքի հաշվարկը կարող է վեց անգամ տարբերվել

2sync-ի հրապարակած օրինակում ամսական մոտ 200 օրացուցային իրադարձություն և ութ դաշտ ընդգրկող երկկողմ հոսքի համար տարեկան վճարմամբ Make Core-ի ամսական համարժեքը $21 է, իսկ Zapier Professional-ինը՝ $129. փաթեթների գինը տարբերվում է ավելի քան վեց անգամ։ Օրինակը գնահատում է մոտ 12 000 credit-ի և 6 000 task-ի սպառում։ Սրանք հրապարակված սցենարի գնահատականներն են, ոչ ցանկացած համաժամացման հաստատուն սակագները։

Zapier-ը դիտարկեք, երբ հոսքը պարզ է, գործարկումների ծավալը փոքր է, իսկ արագ կառուցումն ու ոչ տեխնիկական աշխատակցին փոխանցելը կարևոր են։ Make-ը հաճախ ավելի հարմար ընտրություն է ծավալուն, ճյուղավորվող կամ հաճախ փոփոխվող հոսքի համար, եթե թիմը կարող է ժամանակ հատկացնել դրա կառուցմանն ու սպասարկմանը։ Երկու դեպքում էլ բաժանորդագրության գինը պետք է համեմատել նույն հոսքի իրական աշխատանքային ծավալի հետ։

Ինչպես են ստացվում տարբեր թվերը

Հրապարակված օրինակում Make-ի համար ընտրված է 20 000 credit-ի, իսկ Zapier-ի համար՝ 10 000 task-ի սահմանաչափով փաթեթ։ Գնահատված սպառումից հետո մնում է համապատասխանաբար 8 000 credit և 4 000 task։ Այդ մնացորդները նույն միավորը չեն չափում. դրանք ցույց են տալիս, թե յուրաքանչյուր փաթեթում որքան տեղ կա մինչև սեփական սահմանաչափը։ Գների հարաբերությունը՝ $129 բաժանած $21-ի, մոտ 6,14 է, սակայն այդ թիվը բաժանորդագրությունների հարաբերությունն է, ոչ մեկ գործողության գնի համեմատությունը։

Եթե հրապարակված ընդհանուր սպառումը պարզապես բաժանենք ամսական մոտ 200 իրադարձության, կստացվի միջինում մոտ 60 credit և 30 task մեկ իրադարձության դիմաց։ Սա օգտակար է միայն որպես սցենարի ընդհանուր ծանրաբեռնվածության մոտավոր ցուցիչ։ Հրապարակված աղյուսակը չի բացում յուրաքանչյուր իրադարձության կատարված քայլերի հերթականությունը, իսկ տարբեր իրադարձություններ կարող են ստեղծել, որոնել կամ թարմացնել տարբեր թվով գրառումներ։ Դաշտերի թիվն էլ ինքնուրույն չի որոշում վճարը. ութ դաշտի համադրումը կարող է կատարվել մեկ գործողության ներսում կամ պահանջել լրացուցիչ մշակում։

Առաջին հոսքի կառուցման համար նույն օրինակը Zapier-ում գնահատում է 15–20 րոպե, Make-ում՝ 45 րոպեից երկու ժամ։ Ժամանակային այդ գնահատականը վերաբերում է առաջին հոսքին, ոչ ամբողջ երկկողմ կապի հետագա սպասարկմանը։ Հետևաբար փոքր ծավալի դեպքում ավելի արագ մեկնարկը կարող է կարևոր լինել, մինչդեռ կրկնվող մեծ ծավալի դեպքում ամսական փաթեթների տարբերությունն ավելի մեծ կշիռ է ստանում։

Credit-ն ու task-ը նույն քայլը չեն նկարագրում

Make-ի credit-ների բացատրությունը նշում է, որ սցենարի մոդուլի սովորական գործողությունը հիմնականում ծախսում է մեկ credit. տվյալ կարդալը, որոնելը, ստեղծելը և թարմացնելը հաշվարկվող օրինակներ են, իսկ router-ն ու նշված սխալի մշակման մոդուլները բացառություններ են։ Մեկ օրացուցային փոփոխությունը կարող է անցնել որոնման, տվյալների փոխակերպման և թարմացման մոդուլներով, ուստի մեկ իրադարձությունը մեկ credit համարել չի կարելի։ Եթե մոդուլը մշակում է մի քանի առանձին գրառում, պետք է հաշվել նաև դրա փաստացի կատարումները։

Zapier-ի task-երի դրույքաչափերով սովորական հաջողված action քայլը ծախսում է մեկ task, մինչդեռ Formatter, Paths և Filters ներկառուցված քայլերը task չեն ծախսում։ Սա նշանակում է, որ խմբագրիչում երևացող քայլերի քանակը դեռ ամսական task-երի քանակը չէ։ Պայմանական ճյուղերից հաշվարկվում են կատարված վճարովի գործողությունները, իսկ որոշ մասնագիտացված գործիքների դրույքաչափերը կարող են տարբերվել սովորական action-ից։

Նույն հոսքի համադրելի հաշվարկի համար առանձին դիտարկեք նոր գրառումը, գոյություն ունեցողի փոփոխությունը և սխալից հետո կրկնվող կատարումը։ Յուրաքանչյուր դեպքում նշեք, թե Make-ում որ մոդուլներն են կատարվում և Zapier-ում որ գործողություններն են հաջող ավարտվում։ Այնուհետև ամսական սպասվող հաճախականությունը բազմապատկեք համապատասխան միավորներով։ Այս եղանակով ստացված երկու թվերը համեմատվում են իրենց փաթեթների սահմանաչափերի հետ, ոչ ուղղակիորեն իրար հետ։

Երկկողմ կապը երկու ուղղություն է և մեկ ընդհանուր խնդիր

Օրացույցից տվյալների շտեմարան փոխանցելը և շտեմարանից օրացույց վերադարձնելը պահանջում են առանձին ուղղությունների տրամաբանություն։ Երբ օրացույցում գրառումը փոխվում է, հոսքը պետք է գտնի դրա զույգը շտեմարանում և որոշի՝ թարմացնե՞լ այն, թե՞ ստեղծել նոր գրառում։ Հակառակ ուղղությամբ նույն որոշումն անհրաժեշտ է օրացույցի համար։ Զույգ գրառումների նույնականացուցիչների պահպանումը հատկապես կարևոր է, որպեսզի անվան կամ ժամի փոփոխությունը կրկնօրինակ չստեղծի։

Երկու ուղղության միացումը կարող է նաև շրջանաձև գործարկում առաջացնել. առաջին հոսքի կատարած թարմացումը դառնում է երկրորդի նոր ազդակ, իսկ երկրորդի գրառումը կրկին գործարկում է առաջինը։ Այդ պատճառով ծախսի և աշխատանքի գնահատման մեջ տեղ ունեն արդեն մշակված փոփոխությունը ճանաչող պայմանները, որոնումները և սխալի դեպքում վերագործարկումը։ Նման պաշտպանությունը կարող է ավելացնել հաշվարկվող գործողություններ, նույնիսկ եթե վերջնական օգտակար արդյունքը ընդամենը մեկ համաժամացված գրառում է։

Փոփոխությունների խառնուրդը ևս ազդում է ծախսի վրա։ Եթե ամսվա գրառումների մեծ մասն արդեն գոյություն ունի, որոնման և թարմացման ուղին ավելի հաճախ կաշխատի, քան ստեղծման ուղին։ Եթե աղբյուրներից մեկը հաճախ վերադարձնում է թերի տվյալ կամ փոխում է դաշտի ձևաչափը, ավելանում են ձախողումները, դրանց ուսումնասիրությունն ու ուղղումը։ Հրապարակված օրինակի միջին սպառումը նոր հոսքի բյուջե տեղափոխելիս այս պայմանները պետք է համապատասխանեն իրական տվյալներին։

Ինտեգրումների քանակը դեռ չի որոշում ընտրությունը

Zapier-ի փաթեթների էջը նշում է ավելի քան 9 000 հավելվածի միացում և Professional փաթեթում բազմաքայլ Zap-երի հնարավորություն։ Նույն էջի համաձայն՝ սահմանաչափը լրանալուց հետո կարող է միանալ հավելյալ task-երի վճարումը, եթե այն անջատված չէ։ Լայն կատալոգը գործնական առավելություն է, երբ թիմի օգտագործած ծառայության պահանջվող գործողությունն առկա է այնտեղ, բայց միայն հավելվածի անվան առկայությունը դեռ չի երաշխավորում անհրաժեշտ դաշտի ընթերցումը կամ փոփոխումը։

Make-ի հնարավորությունների համեմատությունը նշում է ավելի քան 3 500 պատրաստի հավելված և HTTP մոդուլով այլ API-ներին միանալու հնարավորություն։ Տվյալ ծառայության պատրաստի գործողությունները կարող են ավելի կարևոր լինել, քան ամբողջ կատալոգի չափը։ API-ով կապը պահանջում է համապատասխան մուտք, տվյալների ձևաչափի իմացություն և կապը պահպանող պատասխանատու. այդ աշխատանքը պետք է ներառել ընտրության արժեքի մեջ։

Որտեղ է ծախսվում թիմի ժամանակը

Առաջին կառուցման ժամանակը միայն սկիզբն է։ Երկկողմ հոսքը պահանջում է դաշտերի համապատասխանեցում, զույգ գրառումների նույնականացուցիչների պահպանում, փոփոխության աղբյուրի ճանաչում և երկու ուղղության փորձարկում։ Հետագայում աշխատանք կարող են առաջացնել փոխված թույլտվությունները, աղբյուր հավելվածի նոր դաշտերը, չավարտված կատարումները և կրկնվող գրառումները։ Այդ ժամերը բաժանորդագրության հաշվում չեն երևում, բայց փոքր թիմի համար իրական ծախս են։

Ընտրությունը կարելի է ամփոփել չորս պայմանով.

• Եթե գործողությունները քիչ են և հիմնականում հաջորդում են իրար ուղիղ հերթականությամբ, Zapier-ի արագ մեկնարկը կարող է փոխհատուցել ավելի թանկ փաթեթը։
• Եթե հոսքը հաճախ է աշխատում, ունի մի քանի պայմանական ուղղություն և թիմը կարող է այն կառավարել, Make-ի փաթեթն ու տեսանելի ճյուղավորումը կարող են ավելի շահավետ լինել։
• Եթե անհրաժեշտ հավելվածը կամ կոնկրետ գործողությունը կա միայն մեկ հարթակում, այդ հասանելիությունն ավելի կարևոր է, քան անվանական գների տարբերությունը։
• Եթե հոսքը հաճախ է խափանվում կամ փոխվում, համեմատության մեջ ներառեք պատասխանատու աշխատակցի՝ հայտնաբերման, ուղղման և նորից փորձարկման ժամերը։

Թիմի աշխատաժամի արժեքը հայտնի լինելու դեպքում ամսական համեմատությունը կազմվում է փաթեթի վճարից և սպասարկման ժամերի արժեքից, իսկ մեկնարկային կառուցման ժամանակը կարելի է բաշխել հոսքի նախատեսված օգտագործման ամիսների վրա։ Այդպես արագ գործարկման առավելությունն ու կրկնվող վճարների տարբերությունը հայտնվում են նույն որոշման մեջ՝ առանց հրապարակված մեկ սցենարի թվերը սեփական բիզնեսի հաստատուն ծախս համարելու։

Կարդացեք նաև:

• n8n թե Zapier․ նույն հոսքը մեկ execution է կամ բազմաթիվ task
• ԱԲ գործակալի հաշիվը հաշվեք ամբողջ loop-ով․ մեկ փորձը կարող է 30 անգամ տարբերվել
• n8n թե Make․ 20 քայլանոց հոսքը նույն հաշիվը չի ստեղծում