The solution we wanted to implement had to fulfill the following requirements:

1. Report on the current state of Components within environment X.
2. Report on the deployment of Components belonging to Release Y.

Within a project the deployment of Release Components occurs over a period of time. Also, a new Release will usually only have a few Components that are really new, with the rest remaining the same as in the previous Release. Therefore the deployment environments are potentially composed of Components that come from many Releases. This is demonstrated in the following two diagrams.

Diagram 1 - Version 1.0 of Release X

Diagram 2 - Version 2.0 of Release X

We use Rational Build Forge (RBF) to automate the deployment of Components. The last step of the deployment project creates a new Deployment History within RAM to describe the outcome of the deployment. This Deployment History is linked to the Component that was deployed. The process is shown in the following diagram.

The Deployment History can also be used to store files, as depicted in the above diagram. These files could be automated test reports, screen captures, stdout captures, etc.

An important point to note is that the link between the Deployment History and the Component is not a RAM relationship. Instead it is a set of attributes within the Deployment History that describe the Component that was deployed, I.e. Name and version. The reason for this “soft” link is to do with the complexities of managing relationships when new versions of an Asset are created. A description of these complexities, with regards to the use of Release Assets, is provided in my previous blog.

For each Component and environment there is a single Deployment History Asset. And each time the Component is deployed to the environment a new version of the Deployment History Asset is created. In the following example Component A, version 1.0, is deployed to System Test twice. Probably because the first attempt failed.

The next diagram shows more clearly how different versions of a Deployment History describe the deployment of different versions of a Component. Component B, version 2.0, is deployed twice as the first attempt failed.

By recording deployments of a Component in this way it becomes easy to see what the most recent version of a Component within an environment is. You just look at the most recent version of the Deployment History. And to see the entire history of deployments for a Component within an environment you just look through all the versions of the Deployment History. This behaviour allows us to fulfill the first requirement, report on the current state of Components within environment X. By looking for the most recent version of the Deployment History linked to each of the Release Components within a particular environment we are able to produce the following report.

Not only does this report tell us what the current Component versions are within an environment, it also checks that all of the Components are part of the same Release. The highest Release reported for UAT is ReleaseX, version 2.0. However, if you look closely you’ll see that ComponentA was deployed as part of ReleaseX, version 1.0. In fact ComponentA did not change in ReleaseX, version 2.0, as depicted in diagram 2 above. The report is clever enough to know this and therefore reports that all Components deployed into UAT are part of ReleaseX, version 2.0. This is only possible due to the expressive power of RAM relationships.

To fulfill the second requirement, report on the deployment of Components belonging to Release Y, we also create a Deployment History for the Release. Each time a Component related to the Release is deployed we not only create a new version of the Deployment History for the Component but we also create a new version of the Deployment History for the Release. However, as there is only one set of attributes in a Deployment History Asset, and we want to use them to link to the Release, we make use of the description field instead. The Deployment History for ReleaseX, version 1.0 looks like the following.

Finally, it may be that some Components of a Release have not been automated and are instead deployed manually. In this case a simple command is executed at the conclusion of the deployment by the deployment team. This command creates the Deployment History for the manually deployed Component and allows reporting to include these Components as well.

“It is a capital mistake to theorize before you have all the evidence. It biases the judgment.” – Sherlock Holmes, A Study in Scarlet

Using agile methods, Odecee will commonly run a workshop where we review the existing performance problems and then ask our stakeholders for their theories regarding the recent poor performance. We then add these as cards to the “To Do” list on our Kanban board. Based on our prior experience we also add theories as cards of our own.

At this point we make sure not to discuss these theories in any detail and emphasise that none of these theories have been proven or investigated in any way. We treat them as “hearsay” until further information is collected so as not to influence the direction of our investigation.

“We balance probabilities and choose the most likely. It is the scientific use of the imagination.” – Sherlock Holmes, Hound of the Baskervilles

