Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Why the DevOps Movement Depends on SOA

DevOps is an umbrella term for processes, methods, systems and tools for improved communication and collaboration between development, QA and operations teams.


advertisement
The rise of agile development methodologies combined with the relentless pressure for shortened innovation cycles and time to market has given rise to the DevOps movement. The growing focus on DevOps signifies a shift in how IT thinks about delivering integration and new functions.

DevOps -- an umbrella term for processes, methods, systems and tools for improved communication and collaboration between development, QA and operations teams -- is reaching a fever pitch, said Ken Yagen, VP of Engineering for MuleSoft, a web middleware company.

[LOGIN]

MuleSoft provides enterprise-class software based on Mule ESB and Apache Tomcat, open source application infrastructure products. Mule ESB is a lightweight, open source enterprise service bus (ESB) and integration platform with 1.5 million downloads and a user community of more than 2,500 enterprises.



"What is stoking much of the interest in DevOps is that companies and developers want to build a more cloud- and services-based approach to business," said Yagen.

However, up until now, much of the focus has been on improved processes and tools. What has been overlooked, said Yagen, is how software architecture can impact and drive successful DevOps practices as well, and how the entire DevOps movement is in some ways the legacy of SOA.

DevOps has grown up around the awareness that there is a disconnect between development activity and operations activity. This disconnect frequently breeds conflict and inefficiency, exacerbated by a swirl of competing motivations and processes.

For the most part, developers are paid to create solutions (aka changes) that will address the evolving needs of a business. Companies often incentivize developers to create as much change as possible.

At the same time, companies rely on operations people to do the exact opposite - to preserve the status quo by ensuring that current products and services are stable and reliable, and making money. Changes are threatening at best and unwelcome at worst for operations people.

Complicating the scene even more is that dev and ops teams often use different software tools, report to competing corporate leaders, and practice conflicting corporate politics. Some dev and ops teams even work poles apart geographically.

DevOps principles are centered on fast development cycles, incremental change, and continuous deployment of new functionality. The service-orientation of modern applications makes this all possible, said Yagen.

Legacy monolithic application approaches demand much heavier weight processes, with a long development cycle, a full QA test phase, and a 'locked-down' operations environment to minimize risks, he added.

"SOA introduces a level of decoupled modularity, allowing for rapid changes to just one part of the application at the service level, tested and released, without impacting other parts of the application," he explained.

As a provider of open source integration and SOA software, MuleSoft has many customers who are leaders in building SOA architectures, which uniquely positions then to benefit from both the SOA and DevOps trends.

"Taking a cue from our customers in this area, we recently announced Mule ESB 3.1, which includes many new features that further enable customers to achieve DevOps benefits," said Yagen. "These features allow cross-functional IT teams (e.g., developers, QA, and operations) to leverage the same web-based console to deploy, monitor and manage applications, enabling more agile deployment processes and reducing the risk of change."

As an example, a collaborative deployment feature in the Mule Management Console (MMC), included with Mule ESB Enterprise Edition, allows developers and IT operations staff to approach the continuous deployment ideal - allowing them to deploy applications more collaboratively, enabling faster feedback loops and lowering the risks of deployment.

The changes to the Mule ESB Management Console allow developers and operations to work together for incremental roll-outs - thus supporting a continuous approach to integration rather than one big roll out date.

"The result is a self-reinforcing virtuous circle," claimed Yagen. "SOA principles have enabled improved operational processes in the form of DevOps, and with the right tools, these same DevOps philosophies and practices are making building and deploying SOA-style applications much easier."



   
Herman Mehling has written about IT for 25 years. He has written hundreds of articles for leading computer publications and websites.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap