A piece of code in a dev environment is in a nascent state ; it needs a production environment to generate the cashflow for the company. This is the time when architecting deployments becomes a crucial task .
1. Never underestimate the importance of a staging environment . Dev-UAT resemble each other closely ,
and Staging - Production environments should resemble even closer. Every deployment model, script, scalability, failover, high availability solution that needs to be there in production, needs first to be there for testing and optimization in the staging server . Once it stabilizes , it can be safely deployed to production.
2. Anwers to the following questions should be clear to you because these answers will determine how your deployment diagram will look like.
What are my hardware / software limitations
How critical is the system
How many physical servers/boxes do I have
Minimum two if you want failover
Do I have virtualization technology?
What does my software license limit me to ?
Is it a per cpu license, per virtual machine license or per server license.
How scalable should my system be ?
If it supports x systems now, in y year/s might it require to support z more?
How robust is my system
If some day the Transaction per second tripled, can it still work smoothly?
How will my system have a clean high availability / failover startegy
Without losing or duplicating data if one server goes down.
What existing systems will yours need to interact/integrate with?
How do you intend to monitor the system once it has been deployed?
How secure does the system need to be
Identify the distribution architecture
Will your application have two tiers, three tiers, or more?
Here is a stepwise guide to build a small deployment diagram of an integration system.
1. Identify the scope and make separate models:
Are you planning to deploy a version of a single application or scale it out to the deployment of the system within your organization .
2.Identify the nodes and their connections
Think about separate modules of your application and which servers they will be deployed in .
Eg . Make a digram of all the different kind of servers your system might need :Web Servers, Application Servers, Database Servers, JMS Server, Mail Server etc. You may represent them as boxes. In this step you need to make platform decisions such as the hardware and operating systems to be deployed, including how the various nodes will be connected
Add to the diagram which module will be hosted in which environment .
Connect these with the kind of interaction these modules will have ( eg messages, ack, RMI) .
Distribute software to nodes.
What you have here is the basic deployment diagram .
In my next post I will discuss further how to factor in different considerations like sizing, resource optimization , redundancy etc into the basic diagram so that you can reach the next level , ie, getting your deployment architecture ready for the enterprise level.
Jason Amenda - I agree with #1 strongly - "Never underestimate the importance of a staging environment . Dev-UAT resemble each other closely ,
ReplyDeleteand Staging - Production environments should resemble even closer. Every deployment model, script, scalability, failover, high availability solution that needs to be there in production, needs first to be there for testing and optimization in the staging server . Once it stabilizes , it can be safely deployed to production.
I see this too often being on the infrastructure side of things where the test environment is "good enough for test" when it should be an exact match to production, or atleast 99.9% there. I also see changes to hardware configurations being made between test and prod, which have caused major headaches. For example, I have seen a test environment running on 32 bit and then production was loaded on 64 bit, a big no no!
I also have to comment on the importance of virtualization. If it is acceptable to run your project in a virtual environment, do it! There are so many tools built into VM environments that developers can use to there advantage. One to note is Snapshot Manager from VMWare. Allows for a snapshot to be taken of the current state of the machine so that you can revert to this point at any time in the future. Works great for those OOOPS moments! There are also some HA (High Availability) features built into virtual environments to maximize your uptime during a disaster or outage (VMotion is the VMWare product that helps with HA). VMotion will also assist in system performance but migrating virtual machines to different physical hosts based on the resource load on the physical hosts and the needs of the virtual machines. This will help to ensure that applications have the resources they need when they need them.
Great blog Rupa! Look forward to learning more from you!
-Jason
Jason's reply on Buzz was very informative , reposted it on the blog....
ReplyDelete