The next stage is to apply a methodical, analytical approach to prioritising the most likely causes of poor performance. At Odecee we would commonly have a second round to our first workshop where we ask the participants to consider the current symptoms of poor performance and to consider their past experiences. Then, using agile voting cards, we quickly build a consensus view of the likelihood of the presented theories contributing to poor performance.

This priority is then recorded on the cards on our Kanban board. This defines the order in which we should tackle our investigation, and also builds a single view on approach for our stakeholders at the same time.

“Eliminate all other factors, and the one which remains must be the truth” – Sherlock Holmes, The Sign of the Four

We typically move our Kanban board and place it in a public area for all to see. As we investigate a new theory we move the associated card from left to right on the board, and add comments on the card regarding the evidence that supports or disproves it.

As our investigations identify new theories, we add them to our board in the ‘To Do’ column. We don’t immediately change tack to investigate the new theory – we just rate it according to likelihood and impact and get round to it as its priority suggests. After all investigation has completed for a hypothesis it is moved to the “proven” or “disproven” column and actions to remediate proven hypothesis can begin.

At the end of the agreed cycle period, typically a week, we review the status of our theories and decide whether to continue with further investigation.

In closing, I’m sure that if you keep these 3 quotes in mind, and use a Kanban board to track our activities you will find that it helps attain swift agreement on your teams activities,  and makes the process, progress, and  outcomes more transparent and easily understood to your stakeholders.

So, how do you measure and plan for adequate capacity? Well, the answer is not that trivial. There are a number of really good books in this space, my favourite one being The Art of Capacity Planning, which focuses on production systems capacity measurement and planning, however, does not focus on new systems, e.g. Predictive capacity modeling. Given the differences between the two starting points, l thought l would write this article to demystify the black art that is capacity management for new systems.

Let’s take the simple case, the system is already in production and requires a capacity plan. The approach is trivial, identify what your users are doing, what time of day they are doing it and how many times they are doing it. Measure the system resource consumption and viola, a system utilisation view is presented.  Take this view, multiply it by your projection requirements and there you have it, a view of how much resources you will need in the future.

Let’s take the more complex view; the system is currently under development and user usage patterns are assumed, e.g. not realised yet as the system does not exist. This is where your models are very important (and your assumptions critical) in setting the boundaries for your capacity models. Enduring your performance requirements are accurate and agreed by your business stakeholders is a critical-success-factor in creating and maintaining a valid performance simulation model to base your performance testing strategy and identify your capacity requirements.  Be warned though, this is an assumptions based model and will need to be ratified as soon as your system is deployed and being used by your customers in production.

This is where calibration of performance simulation models is critical in ensuring your performance testing strategy delivers quality data into capacity planning processes.  Without calibrating your performance models with data from production usage, your assumption based performance models will deteriorate over time and will eventually become irrelevant; providing incorrect views of the capacity requirements and performance of your production system.  A good rule of thumb here is to recalibrate your performance simulation models at the end of every month after a new release of features or software into production.  This way, you have enough time to measure what your users are going in production and feed that back into the development and test cycles.

Unfortunately, l see huge number of projects neglecting calibration oriented due-diligence  and it often leads to production incidents.  If you find yourself asking “why have my performance tests passed and given me a stable view in our pre-production environment, yet the application performance requirements have failed when we deployed into production?”, well, the answer is in the question “how relevant is your performance simulation model?”.

Ensuring your performance testing approach remains relevant and accurate requires calibrating your performance models on a frequent basis.  The act in thinking about, designing and implementing a calibration approach helps you solve a number of other concerns relating to production monitoring and data gathering.  A presupposition to calibrating your performance model is understanding the monitors that are important in production! Wow! Talk about killing two birds with one stone.  As if that was not enough benefits to jump right into calibration, approaching calibration activity often yields massive insightful benefits into how to correlate your metrics and provide alarm scenarios when capacity shortages or problem scenarios are on the event horizon.  I will rest my case here.

So, to keep your performance testing approach in a healthy and relevant state, model calibration is a critical requirement to performance due-diligence.  The benefits extend into production support teams and furthermore, save the business in over-capacity spend and reduced production outages.

Till next time.

