Logic Apps'e geçiş: Power Automate'ten geçiş ne zaman değer

Power Automate, birçok ekip için otomasyona mükemmel bir giriş noktasıdır: akışlar birkaç tıklamayla oluşturulabilir, lisanslar genellikle Microsoft 365 üzerinden zaten mevcuttur ve topluluk konektörleri günlük kullanım senaryolarının çoğunu kapsar. Ancak platformun sınırlarına dayandığı bir nokta vardır; örneğin yüksek yürütme hacmi, karmaşık kurumsal iş yükleri veya BT güvenliğinin ağ ve erişim kontrolüne ilişkin daha katı gereksinimler getirdiği durumlarda. Microsoft, tam olarak bu durum için resmi bir geçiş yolu tanımlamıştır: Power Automate'ten Azure Logic Apps'e (Standard).

Bu yazı, bir geçişin ne zaman mantıklı olduğunu hangi belirtilerden anlayabileceğinizi, Azure Logic Apps'in (Standard) teknik olarak neyi farklı yaptığını ve Microsoft belgelerine göre geçiş sürecinin somut olarak nasıl işlediğini gösteriyor. Karar üzerindeki kontrolü elinizde tutarsınız: her akışın taşınması gerekmez, ancak sinyalleri bilen kişi, acil durumda tepki vermek yerine zamanında planlama yapabilir.

Power Automate ne zaman sınırlarına dayanır

Power Automate, bilinçli olarak vatandaş geliştiricilere ve iş kullanıcılarına yönelik tasarlanmıştır ve ortak kaynaklarla çalışır. Yük arttıkça hissedilir darboğazlara yol açan da tam olarak budur. Platform sınırlarına ilişkin Microsoft belgelerine göre, diğerlerinin yanı sıra aşağıdaki kısıtlamalar geçerlidir:

• Lisans başına günlük eylem sınırları. Bir tetikleyici ve bir eylemden oluşan bir akış, her çalıştırmada zaten iki eylem tüketir. Ücretsiz veya Microsoft 365'e dahil lisanslarda günlük sınır, premium veya süreç lisanslarına göre belirgin şekilde daha düşüktür.
• Konektör kısıtlaması. Her konektörün kendi hız sınırları vardır. Bu sınıra ulaşıldığında hizmet, "Rate limit is exceeded. Try again in 27 seconds" gibi bir mesajla birlikte 429 hata kodunu döndürür.
• Eylem patlaması sınırı. Şu anda üst sınır, akış başına beş dakikada 100.000 eylemdir. Bu aşıldığında platform akışı otomatik olarak kısıtlar.
• Otomatik devre dışı bırakma. 14 gün boyunca kesintisiz olarak kısıtlanan bir akış, Power Automate tarafından kapatılır. Yeniden etkinleştirilebilir, ancak aşırı yük devam ederse tekrar devre dışı bırakılır.
• Döngüler ve paralellik için sınırlar. Bir "Her birine uygula" döngüsü, performans profiline bağlı olarak en fazla 5.000 veya 100.000 dizi öğesini işler; paralellik denetimi etkinleştirildiğinde eşzamanlı yürütmeler en fazla 100 ile sınırlıdır.

Bu sayılar tesadüf değildir, platformun amacını yansıtır: iş kullanıcıları için küçük ve orta ölçekli otomasyonlar, kalıcı yüksek yüklü entegrasyonlar değil. Akışlarınız düzenli olarak bu sınırlara takılıyorsa, günlüklerde 429 hatalarıyla karşılaşıyorsanız veya bir akış optimizasyona rağmen tekrar tekrar kısıtlanıyorsa, bu mimariyi yeniden gözden geçirmek için açık bir sinyaldir.

Azure Logic Apps (Standard) neyi farklı yapar

Microsoft, Power Automate ile Azure Logic Apps'i (Standard) resmi geçiş belgelerinde doğrudan karşılaştırıyor. Farkın özü şudur: Power Automate paylaşılan kaynaklar ve kolay kullanım için tasarlanmıştır, Logic Apps (Standard) ise ayrılmış kapasite ve kurumsal gereksinimler için tasarlanmıştır.

Performans ve ölçeklenebilirlik

