Refactoring AWX into a Pluggable, Service-Oriented Architecture

Project Discussions
, , , , ,
1

Hi folks,

In our previous post, we discussed the upcoming changes we’re making to the AWX project. Today, we’d like to dive deeper into one of the most significant changes: refactoring AWX into a pluggable, service-oriented architecture.

Current State of AWX

AWX is currently structured as a monolithic Django application. It consists of several entry points, each running as individual processes, including our API, Job Dispatcher, Event Processor, and Websocket subsystem. Alongside these, AWX relies on various ancillary processes such as Redis, Rsyslog, Receptor, Nginx, Uwsgi, and Daphne.

Challenges with the Current Architecture

Over time, it has become increasingly challenging to implement changes due to the large, self-contained nature of the application. This monolithic structure has not only slowed down our development process but also made it difficult to ensure efficient code reuse across our other applications. Consequently, this impacts both our development efficiency and the ability to quickly iterate on features and fixes. As we continue to extend capabilities across Ansible Automation Platform we cannot afford these challenges and maintain upstream projects the way they are currently structured.

Proposed Changes

To address these challenges, we are beginning to transition AWX towards a more pluggable, service-oriented architecture. By breaking down the monolithic structure into smaller, modular services, we aim to enhance both flexibility and maintainability. This shift will enable us to make changes more swiftly and efficiently in AWX while also improving our ability to reuse code across various projects leveraged by Ansible Automation Platform.

Implementation Plan

Our implementation plan involves several key steps:

  1. Identifying Modular Services: We will start by identifying the core functionalities that can be extracted into individual plugins and/or services.
  2. Creating a Communication Framework: Establish a robust communication framework to ensure seamless interaction between these services.
  3. Gradual Transition: Implement the new architecture in phases to allow for continuous feedback and improvement.
  4. Community Collaboration: Engage with our community throughout the process to gather feedback and ensure the new architecture meets the needs of our users.

Future-Looking Architecture

1316×628 38.8 KB

Expected Outcomes

By refactoring AWX into a service-oriented architecture, we expect several positive outcomes:

  • Improved Flexibility: Easier to implement changes and add new features.
  • Enhanced Maintainability: Simplified codebase with clear service boundaries.
  • Better Code Reuse: More efficient reuse of code across different projects.
  • Active Community Participation: Greater opportunity for community members to contribute and shape the project.

Call to Action

We invite feedback and collaboration with us on this significant transformation by replying to this forum post.

Join the discussions on our forum, share your thoughts, and help shape the future of awx .

Conclusion

These architectural changes are a crucial step towards a more modern and scalable AWX. We look forward to your participation and support as we embark on this journey together.

Stay updated by joining The Forum, following the News & Announcements and awx tags.

Thank you for your continued support.

Links in this AWX update series

Useful links

13 Likes
2

How do you see these blocks running and communicating with each other?
Communication would be api based?

Every block is a supervisord process? That would make it scalable since you could seperate each block to a container if needed.

I use the docker-compose dev method a lot for testing new releases. So I hope that this keeps working in the new architecture. (awx/tools/docker-compose/README.md at devel · ansible/awx · GitHub)

4 Likes
3

I would like to see the framework be open and flexible enough that the community could deliver custom installable plugins to enhance the AWX experience, complete with an online store for installing plugins from. (think something along the lines of Jenkins’ plugins)

At the very least, these plugins could be sub-types of AWX’s existing modules, such as custom credential types (improves re-usability), but it would be awesome if entirely new modules/components could be installed without having to custom build the awx image. We (the community) could build ansible-{lint,policy} compliance modules that report on the code quality of projects, or even enforce restrictions on their use until it’s fixed. Sure, this can be done in workflows upstream; I’m just providing an example.

Having a framework that supports installable plugins could benefit internally as well. Your team could experiment with feature ideas and make them available to the community for testing without baking it straight into the main more-stable code base where you may risk muddying the water with breaking changes.

In any case, I hope to see more flexibility/re-usability with what’s already in AWX.

6 Likes
4

Hi all, a new post in the AWX refactoring series has been posted in the forum, you can check the post here: Upcoming changes to AWX Operator installation methods

2 Likes
5

There’s a new post in the AWX Modernization series at AWX UI and credential types transitioning to the new pluggable architecture.

1 Like
6

I’ve just posted the next forum post in this series, Transitioning authentication and authorization (RBAC) to the new AWX architecture