Whilst Continuous Integration has addressed the concerns of rebuilding software and deploying software to development environments there is still a gap on how software packages and configurations and managed and promoted between environments.

A solution that Odecee put forward to a tier 1 customer was the integration of Odecee’s Build Pipeline solution that defines quality processes from the point that software is built all the way through to software delivery and rollout to target environments – we called this solution the Enterprise Build Pipeline. This solution required a base set of tools to support the Odecee Build Pipeline processes and controls.  This is when we partnered up with Rational to integrate into our solution the Use of Rational Team Concert, Rational Asset Manager and Rational Build Forge with a view to improve interoperability of the tools leading to a tightly integrated tooling implementation.  This solution gretaly improved the tracability of configuration and software assets.

I will explain how each of the Rational tools were implemented in the enterprise wide configuration management solution:

Development teams use Rational Team concert for version control of their source code and, through the process template configuration, are able to utilise best practices in source code baselining and leverage RTC’s CALM features.

At the heart of our Enterprise Build Pipeline solution, Odecee has developed a custom Rational Asset Manager schema that is used to control and manage software deployment assets. This facilitates the capturing of key metadata associated with software assets and defines the process of how software deployment components are related.  One key design element and component of the Enterprise Build Pipeline solution was the implementation of a dependency management capability in RAM.  Rational Asset Manager does not have the capabilities to track dependencies as they are retrieved (or queried) as related to software assets.

The integration between Rational Team Concert and Rational Asset Manager has been automated through Build Forge via and automated build process that retrieves source then compiles and creates the software package for deployment which is automatically published into Rational Asset Manager via this automated process and provides full traceability back to the source from which it was constructed.

Build Forge is also used for the automated deployment process that extracts the Software packages and dependencies from Rational Asset Manager through the RAM API that has been extended to conform with Odecee’s RAM Schema, making the integration seamless. This automated deployment process deploys and configures the software packages to the all target deployment environment using the same deployment process and same environment agnostic software package.

This solution, integrated with the Rational tools will give you control of your environments and your software delivery cycle, reducing time it takes to deploy and configure software, as well as promoting consistency across environments and hence reduce risk.

My initial response to resolve this conundrum was to set up a database, import the data and query for the relevant data from within the LoadRunner script. This should work, Right?

Wrong. With timelines tight and the Projects (in)ability to install the database software on appropriate machines meant possible delay in testing that could be ill afforded. Getting the data was not a problem, however setting up a database instance required that 7 letter word starting with a P (Process). The Process required approval to install the software and also schedule times and resources to implement. These inhabitants plus the lack of experience by the tester to execute and setup database scripts within LoadRunner led me to think of a Plan B!

Therefore, Plan B was to handle this data requirement with some code within LoadRunner. How was this achieved? Firstly, two parameter files had to be created and handcrafted with the following format.

And below is the first cut of code to get a matched searchTerm for the loggedOnUser.

Action {
   // assumed vuser_init contains your logon details but for this example i'll assume the username is coming from a param file
   // LoggedOnUser therefore "loggedOnUser" is defined in vuser_init.... as a Unique & Once Parameter.
   // Basically loop through your param file to ensure that the loggedon user the right search terms.
   // Your param file will need to look something like this
   //  searchUser, searchTerm
   //   vuser1, john
   //   vuser1, odecee
   //   vuser1, perform
   //   vuser2, test
   //   vuser2, simple
   //   vuser3, wow
   //   vuser3, expert
   while  ( (strcmp(lr_eval_string("{loggedOnUser}"),lr_eval_string("{searchUser}")) != 0)) {
      lr_advance_param("searchTerm");
      lr_advance_param("searchUser");
   }

   lr_output_message("Test variables are Iteration: [%s], LoggedOnUser: [%s], SearchUser: [%s], SearchTerm : [%s]",
   lr_eval_string("{Iteration}"),
   lr_eval_string("{loggedOnUser}"),
   lr_eval_string("{searchUser}"),
   lr_eval_string("{searchTerm}"));
   return 0;
}

