Comments (4)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 HelmutRiegler commented Permalink

Thank you for this interesting article. I am interested in the following questions: <div>&nbsp;</div> .) How do you handle application data when you provision a new environment from scratch? <br /> .) Do you have experience or best practice about how to migrate from an existing mainly manually maintained system to a fully automated solution? <br /> .) What would be a good parctice to handle separation of duties in a Service Delivery Center? i.e. if production access is limited and be handled by a separate organization?

2 tivolimarathon commented Permalink

Thanks Helmut for your comments and great questions. <br /> The first thing you need to understand is that we are (though in an extensive one) still in a pilot phase, so things are developing and need to be defined for the final design. This is true the case for the application data. <br /> Currently we have captured all required application data within the DB image template that we spawn up throughout the test stages. Within the production environment (active and passive line) we have a HAD cluster that is not re-provisoned all the time, but re-used. That means new lines are connecting to the exsiting cluster. <br /> Moving forward we could pump data into the DB layer by either using appropriate SQL scripts as part of the DB component worklflow inside uDeploy or integrate with some tooling like Liquibase, Optim or any other tooling that handles this. <div>&nbsp;</div> Your question regarding the spearation of duty is heavily discussed. The Service Delivery Center per definition is the owner of the systems after they are provisioned since they have the operational responsibilities. In other words, they are root. Now, there will be cases where the dev team will have the requirement to have high privileged access to the systems. We either will give them root rights as well and have appropriate technology in place to log all accesses or provide them with "root like" access - in any case we need some intensive looging facility. <br /> But don't forget, one of the main paradigms of this implementation is that we want to reduce the amount of changes within the running mode of the systems. We want to follow the principle of "a change is a change" - all changes are modeled and defined at the beginniing of the pipeline. E.g. a patch to the OS shouldn't be applied to a running instance, but to the model that feeds the CD pipeline <div>&nbsp;</div> Talking about Best Practices at this point in time would be a great word. <br /> Hope that helps

3 RandyTangco commented Permalink

I am interested in the use cases you have.

4 andedgar commented Permalink

Very good article. What technology did you use for the "patterns" to deploy the application stack? With the new announcements of Pure on SoftLayer the use of the Pure Application Systems pattern technology would be an interesting addition to this use case.