Don’t Shortchange Your IAM Dev Environment

Don’t Shortchange Your IAM Development Environment

Here at IDMWORKS, we have worked with many different clients across a wide range of sectors – from higher education, to finance, retail, and more. This experience has given us an informed perspective on some of the common challenge faced during an Identity and Access Management (IAM) implementation. In almost every case, cost is a significant constraint. As a result, organizations are forced to trim costs wherever they can, and frequently that means deploying a development IAM environment on the cheap. While in the short term this might seem like a good strategy, in the long run it can actually cause a lot of pain.

Don’t shortchange your Dev environment!

On the surface, this might sound counterintuitive; your development environment is supposed to be a light duty installation where you can test drive your software before migrating to QC and Prod. Or perhaps your “Dev” environment was originally a proof of concept and now it’s a part of your infrastructure – we don’t need a lot of power for Dev, we just need enough to make it work – right?  I respectfully disagree.

For starters, some of the Identity and Access Management (IAM) products are resource hungry. If you don’t have enough horsepower, things are going to be way too slow. Recently, I experienced an application server that took more than 30 minutes to startup in Dev – the same app server launches in less than 5 minutes in production. What are you going to have your team doing while they sit around and wait for 30 minutes for the Dev instance to start? Keep in mind that you’re going to be restarting Dev many times – configuration changes, app deployments, or even installs could happen frequently in your development lifecycle, so you don’t frequent development restarts taking more than a few minutes tops – anything longer and you’re just wasting time.

Another reason you don’t want to short change your development environment is that you have to be able to adequately simulate your production processes. You don’t want to encounter issues for the first time in production simply because your development (or QC) environments weren’t powerful enough to adequately simulate production. We have seen issues in the past where things would break when they were deployed to production even though all testing in dev and QC passed with flying colors. When we did some digging and found the root cause, we found that these were issues that had not shown up in testing simply because the production environments were dramatically different from Dev and QC.

Really there are two takeaways here:

  1. Make sure you have enough juice in Dev
  2. Make sure Dev is a capable stand-in for your production system for testing purposes.

We know it can be tough to justify spending more on your development environment, especially in this economic climate. However, we think you’ll find the time wasted in waiting for servers to start or chasing mystery issues in production will more than outweigh any short term budgetary gains.