Very simple piece of code to meet the requirements and no database in sight! Less than 30 minutes. Only overhead is crafting together parameter files to allow for the code to work.

However, (always one but!) a couple of issues were discovered. When the script was executed in a Scenario some of the Virtual users were failing with the error:

Error (-17991): Failed to add item to mfifo data structure

Some troubleshooting investigations found a couple of issues. First issue was that the data provided for the two files had a mismatch of data. The loggedOnUser file contained users that did not match to the searchUser therefore the script would iterate and loop through and eventually cause the virtual-user to abort due memory issues.

This leads quite nicely to the second issue with the above approach – the way lr_eval_string allocates memory internally within LoadRunner. For lr_eval_string, the memory is freed at the end of each iteration and in the code sample above, the virtual-user is evaluating a parameter as part of a loop. Generally loops of smaller size the lr_eval_string function would not be an issue. However, for this particular requirement the loop was over 200K+ records.   This memory overhead impacts the scalability of the load generators as well.

As part of the more thorough testing, I monitored the mmdrv process with the above code only in a script. The mmdrv process grew from ~8000Kb to just over 40,000Kb looping through only 100K records. If the mmdrv process is large already than this code can cause a memory issue (or two!).

The solution to conserve memory is basically to not to use the lr_eval_string function at all. Instead, use lr_eval_string_ext to assign the variable and free the memory on each iteration of the loop using the lr_eval_string_ext_free.

So here is the new code with (i) an additionally condition to check for data mismatches and (ii) more importantly using the lr_eval_string_ext and lr_eval_string_ext_free functions to handle the memory within the iteration and its multiple loops.

When tested, the mmdrv process for 300K loop within an iteration stays at ~8000Kb (previously grew to 40 000Kb). Here is the code.

Action2()
{
   unsigned long prmLen;  //required to be set for use by  lr_eval_string_ext
   char* buf; //required to be set for use by  lr_eval_string_ext

   int loop = 0;
   int match = 0;
   int maxfilesize = 200000;  // set this variable to stop the script from goin into a loop. Set to Size of   your Param file +1
   char loggedOnUser[16]; //might need to change this dependant on string-length of usernames

   // save  logged on user Id here
   strcpy(loggedOnUser,"");
   strcpy(loggedOnUser, lr_eval_string("{loggedOnUser}"));

   while( (match == 0)  && (loop < maxfilesize))  //can change the loop variable     {       

      lr_eval_string_ext("{searchUser}",strlen("{searchUser}"), &buf, &prmLen, 0, 0, -1);       

      lr_output_message("ONE => buf=%s   and  loggedOnUser = %s", buf, loggedOnUser); 

      if   (strcmp(loggedOnUser,buf) != 0)  {
         lr_advance_param("searchUser");
      } else {
         match =1 ; //break out after match to searchuser and loggedOnUser is made!
      }

      // lr_output_message("Iteration %s => buf=%s, loggedOnUser = %s, searchTerm = %s ,    and loop = %i", lr_eval_string("{Iteration}"), buf, loggedOnUser,
      //         lr_eval_string("{searchTerm}"), loop);

      lr_eval_string_ext_free(&buf);  //dont forget to free!
      loop++;
    } //end of while loop

   if (loop >= maxfilesize) {
      lr_error_message("Iteration %s => buf=%s   and  loggedOnUser = %s   and loop = %i", lr_eval_string("{Iteration}"), buf, loggedOnUser, loop);
      //exit user cos if this max is reached the script is looping through as NO  match to users can be made in the param file. This is the first issue!
  }
 return 0;
}

Overall, once the memory issues were resolved and appropriately catered for, then this code was more than adequate to meet the requirements specified above. Testing continued and was a success, all without a need for a database!

What makes relationships so great is that they allow the dependencies between Assets to be mapped.  Further to this, they provide a very easy way to navigate these relationships.  Each Asset has its relationships displayed as hyper links within the Assets general page, and this makes it very easy to navigate between Assets, see below:

