Automic Workload Automation

I've recently found Automic has been installed and setup with multiple clients created on a single AE system with the intention to use a different client for each environment - prod, pre-prod, SIT, DEV etc. My concern is that all these environments will being sharing resources to a large extent - both at AE level and at physical server level also. My preferred choice would have been to at least separate the Prod environment into a different AE system and probably on a separate physical server as well. Does anyone have any views or past experience they can share on this subject. Thanks.  

Even as a small shop, we split prod to its own server.  Supporting two separate AE's can double admin work, so there could be resistance in that regard.  But it is the right thing to do.

With your current configuration, a developer could bring your production operations to its knees. (not likely, but technically possible.)

I would also hope that your prod and non-prod clients use different credentials when accessing databases, files, and other systems.  Otherwise you open yourself up to the risk of prod accidentally using dev data, and dev accidentally using prod data.

Thanks for reply Pete.

Yes the clients are all using different specific access credentials for everything - It's just the sharing of the production environment with non production work which I'm not comfortable with for exactly the same reasons you've stated and a few more - during all my time in Prod Ops this has always been a definite non starter!  

We have four environments:

• Experimental (EXP) — Just for testing infrastructure components and new features.
  
• Development (DEV) — Development of AE batches (read, write & execute access)
  
• Integrated Test Environment (ITE) — Testing AE batches (read & execute access)
  
• Production (PROD) — (only read access is allowed)
  

Each environment is physically distinct. Each has its own:

• DB (Oracle RAC with active/passive configuration & one node in each data center)
  
• Hardware (2 VMs, each running in a different data center)
• OS (SLES)
• Automation Engine (2/3 CPs and 7 WPs per VM)
  

Running separate systems gives us peace of mind. We know that DB, hardware, OS, and application failures in one environment will not affect other environments. We also know that performance issues in one environment are unlikely to impact the other environments.

This approach also gives us a great deal of flexibility. We can apply different system-wide settings in each environment. We can upgrade individual components in one environment without affecting the other environments. And we can perform proper isolated testing when fixes or new features are made available. When it comes time to install a service pack, we typically test it for a while in EXP, and then roll it out to DEV, ITE, and PROD over the course of a month or two, with a couple of weeks in between each stage.

We developed an application for promoting batches of AE objects from DEV to ITE and PROD. It is based on the transport case mechanism, and is fully integrated into our source code management and service management systems. Deployments to production require an approved change request. Deployments are fully automated, and do not require human intervention. We are the the process of developing a replacement batch promotion/deployment system that is based on the XML export file format.

Major version upgrades complicate matters somewhat, because the transport case file format is not backward compatible. This means that when we upgrade our AE systems, we face a choice:

• Either upgrade DEV, ITE, and PROD together in quick succession,with little time for testingat each stage;
  
• Or upgrade DEV, ITE, and PROD in stages as usual, butdisallow batch promotion during the time when the source environment (DEV) is running a newer version than the target environments.

Neither option is very palatable, so we are accelerating our migration to an XML-based solution for batch promotion.

Thanks for taking the time to reply Michael.

The environments & processes you describe are very much the same as what I'm used to working with and just reinforces my concerns with the current setup I'm now working with.