I'm struggling with what feels like a logical conundrum. There is nothing explicit in the definition of a Technology Build Architecture that specifies deployment role - that only comes with the creation of an Application Deployment that uses the Technology Product Build based on the architecture. This should mean that I am able to use the same technology product build architecture for all instances of my application that share the same technology providers; the same fundamental architecture.
In practice this isn't the case when using the core_app_def report. Within that report the list of deployments is established, the product build identified, and then all instances of the Technology Provider Usages are assumed to be associated with this one deployment role - but of course multiple deployments having different roles could all use the same technical architecture. What I end up with is the same dev, test and production technology instances repeated for every environment - because they're all the same technology provider usages.
What it feels is missing is the ability to tag an infrastructure software instance as being a technology provider usage in the context of an application deployment, not just the architecture. That would allow us to more precisely identify the deployment role of an instance without the burden of multiple, redundant, copies of the build architecture - one per environment.
Hope that made some kind of sense, it's quite a bit to get my head around!
Kevin
Technology Builds and App Deployments
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
I think I understand where you're coming from but I think it might be case of how you're approaching how you think about Application's use of Technology.
An Application Deployment is actually deployed via it's Application Software Instances directly to Technology Nodes. The Technology Architecture that we select to support each deployment is a logical specification of the technology that we require to support the deployment. In terms of the core_app_def view this provides the scope for the physical infrastructure software and hardware that is supporting each deployment.
An Application Provider can have multiple deployments - e.g. Development, Test, Production and each of these can have separate supporting Technology Product Builds - or if it makes sense can share them.
We have a options in terms of how we define the physical technology in the model. Taking a top-down approach we can go through each Usage in the logical Technology Product Build and 'deploy' it to one or more Technology Nodes - as if we were installing the infrastructure software on the node. In practice, even in a current state capture, working bottom-up, I tend to take this approach as it's a bit trickier to map from an Infrastructure Software Instance up to the correct usage. The Product Build tells us what technology infrastructure we need to have in place and we can just work through it, deploying the technology as per our physical configuration.
If our Technology Strategy is provide a set of well-defined, shared infrastructure, e.g. for database servers, application servers etc. to be shared by a suite of applications, then we can define these standard builds of infrastructure and then 'deploy' the instances of it to the nodes in our architecture. Typically, the build won't describe, e.g. how many application servers we need but we can deploy multiple instances of it to the required servers and then define the specific interdependencies between the instances in that deployment that described in the logical architecture.
So, e.g. our logical architecture says we need an application server that depends on a RDBMS and they both need a server. We could deploy that so that they are co-located on the same server and when we do that, both instances will depend on the node and we define the dependency between that application server instance and the RDBMS instance. However, we could deploy each to their own server. In which case we still define the dependency between the application server and the RDBMS.
Now, this might be our standard App Server Build but we need many of these - perhaps we decide that each Web Application has it's own App Server Build deployment. In which case, the Web Application uses the standard App Server Build but is deployed to the specific Nodes (servers) assigned to it. And on those servers, the App Server and RDBMS are defined to depend only on each other (and not all other instances of RDBMS).
Where I'm going with this is that the logical is a design-time artefact that describes the dependencies that we have designed in that technology architecture. In the physical, apart from the clear dependency between an instance and the node that it is deployed on, all other dependencies must be explicitly defined between the instances - guided by the dependencies defined in the logical architecture - because in our distributed systems landscape there are many inter-node dependencies that exist but in actual physical terms, via the network, all the nodes are connected to all the other nodes - it's through the dependencies between the physical technology instances (application software, infrastructure software and information stores) that we define what's actually been configured in the software at a physical level.
Note that it's only technology things that are physically residing on Technology Nodes - application software instances are the configured software packages that 'are' the application, information stores are the database instances that depend on an instance of your favourite RDBMS and so on.
What does this mean for the core_app_def view, though?
First, this View finds all the deployments of the Application either directly through the deployments slot on the Application Provider or, additionally, it explores the deployments of the software components defined in the supporting software architecture of the Application Provider.
For each of the deployments identified, it finds the supporting Technology Product Build and finds all the instances (deployments) of the products that are used in that build. Note that this is not all the usages of each product across the enterprise, but just the instances (deployments) of each product that is related explicitly to each usage in that build.
From this set of technology instances, the set of relevant technology nodes are identified and from this list the view reports the physical technology that is relevant for that Application Deployment.
If you have more than one deployment for your application, you will see a table for each 'environment' that shows all the nodes that are involved and all the technology instances that are defined in the Technology Build that are deployed on each node.
If your application deployments are sharing technology builds, then each environment table will hold the same stuff except for the application software instances - which should just be the instance of that application deployment at hand, e.g. Development, Test, Production.
I think the key point is that there is no derived relationship between a particular Application Deployment and the technology that supports it that follows the deployment role. e.g. Just because we have a development deployment of an application, doesn't necessarily mean that the infrastructure to which it is deployed is also 'development'. It might be - and we can capture that - but equally, we could have a development deployment of an application running on production infrastructure. We can't assume anything in the Views but we can (and need to) explicitly capture these subtleties in the model.
Apologies for the length and depth of this reply - I hope it helps provide some more detailed background to the approach for physical application and technology and helps to take this discussion forward.
Jonathan
An Application Deployment is actually deployed via it's Application Software Instances directly to Technology Nodes. The Technology Architecture that we select to support each deployment is a logical specification of the technology that we require to support the deployment. In terms of the core_app_def view this provides the scope for the physical infrastructure software and hardware that is supporting each deployment.
An Application Provider can have multiple deployments - e.g. Development, Test, Production and each of these can have separate supporting Technology Product Builds - or if it makes sense can share them.
We have a options in terms of how we define the physical technology in the model. Taking a top-down approach we can go through each Usage in the logical Technology Product Build and 'deploy' it to one or more Technology Nodes - as if we were installing the infrastructure software on the node. In practice, even in a current state capture, working bottom-up, I tend to take this approach as it's a bit trickier to map from an Infrastructure Software Instance up to the correct usage. The Product Build tells us what technology infrastructure we need to have in place and we can just work through it, deploying the technology as per our physical configuration.
If our Technology Strategy is provide a set of well-defined, shared infrastructure, e.g. for database servers, application servers etc. to be shared by a suite of applications, then we can define these standard builds of infrastructure and then 'deploy' the instances of it to the nodes in our architecture. Typically, the build won't describe, e.g. how many application servers we need but we can deploy multiple instances of it to the required servers and then define the specific interdependencies between the instances in that deployment that described in the logical architecture.
So, e.g. our logical architecture says we need an application server that depends on a RDBMS and they both need a server. We could deploy that so that they are co-located on the same server and when we do that, both instances will depend on the node and we define the dependency between that application server instance and the RDBMS instance. However, we could deploy each to their own server. In which case we still define the dependency between the application server and the RDBMS.
Now, this might be our standard App Server Build but we need many of these - perhaps we decide that each Web Application has it's own App Server Build deployment. In which case, the Web Application uses the standard App Server Build but is deployed to the specific Nodes (servers) assigned to it. And on those servers, the App Server and RDBMS are defined to depend only on each other (and not all other instances of RDBMS).
Where I'm going with this is that the logical is a design-time artefact that describes the dependencies that we have designed in that technology architecture. In the physical, apart from the clear dependency between an instance and the node that it is deployed on, all other dependencies must be explicitly defined between the instances - guided by the dependencies defined in the logical architecture - because in our distributed systems landscape there are many inter-node dependencies that exist but in actual physical terms, via the network, all the nodes are connected to all the other nodes - it's through the dependencies between the physical technology instances (application software, infrastructure software and information stores) that we define what's actually been configured in the software at a physical level.
Note that it's only technology things that are physically residing on Technology Nodes - application software instances are the configured software packages that 'are' the application, information stores are the database instances that depend on an instance of your favourite RDBMS and so on.
What does this mean for the core_app_def view, though?
First, this View finds all the deployments of the Application either directly through the deployments slot on the Application Provider or, additionally, it explores the deployments of the software components defined in the supporting software architecture of the Application Provider.
For each of the deployments identified, it finds the supporting Technology Product Build and finds all the instances (deployments) of the products that are used in that build. Note that this is not all the usages of each product across the enterprise, but just the instances (deployments) of each product that is related explicitly to each usage in that build.
From this set of technology instances, the set of relevant technology nodes are identified and from this list the view reports the physical technology that is relevant for that Application Deployment.
If you have more than one deployment for your application, you will see a table for each 'environment' that shows all the nodes that are involved and all the technology instances that are defined in the Technology Build that are deployed on each node.
If your application deployments are sharing technology builds, then each environment table will hold the same stuff except for the application software instances - which should just be the instance of that application deployment at hand, e.g. Development, Test, Production.
I think the key point is that there is no derived relationship between a particular Application Deployment and the technology that supports it that follows the deployment role. e.g. Just because we have a development deployment of an application, doesn't necessarily mean that the infrastructure to which it is deployed is also 'development'. It might be - and we can capture that - but equally, we could have a development deployment of an application running on production infrastructure. We can't assume anything in the Views but we can (and need to) explicitly capture these subtleties in the model.
Apologies for the length and depth of this reply - I hope it helps provide some more detailed background to the approach for physical application and technology and helps to take this discussion forward.
Jonathan
Essential Project Team
-
Kevin Campbell
- Posts: 40
- Joined: 13 Sep 2010, 20:26
Hi Jonathan
Thanks for taking the time for a detailed reply, especially so late at night!
What I have found is that if I have a single deployment technical architecture, used in two application deployments one for dev and one for test, when viewing the core_app_def report all infrastructure instances are shown in both dev and test sections of the table.
Take the DB for example: both dev and test deployments will include a dependency on an infrastructure instance which is a deployment of the technology provider usage. Two separate deployments, to two separate nodes, but because they are both of the same infrastructure software, from the same build architecture, they will both be shown under the "Test" and "Development" tables in core_app_def. The only way we have found to avoid this is to create separate build architectures for each deployment role, as that leads to distinct, environment specific, Technology_Provider_Usage instances - but it's a lot of duplicated work to create.
Would a copy of the model help?
Kevin
Thanks for taking the time for a detailed reply, especially so late at night!
What I have found is that if I have a single deployment technical architecture, used in two application deployments one for dev and one for test, when viewing the core_app_def report all infrastructure instances are shown in both dev and test sections of the table.
Take the DB for example: both dev and test deployments will include a dependency on an infrastructure instance which is a deployment of the technology provider usage. Two separate deployments, to two separate nodes, but because they are both of the same infrastructure software, from the same build architecture, they will both be shown under the "Test" and "Development" tables in core_app_def. The only way we have found to avoid this is to create separate build architectures for each deployment role, as that leads to distinct, environment specific, Technology_Provider_Usage instances - but it's a lot of duplicated work to create.
Would a copy of the model help?
Kevin
-
Kevin Campbell
- Posts: 40
- Joined: 13 Sep 2010, 20:26
A follow on post just to let you know that the process you described is how we have approached modeling our "as is" - but somewhat meet in the middle. Because it's easy to create technology nodes based on data we already have the first thing we did was to import them, and their associated o/s instances. This makes it a bit easier as we work our way down the model to, as you say, virtually deploy the technology usages to each node.
My application software instances are instances of the technology product build as technology provider, typically deployed to the node that hosts the application server. Each infrastructure software instance deploys the actual technology provider itself (Weblogic app server, SQL Server etc) and is also a deployment of the appropriate Technology Provider Usage from the product build.
To restate from my earlier note: the problem comes when nodeA and nodeB are each instances of the same Technology Provider Usage - but each is associated with a different Application Deployment, each playing a different role. In the core_app_def report the two environments (roles) are shown under physical technology platforms and nodeA and nodeB both appear in each environment. In reality nodeA should only appear under Development and nodeB should only appear under Test, because that's the roles of the application deployments that are dependant upon them.
Kevin
My application software instances are instances of the technology product build as technology provider, typically deployed to the node that hosts the application server. Each infrastructure software instance deploys the actual technology provider itself (Weblogic app server, SQL Server etc) and is also a deployment of the appropriate Technology Provider Usage from the product build.
To restate from my earlier note: the problem comes when nodeA and nodeB are each instances of the same Technology Provider Usage - but each is associated with a different Application Deployment, each playing a different role. In the core_app_def report the two environments (roles) are shown under physical technology platforms and nodeA and nodeB both appear in each environment. In reality nodeA should only appear under Development and nodeB should only appear under Test, because that's the roles of the application deployments that are dependant upon them.
Kevin
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Kevin,
Apologies for taking so long to get back to you.
Thanks for the clarification. I'll take a look at this scenario in detail and get back to you.
Jonathan
Apologies for taking so long to get back to you.
Thanks for the clarification. I'll take a look at this scenario in detail and get back to you.
Jonathan
Essential Project Team