The previous screen-shot is of the relationships within a SubSystem Release Asset called BAR.  A SubSystem Release has relationships to its parent System Release(s) and also the Components of the SubSystem.  From this example we can see that this SubSystem Release is related to 2 versions of the System Release and has 3 separate Components.  The diagram below shows where this Asset lives within the release hierarchy.

Now here’s where things get tricky.  When creating a new version of an Asset all of the relationships are copied into the new version. This is good as you would not want to recreate them each time. However it does lead to some unfortunate side effects, as depicted in the following example.

In this example we want to create new versions of the ACME System Release and BAR SubSystem Release.  The FOO SubSystem Release will stay the same.

Start State

So this is what our start state looks like:

Create new version of System Release

When we create version 2.0 of the ACME System Release the relationships from version 1.0 are copied over.  This is OK for the moment as we have not yet created version 2.0 of the BAR SubSystem Release.

Create new version of SubSystem Release

When we create version 2.0 of the BAR SubSystem Release the relationships from version 1.0 are copied over.

However, we now have a number of incorrect relationships.  Version 2.0 of BAR has a relationship to version 1.0 of ACME.  Obviously not what was wanted.  Also we no longer want version 1.0 of BAR to point to version 2.0 of ACME.  The incorrect relationships are highlighted in the diagram below.

This problem only gets worse as more new versions of assets are created for a release.  And we are not even describing  creating new Components in the above example.  To fix this you would manually remove the incorrect relationships but this is both error prone and time consuming.

Ensure new SubSystem Release version only relates to the new System Release version

A new version of a SubSystem Release should only ever have one parent, the System Release for which it was created.  Later on the SubSystem Release may end up belonging to multiple System Releases, but at this point in time it should only relate to a single System Release.  So we remove the relationships to all other System Releases.

Ensure previous SubSystem Release version does not point to new System Release version

As we saw earlier, when we created a new version of the ACME System Release all the relationships were copied over.  This meant that we ended up with a relationship to version 1.0 of BAR.  However, since we have created a new version of BAR we no longer want to relate to version 1.0 of BAR from version 2.0 of ACME.

And now things look as they should.

However, fixing things up manually is less than ideal.  If you look again at the tasks above then you can see that the manual solution is really a high level design for an automated solution, as below:

Create new version of System Release

For each new version of a SubSystem Release

Create new version of SubSystem Release

Ensure new  SubSystem Release version only relates to the new System Release version

Ensure previous SubSystem Release version does not point to new System Release version

In a recent role, I was referred by a client as a “Performance Engineering expert”.   Which brings me to ponder this thought, “do Performance Testers and Performance Engineers perform the same role?”.  How similar are Performance Testers and Performance Engineers?

In my humble opinion, there is a clear distinction between the services provided by a Performance Tester and Performance Engineer.

Let me expand firstly on the roles of each. Firstly, for a bit of clarity, I am grouping the roles of the Performance Analyst, Performance Lead and Performance Manager within the boundaries of a Performance Tester. Therefore, some of the roles and responsibilities of a Performance Tester are as follows (not a definitive list), design and execute a Performance Test Strategy and Plan; design a Application Simulation Model (ASM); build the automation suite and artefacts;  build monitoring and metric gathering solutions; execute test and tuning cycles; analyse results against requirements; and reporting to business stakeholders. These are some of the roles that are considered and commonly accepted as Performance Testing resource role and responsibilities.

Whereas, a Performance Engineer has in-depth expertise in development and infrastructure components that assist them to provide services such as code reviews; running up profilers (application profiling); investigating environment configurations; reviewing performance best practices; tuning and supplying remediation activities to performance problems. In short, the Performance Engineer provides the in-depth expertise to resolve performance related bottlenecks.

Just to highlight the difference, a former Performance Test colleague once mentioned to me that their role is to discover the performance defects and report against the requirements. If a system or application does not meet its requirements, a defect is raised which then becomes a development/project problem to resolve. This is the true definition of a Tester on any project (albeit Functional or Performance). Their strengths are within the delivery and scope of “testing” processes and as l mentioned before, their roles as a Performance Tester would be focused on delivering a performance quality management solution (test processes, test artefacts, test metrics and reporting). This is where the Performance Engineer provides the value add. In this instance they will analyse the outputs of the test metrics and provide remediation activities or solutions to the development and infrastructure teams to ensure performance problems are resolved.

