Microservices mimarisinin adaptasyonu gittikçe hızlanmaya başladı. Özellikle bu yıl katıldığımız konferans ve etkinliklerde bu yapıya evrilen kurumların süreçlerinden edindikleri deneyimlerin yanında, keşke yapmasaydık dedikleri noktaları da keşfetme şansımız oldu.
Aslında birçok kavram gibi microservices de kendi avantaj ve dezavantajlarını beraberinde getiriyor. Bağımsız ekipler, farklı teknolojilerin kullanımı, devreye alım ve ölçekleme esnekliği ilk akla gelen avantajlardan olurken, farklılaşan teknoloji altyapıları, ekipler arası iletişim ve servisler arası entegrasyon sorunları dezavantajları arasında sayılabilir.
Aslına bakılırsa servisler arası entegrasyon sorunu göründüğünden çok daha karmaşık. Zira monolith uygulamalarda oldukça az olan entegrasyon sayısı, yeni yaklaşımla birlikte n*(n-1) gibi exponential şekilde büyüme gösteriyor. Onlarca, yüzlerce hatta binlerce (bunun için oldukça büyük ölçekte bir yapı gerekecektir) microservice’in olduğu bir uygulama için tüm bu entegrasyonları test etmek kolaylıkla bir kabusa dönüşebilir.
Elbette, microservices yaklaşımının esas motivasyonlarından biri olan esneklik (resilience) için yüksek sayıda verification/validation işlemi gerekli olacaktır. Ancak değişen bir servisin kendisine entegre olan diğer tüm servisleri etkileyeceğini düşündüğümüzde, bu değişiklikleri doğrulamak oldukça zorlu bir süreç haline geliyor.
Bu sorunla başa çıkmak için, sürekli bahsettiğimiz test piramidine yeni bir katman eklenmesi işlerin yönetilebilirliği için oldukça faydalı olacaktır.
Consumer-Driven Contract Testing
Consumer-Driven Contracts, kullanılan (provider) ve kullanıcı (consumer) servisleri arasındaki entegrasyonun bir kontrat üzerinden tasarlandığı ve yönetildiği yaklaşım olarak düşünülebilir. Consumer’lara sağlanan API üzerinde herhangi değişiklik yapıldığında, bu servisi kullanan tüm consumer’ların API release’lerini takip ederek kendilerini güncelliyor olması gerekecektir. Veya API tarafının entegrasyonlarda sorun oluşmaması için önceki versiyon(ları) da desteklemeye devam etmesi zorunlu olacaktır.
Bu sorunla başa çıkma için, API’lar üzerinde yapılacak değişikliklerin validasyonu için bir kontrat mekanizması kurulabilir. Bu durumda servisi kullanacak olan tüm consumer’lar kendi kontratlarını hazırlayarak provider’ın erişimine açacaktır. Bu yaklaşımdaki önemli fayda, provider’ın hangi fonksiyonlarının nasıl kullanıldığını bilmesi ve bu sayede yapılacak önemli bir değişiklikte hangi kullanıcıların etkileneceğini öngörebilmesi ya da erişim noktalarını sabit tutarak kodun içyapısını değiştirebilmesidir.
Pact, Consumer-Driven Contract Testing için kullanılabilecek popüler bir open-source araç. Ruby, JVM, .Net, Go gibi ortamları destekleyerek kontratlarınızı hazırlamanıza olanak sağlıyor.
Daha fazla bilgi ve dokümantasyon için;
https://github.com/DiUS/pact-jvm
http://dius.com.au/2014/05/19/simplifying-micro-service-testing-with-pacts/