The ability to connect data, processing, and services is the foundation of the modern financial services enterprise. You want to do those things in the most efficient, transparent, scalable, and cost-effective way. This is the key to business stability, growth, and competitiveness regardless of market or sector.

Without true workflow automation, the old aphorism “time is money” becomes literal since lack of agility, visibility, flexibility, and scalability carries heavy costs. If your enterprise has historically used AutoSys, you’re seeing its limitations as a legacy tool.

Those limitations and what they mean to the competitiveness of your financial services enterprise may have you looking at a migration to Airflow and Cloud Composer. This blog goes through some of the common pain points of AutoSys and how a Cloud Composer migration will eliminate those challenges. While the focus is on financial services, these gains of migration to Cloud Composer are true across any enterprise sector using legacy AutoSys.

The first version of AutoSys hit the market in the mid-90s and is still heavily used by the financial sector. While still heavily in use across different sectors, it’s got a dwindling user base and looks to have limited updates that make it somewhat inflexible for today’s cloud and digital enterprises.

Cloud Composer is a managed Apache Airflow service that helps you create, schedule, monitor and manage workflows. There are some big differences between Cloud Composer and AutoSys. A closer look shows why it may be a good time to consider migrating to Cloud Composer sooner rather than later.

Why You Should Migrate to Cloud Composer

Cost savings

AutoSys is a very structure-based, license-heavy application that has inherent complications because of its legacy status. More importantly, its future likely holds few if any substantive upgrades via versioning. This is a big problem for enterprises that must deal with unsustainable costs of IT maintenance and the skills gap needed for management.

AutoSys is a license-based model, so there is a license fee attached to each new job. That adds a lot of extra cost that goes into maintaining and scaling up if needed. Cloud Composer is a usage-based fee model, so as your jobs are scaling up, you’re only being charged based on the amount of resources you use.

Techolution recently collaborated with Google on a migration proof-of-concept (POC) project of legacy AutoSys to Cloud Composer for an education partner. Education is also one of several major sectors that still heavily use Autosys in addition to the financial sector. The POC revealed several major benefits of Cloud Composer over AutoSys, starting with Lower costs.

The cost analysis for this education partner project showed that composer is at least 45 percent cheaper based on historical GCP Cloud Composer project data. This is because the Composer usage model calculates costs based only on the number of machines needed for scalability targets to meet job needs and run data orchestration pipelines.

These costs were based on this education partner project use case for migration where upscaling was the primary goal. However, we can calculate a comparable level of cost savings across other Techolution-led workflow automation migration projects with other sector partners.

Large and growing pool of experts at competitive salaries

Personnel costs for admin and support teams is another important cost savings of Composer because AutoSys uses the Job Information language (JIL) for programming along with Shell scripting. These aspects make it difficult and costly to run and maintain AutoSys because it’s difficult to program and execute tasks in that Shell environment.

Costs become even higher when you need to replace your AutoSys experts that know JIL. The pool of JIL experts is dwindling as fewer young programmers are learning the language. That puts the remaining experts in higher demand, which means higher salaries, if you can get them when you need them.

Composer is based on the ubiquitous Python language, which is far more flexible and provides a growing pool of affordable experts. Python and Java also provide a greater number of efficient tools and technologies that aren’t necessarily available or easily integrated with AutoSys.

Ease of use, integration, transparency, and error tracking

Things like ease of use and integration are always major considerations since time is money with workflow automation across different industries. Cloud Composer has a clear advantage over AutoSys in many ways because:

• The relative ease of learning Composer and its growing base of expert users stands in contrast to AutoSys, which can bring a higher cost of experts in a finite pool.
• AutoSys alerts are very general, which require an admin to manage tracking problems with a task execution list for correction. The support team size is limited because of the JIL language and Shell scripting expertise needs. This means there are fewer people to manage AutoSys and track errors.
• Composer provides specific alerts that enable a broader swath of an IT support team to handle it. This reduces overall time devoted to job management and frees IT support teams to spend more time on other projects. You can also expose more people using the cloud that have little or no coding experience to Cloud Composer.
• Unlike AutoSys, Cloud Composer provides full integration capabilities across any cloud platform or on-premises data center. Cloud Composer provides far more integration tools through Airflow, which is aimed at data pipelines with all the needed tooling.
• The originators of AutoSys did not design it specifically for a cloud world where most tools are cloud-native. Although you can run AutoSys in the cloud, you will have fewer integration options that make pipeline management and scaling easier and more flexible.

It’s important to remember that AutoSys is an application, while Cloud Composer is a web-based tool that abstracts Apache Airflow processes. This ties into making workflows more reliable, transparent, and easy to manage, which starts with the UI. AutoSys and Cloud Composer have very different approaches where:

• The AutoSys GUI lacks a single source of truth and requires moving between several screens to complete or manage a workflow process
• AutoSys makes tracking bugs and errors very difficult with limited alert reporting. This is because the agent that executes each task and any error reporting gets done on the agent. The agent will tell the server there is an error but not what the error is because of its lack of true integration.
• Cloud Composer provides a centralized approach via its web-based command line UI . This eliminates the time and work needed to execute the task and figuring out what went wrong if the task breaks.
• Cloud Composer has several tools that make managing workflows easy, even if you don’t know how to code or program. It’s very visual and very intuitive and allows you to check on the status of jobs on any platform with ease.
• Integrating AutoSys in a technology and cloud stack is very challenging. This is because it requires many manual processes to make that integration work in terms of integrating tools that can automate workflows or make it easier to manage.
• Cloud Composer automates all those integration and management tasks and makes it easy to integrate other services with many template-based open-source tools.

Scalability

Ease of scalability is a major differentiator between AutoSys and Cloud Composer because:

• AutoSys does not provide automatic scaling, which requires provisioning extra machines for heavy data workloads.
• Cloud Composer 2.0 (which is in sync with Apache Airflow 2.0), provides autoscaling that scales servers up or down when needed. This delivers greater cost efficiency and savings by eliminating unneeded resources (over-provisioning) when you complete the job.

Even when migration becomes inevitable with your AutoSys workflow automation application, you ace other challenges. We can see these in terms of personnel, expertise, and discovery across the legacy AutoSys application. Equally important is having the experts that also know Cloud Composer, which often means finding a partner to support the migration.

Having the Right AutoSys to Cloud Composer Migration Partner

Every migration project brings its own specific challenges and AutoSys to Cloud Composer is no different. While we’ve defined just some benefits of cost savings, scalability, and expertise with Composer, it takes an experienced cloud migration partner to realize them.

Techolution composed its team to be experts in all aspects of cloud services with deep experience in the financial services sector. While Techolution is a Google Cloud Premier Partner, they bring the same level of knowledge with AWS and Azure. That cloud-agnostic approach enables them to deliver the right solutions that fit the business outcome needs of every enterprise in financial services and beyond.

By working on a fixed-bid model, they can deliver projects within budget while also devoting any number of experts needed to make it successful. That includes projects where deep AutoSys experience is necessary.

To speak with an expert and learn more about why Techolution should be your migration partner, click here.