Having said all of the above, an excellent Performance Tester must have some (but not detailed) knowledge of Engineering activities. The accomplished Performance Tester is able to identify the bottlenecks, whether infrastructure, application code or JVM behaviour and assist to resolve these issues. An example might be that a good Performance Tester should be able to use tools such as HP Diagnostics to identify time spent within an application under loaded conditions.

And this is why Performance Testers are in a unique field. They are expected to have the knowledge and expertise in the Performance Test domain best practises and also have the expertise in resolving and remediating performance defects via engineering initiatives.

This is where, at times, the distinction between the Performance Tester and Engineer can become grey and perhaps why the terms are commonly used in place of each other.

From my experience, for a performance program to achieve best results a performance team must be compromised of both performance testing and performance engineering disciplines (SME’s). My experiences over the last few years have highlighted that to deliver successful performance programs these two roles must work closely together in a performance team, with one supplying the testing methodologies/artefacts and the other analysing such results from the testing to determine and remediate the performance defects.

I will leave you with this thought, could (and should) a functional tester inspect code to resolve a defect?  My humble opinion is “no”, that is the responsibility of the development team. We don’t refer to a functional tester as a functional engineer? In the performance version of testing and as aforementioned at the start of this blog, I believe that the Performance Testing and Performance Engineering roles are two distinct roles with differing deliverables and responsibilities. These two distinct roles are important cogs in any delivery of a successful Performance program.

• The EAR file
• A deployment guide for the EAR
• A deployment script for the EAR
• Informational fields describing the version, owner and source baseline of the EAR
• Relationships to other Assets (more on this later)

The types of Asset that can be maintained by RAM is limited only by your imagination. However, for our purposes we wanted to represent the artefacts that are created and deployed as part of the SDLC. And it was with this in mind that we set to work. Whatever shape the schema took it had to meet the following requirements:

• Store and describe a deployable unit, including its related artefacts
• Describe the release that the deployable unit belongs to
• Describe the deployment of the deployable unit
• Control access to the Assets
• Simple to maintain
• Easy to search

The initial design was quite large and cumbersome. However, it was really just a starting point. Over the next few weeks we managed to pair it down until it was lean and yet still able to represent even the most complex of release scenarios we could envisage. The final design had only three Asset types, as below:

Release

A Release Asset is used to describe a release. It has the release note attached to it. It can also maintain other artefacts that are related to the release. It has relationships to the Components of the release (see below). It can also have relationships to other Release Assets. This allows release hierarchies of systems and sub-systems to be modelled.

Component

A Component Asset is a generic container for a collection of artefacts that logically fit together. For instance a Component could contain deployables, deployment scripts, tests, etc. A Component has a relationship to one or more Releases. It can also have relationships to other Component Assets.

Deployment History

A Deployment History Asset is used to describe the deployment of either a Release or a Component. It does not have direct relationships to either Release or Component Assets. Instead it has attributes that describe the relationship. It also has attributes for deployment time, date, environment and status.

The combination of these three Asset types, and their relationships, allows us to construct quite complex release hierachies, as depicted in the following diagram.

In fact RAM is just one of the tools that we use within the Build Pipeline . And of course there are many other aspects to the RAM design. Perhaps that is something for another article.

Modern vitualisation approaches have changed the landscape in environment management in the area of hardware consolidation, configuration management centralisation, infrastructure architectural flexibility and general management of operating systems.  As result of the benefits of virtualisation, we have seen an increase in the number of environments in the SDLC, which (as you would expect) has also increased the configuration management overheads.  Deployments are one of the critical functions executed by the environment management team, and due the increasing number of environment and complexity in modern infrastructure architectures, configuration management is getting more complicated and time consuming.  Our novel approaches of the past are not scaling to meet our insatiable appetite for the benefits of virtualisation.  As a consequence, our costs in environment management are increasing and the benefits of this additional cost are not being realised.

