去年我們曾報道過，arjuna technologies（hp事務服務技術的初創者，現在red hat/jboss的一部分）又把注意力轉向了容錯的網格基礎設施。這篇文章在當時引起了極大的興趣，即使當時並沒有什麼東西可供人們來嘗試。然而，事隔一年之後，arjuna發布了更加實在的東西：arjuna agility聯邦雲計算平台。這裡有必讀的***和網路研討會（事實上非常不錯），但是關於agility最重要的是現在可供訪問了。再加上
\u0026#xd;\n
[agility]是乙個『聯邦雲計算平台』，它被設計成可通過更靈活的基礎設施來提高業務敏捷性。聯邦，是因為agility™是由分配給企業內外自治、合作的業務組織的it資源構成的。在組織間資源共享的真正障礙往往是信任和許可權，agility™提供了一種可掌控的方式使得企業能有機地壯大它們的『內部雲服務』。資源的所有者可對所分配的資源附加一定的策略用以描述在哪種情況下資源可以被agility™共享，通過這種方式，資源所有者保有了對資源的控制權。一旦（資源）被分配並遵從於策略，agility™就可以動態地配置資源池並提供服務以滿足業務對it變化的需求。\u0026#xd;\n
像其它的雲計算平台一樣，完成這一**（provisioning）所需的服務和工具可能超出現有的基礎設施投資。然而，要交付其承諾的益處，agility最終需要獲得對整個雲架構的掌控：
\u0026#xd;\n
雖然agility™也可以部署於現有的基礎設施而不需作出折衷的更改，但在增量地向其分配it資源時agility™的威力才能真正的體現出來。\u0026#xd;\n
將這一新平台與現有解決方案對照得出的差別會非常有益，然而它顯然還處於開發的早期階段。儘管如此，最新的***還是給了我們一些線索：
\u0026#xd;\n
和其它的途徑不同，agility不會強制企業的it基礎設施和應用作出「大**」般的轉變。\u0026#xd;\n
這一點初看起來和之前agility需要完全控制的陳述似乎是相矛盾，但對於這種化圓作方（即不可能）的事，agility作出了許多努力。實際上，據現有訊息來看，agility「不要求現有基礎設施進行任何更改或重組」，也「不要求資源進行共享，除其所有者允許的情況之下」。這種無侵害的方式支援使用者進行全面的擴充套件，甚至利用其服務時都不需要了解agility的存在。
\u0026#xd;\n
從該平台的表現來推斷，應該是基於esb的，因為有很多相關參考指出其「基於服務幷包含支援多種訪問協議的協議閘道器」。儘管它包括一些你所知道的關於雲服務平台的常見疑慮，比如跨越管理邊界的服務共享控制以及動態的服務配置與供給等等，但它還有一些新穎出彩的地方，這令它顯得更加有趣：
\u0026#xd;\n
但考慮到arjuna的背景，agility裡將如何融合其容錯技術呢？
\u0026#xd;\n
……通過在檢測到失效時支援動態地重新部署資源，依賴性得以改善。失效之後，隨著服務需求與it基礎設施之間解耦，agility可以確定能夠滿足服務需求的替代資源，並重新配置系統來使用這些資源，以保證可持續地滿足服務的需要。\u0026#xd;\n
目前還沒有跡象表明agility使用的是現有失效探測機制還是其自已的技術。在缺少乙個詳盡架構描述的前提下，很難作出相應的判斷。但看似有一件事是確定的：這一次事務處理沒有被包含進整個巨集圖中（除非它們已經隱含為基礎設施的一部分）。
\u0026#xd;\n檢視英文原文：
agile cloud computing?
敏捷開發 DevOps和雲計算（三）
與傳統開發方法相比，在敏捷開發的整個過程中，有以下幾個主要的特點 從敏捷宣言的第四條響應變化高於預設計畫便可以看出來。因為軟體開發過程的本身的不可預見性，很多使用者在專案開始時不可能對於這個專案有著乙個完整而明確的預期。很多對軟體的預期都在後期的修改和完善過程中產生。因此高適應性顯然更加符合軟體工程...
狹義雲計算和廣義雲計算 雲計算比我們想象的更環保
狹義雲計算和廣義雲計算 雲計算是綠色的想法實際上取決於您正在與誰交談。有人說，資料中心的增長是由那些 的雲提供商推動的。他們建造了龐大，醜陋的建築物，比乙個小鎮要消耗更多的電力和水，占用了許多可用於農業的房地產，而且實際上並沒有雇用那麼多人。但是，一般而言，主要公共雲提供商運營的資料中心會對計算功耗...
DevOps 敏捷開發 雲計算，三劍客的小時代
在開發和創新領域中，devops 敏捷開發以及雲計算終於突破了布道階段逐步成為主流，本篇文章講述將三種模式結合在一起所帶來的巨大收益。隨著數位化的快速發展，整個世界都在全方位轉型，過去的十年中，個人和職業生活都受到了技術的深刻影響，這一切可能要歸功於devops。2013年，敏捷開發受到很多開發者的...