Standart bir Logic App, ayrılmış işlem kaynakları üzerinde çalışır; ister tek kiracılı bir örnek olarak, ister bir App Service Environment içinde, ister hibrit bir dağıtımda. İş akışı örnekleri varsayılan olarak paralel çalıştırılır, bu da karmaşık görevlerde işlem süresini azaltır. Power Automate'te sürekli olarak eylem veya konektör sınırlarına takılan yüksek hacimli iş yükleri için bu, belirleyici avantajdır: artık paylaşılan bir kaynak havuzu değil, esnek şekilde ölçeklenen sabit bir kapasite vardır.

Güvenlik ve uyumluluk

Azure Logic Apps (Standard), Power Automate'te basitçe bulunmayan özellikler sunar:

• Sanal ağ entegrasyonu ve özel uç noktalar sayesinde iş akışlarının artık zorunlu olarak genel internet üzerinden çalışması gerekmez.
• Yönetilen kimlik kimlik doğrulaması, manuel olarak yönetilen kimlik bilgilerini gereksiz kılar.
• Kaynak düzeyinde rol tabanlı erişim denetimi. Power Automate'te RBAC tek tek kullanıcıya bağlıyken, Logic Apps'te kaynak düzeyinde uygulanır. Dolayısıyla bir iş akışını oluşturan kişi şirketten ayrılsa bile iş akışına erişim kaybolmaz.

Geliştirme, sürüm yönetimi ve işletim

CI/CD ile üretken şekilde çalışan ekipler için Logic Apps (Standard), Visual Studio Code üzerinden tam Git entegrasyonu sunar; değişiklik takibi, dallanma ve Azure DevOps veya GitHub Actions üzerinden otomatikleştirilmiş dağıtımlar dahil. İş akışları, yani altyapı kod olarak (Infrastructure as Code) ARM şablonları veya Bicep dosyaları olarak tanımlanabilir; bu da tekrarlanabilir ve hataya daha az açık dağıtımlar sağlar. Ayrıca platform 1.400'den fazla konektörü, iş akışı içinde doğrudan .NET, C# veya PowerShell ile özel kod parçacıklarını ve dağıtım yuvaları (deployment slots) aracılığıyla kesintisiz dağıtımları destekler.

Değerlendirme için önemli: bu avantajlar, geliştirme geçmişi olmayan iş kullanıcılarına değil, profesyonel geliştiricilere ve BT ekiplerine yöneliktir. Basit, tek seferlik otomasyonlar oluşturan kişi, geçişten çok az kazanç sağlar ve Power Automate'in kolay kullanılabilirliğini kaybeder.

Pratikte geçiş süreci

Microsoft, geçişi otomatik bir dönüştürme olarak değil, kendine ait bir test aşaması olan planlı bir süreç olarak tanımlar. Belgelerden aşağıdaki adımlar türetilebilir:

1. Envanter çıkarma. Hangi akışların sınırlardan gerçekten etkilendiğini kontrol edin; örneğin akış başına yürütülen eylem sayısını gösteren Power Automate'teki analiz görünümü üzerinden.

2. Hedef mimariyi belirleme. Tek kiracılı Azure Logic Apps, bir App Service Environment veya kendi altyapınızla hibrit bir dağıtımın uygun olup olmadığına karar verin.

3. İş akışı mantığını yeniden oluşturma. Akış mantığı, Azure Logic Apps'in görsel tasarımcısında veya doğrudan JSON kod düzenleyicisinde; yerel olarak Visual Studio Code'da ya da tarayıcı tabanlı olarak Azure portalında yeniden oluşturulur.

4. Bağlantıları yeniden kurma. SQL Server veya Azure Key Vault gibi hizmetlere olan bağlantıların manuel olarak yeniden oluşturulması gerekir. Microsoft bu noktada açıkça titiz güvenlik ve işlevsellik testleri önerir.

5. Geçişi doğrulama. Belgeler, üretime geçmeden önce tamamlanması gereken dört doğrulama adımından bahseder: işlevsellik testleri (orijinal mantık korunuyor mu?), bağlantı testleri, kurumsal politikalara karşı güvenlik doğrulaması ve taşınan iş akışlarının önceki Power Automate performans değerlerini aştığını garanti eden performans testleri.

Bu süreç için bilinçli olarak zaman ayırın. Basit bir dışa/içe aktarma işleminin aksine, geçiş; her bağlantının, her iznin ve her hata işlemenin yeniden düşünülmesini gerektirir, çünkü güvenlik modeli temelden farklıdır: Power Automate'te kullanıcı tabanlı, Logic Apps'te kaynak tabanlıdır.