So, where to from here?  Well, l believe the solution lies in Environment Models and a smart configuration management strategy that is deployment focused.

When we design internet facing business systems, we get our customers to specify their requirements and we then architect, build and test them.  Why, as infrastructure architects and environment managers don’t we go through the same specification process?  We should be specifying our environments in a way that will optimise our ability to deploy to them and manage their configurations.  Seem’s simple really, yet we don’t seem to want to apply the same diligence to our internal processes as we do to our customers requirements.

This is where Environment Models come into the picture.  My definition of an Environment Model is an environment that is built for the purposes of being used in the SDLC, where the entire collection of environment components are version controlled, labeled and unique.  This way, we can construct an Environment Model once (this is what l call the Genesis Environment Model), and use it as a basis to build other environments.  Figure 1 represents an Environment Model.

Figure 1. Environment Model

One of the biggest advantages of Environment Models is the consistency they present in terms of architecture, design and configuration.  This makes deploying to them more consistent and predictable.  If you have not already been able to see it, there are some greater benefits to Environment Models that we can exploit – deployment standardisation.  Building our deployment and configuration tools right into our Environment Models can significantly improve our ability to deploy to these environments.

Till now, l have proposed the benefits of Environment Models and how they can standardise the definitions of environments, standardise the deployment & configuration methods and improve the overall configuration quality and traceability of our environments in the SDLC.  By following the approaches discussed here and applying them to a virtualisation platform (VMWare, AWS), will certainly take you many steps closer to copy-and-pasting of environments.  Now, wouldn’t that be a great alternative to what we have today?

Till next time.

In my journey, one clear truth has emerged; applications have a tight and brittle dependency on any given environment; specifically hostnames, schemas, URL’s, et. al.  It is clear that abstracting away these environment specifications is key to enabling a seamless application configuration and realise rapid environment constructions/configurations.  This dimension is further compounded by the speed to which business expect product and system delivery in today’s modern SDLC’s.

Copy and paste environments have been a vision for many environment engineers, where the possibilities have been pondered and drooled over, however, l have never seen an implementation of the strategy in my travels.  Reflecting on my application architecture experience, coding to interfaces, dependency injection and abstraction rate very highly as useful tools and techniques that can be utilised to increase flexibility, promote reuse and improve architectural flexibility.  Similarly, these principles can (and do) apply to environment configurations.  Designing environments that lend themselves to an automated deployment strategy is as simple as defining requirements and creating an infrastructure architecture to implement those requirements.

Copy and pasting environments have one large, perceived drawback – each environment is an exact replica of the copied version;  exact copies of server names, DNS entries, Active Directory and group polices can seem to be restrictive, after all, for the servers to be useful, the server names will need to be changed to avoid server name collisions.   This might seem like a disadvantage, however, isn’t this a feature which we can take advantage of?  Having environments that are identical in configuration can be exploited from an deployment perspective because the system in exactly the same as the master and will minimise change in deployment scripts.  A strategy and solution to this problem is a “Network Bubble” – isolated collection of servers which are not (directly) accessible to a global network and avoiding the server name collision problem.  Access to these environments are configured into the broader network and guided through front-end Web servers; promoting encapsulation of function and abstraction of environment configuration details – Platform-as-a-Service (PaaS).

VMWare Lab Manager is a tool that can provide the software functionality and network isolation features which can realise your PaaS objectives and enable Environment Models.  PaaS objectives can also be realised through Amazon Web Services utilising Virtual Private Clouds and Elastic IP’s.  The choice between these two options is an outsourcing decision.  Both options present strong and compelling features that should be considered when building environment management strategies for our future projects.

Our old novel approaches of the past can no longer scale to meet the growing drive for new and refreshed business systems.  To meet our customers demands, we cannot afford to solve environment management problems using manual or traditional configuration management strategies.  Taking advantage of cloud based design patterns and bridging the gap between software configuations and deployment environments is critical in providing the agility and speed required to keep our customers competivie and ahead of the game.

Till next time!