Geçiş mi optimizasyon mu: bir karar rehberi

Ara sıra kısıtlanan her akışın hemen tam bir geçişe ihtiyacı yoktur. Bir platform değişikliğinin çabasına girmeden önce üç soruyu değerlendirmek faydalıdır:

• Sorun yapısal mı yoksa tek seferlik mi? Tek bir yük artışı genellikle akış optimizasyonuyla, örneğin tetikleyici koşulları, birden fazla akışa bölme veya "Her birine uygula" döngüsünden filtrelenmiş veri sorgularına geçiş yoluyla çözülebilir.
• Gerçekten kurumsal güvenlik özelliklerine ihtiyacınız var mı? Sanal ağ entegrasyonu, özel uç noktalar veya kaynak tabanlı RBAC uyumluluk nedenleriyle zorunluysa, Logic Apps'ten başka bir yol yoktur.
• Bir geliştirme ekibi hazır mı? Logic Apps (Standard), Visual Studio Code, Git ve tercihen CI/CD bilgisi gerektirir. Bu kaynaklar olmadan işletim daha basit değil, daha karmaşık hale gelir.

Bu sorular bir geçişten yana ise, akut bir kısıtlama sorunu sırasında zaman baskısı altında iş akışlarını taşımak yerine, net test kriterleriyle yapılandırılmış bir geçiş planlaması yapmak faydalıdır. Bu adımı tek başına üstlenmek istemeyenler, örneğin bir Power Automate danışmanlığı kapsamında dışarıdan destek de alabilir.

Sık sorulan sorular

Hangi yürütme hacminden itibaren Logic Apps'e geçmeliyim?

Microsoft sabit bir rakam belirtmiyor. Belgelere göre asıl belirleyici olan, tekrarlayan örüntüdür: akışlar düzenli olarak eylem sınırlarına, konektör kısıtlamasına veya beş dakikada 100.000 eylemlik eylem patlaması sınırına takılıyor ve optimizasyonlar bunda bir değişiklik yaratmıyorsa, bu geçiş için güçlü bir sinyaldir.

Power Automate akışları otomatik olarak Logic Apps'e dönüştürülüyor mu?

Hayır. Microsoft geçişi manuel bir süreç olarak tanımlar: iş akışı mantığı, Logic Apps'in tasarımcısında veya JSON düzenleyicisinde yeniden oluşturulur; SQL Server veya Azure Key Vault gibi hizmetlere olan bağlantıların yeniden kurulması gerekir. Resmi geçiş belgelerine göre Microsoft, tek tıkla otomatik bir dönüştürme sunmuyor.

Power Automate ve Logic Apps'i paralel olarak çalıştırabilir miyim?

Evet, hatta bu genellikle izlenen yoldur. Tüm akışları bir kerede taşımanız gerekmez. Gerçekten platform sınırlarına takılan veya artırılmış güvenlik gereksinimleri olan iş akışlarını önce taşımak, daha basit otomasyonları ise Power Automate'te bırakmak mantıklıdır.

Kalıcı olarak kısıtlanan bir akışa ne olur?

Microsoft belgelerine göre Power Automate, bir bulut akışını 14 gün boyunca kesintisiz olarak kısıtlanmışsa otomatik olarak devre dışı bırakır. Akış yeniden etkinleştirilebilir, ancak aşırı yük devam ederse tekrar kapatılır. Tam olarak bu tür tekrarlayan devre dışı bırakmalar, ya bir süreç lisansı satın almak ya da Logic Apps'e geçişi değerlendirmek için açık bir sinyaldir.

Logic Apps (Standard) için kendi geliştirme ekibime ihtiyacım var mı?

Pratikte evet, en azından temel bilgi gereklidir. Microsoft, Logic Apps'i (Standard) açıkça profesyonel entegratörler, geliştiriciler ve BT yöneticileri için konumlandırırken, Power Automate geliştirme geçmişi olmayan iş kullanıcıları için tasarlanmıştır. Git sürüm kontrolü, CI/CD hatları ve altyapı kod olarak (Infrastructure as Code) ile üretken şekilde çalışmak isteyenler, geçişe başlamadan önce ilgili kaynakları planlamalıdır.

Tek tek geçiş adımları ve tam özellik karşılaştırması hakkında daha fazla ayrıntıyı Power Automate geçişine ilişkin Microsoft belgelerinde ve ayrıca Power Automate platform sınırlarına genel bakışta bulabilirsiniz.