Category: General
Posted by: bagheljas
Disaster Recovery Solutions design is driven by the following recovery objectives:
  • Recovery Point Objective: Worse case data loss is acceptable for applications for a disaster event.
  • Recovery Performance Objective: Application need to perform at the same level as primary site or we can limit user access or ok to have degraded performance for applications if disaster happens.
  • Recovery Functionality Objective: Functionality of applications needed at same level as primary site or can they operate with limited functionality.
  • Recovery Location Objective: Location characteristics such as power grid, distance relative to primary sites and corporate offices
  • Recovery Time Objective: Worse case of Time to recover for applications for a disaster event
  • Recovery Redundancy Objective: Defines the redundancy objective for the Disaster Recovery Site such as same as Primary Site or certain layer as production and while others have no redundancy

We often find that these objectives together help us define DR tiers such as Platinum, Gold, Silver and Bronze to fit into a budget to delivery DR capability for an enterprise.
Category: General
Posted by: bagheljas
  • App to App dependency (Internal and External) needs protocol transformation for cloud deployment
  • COTS products current license is not supported for cloud deployment
  • Gaps in Application grouping and Sequencing also known as Wave Plan and Detailed Migration Plan for each wave
  • IP based configurations that sometime even hard coded in the application code
  • Application platform components clustering protocol not supported in the cloud
  • App to Infrastructure dependency needs architecture transformation for cloud deployment
  • Application platform components and underlying middleware & operating systems has direct binding with the server hardware platform
  • Application system architecture needs to be revised for matching the current performance baseline
  • User functionality and experience impacts by network latency sometime needs to be addressed by re-design of the application architecture
  • Transformation of proprietary implementation of Load Balancers and Security Controls in WAF, Firewall, IPS/IDS etc.
  • Transformation of services/systems deployment life cycle management tools and processes such as monitoring, backup and recovery, automation (config, build, patch and deploy), ITIL etc.
Category: General
Posted by: bagheljas
The Data Center Migration Timeline is directly influenced by the following factors:
  • Transformation Objectives and In-flight Enterprise Initiatives
  • Business, Technology and Applications Constraints driven move groups and available maintenance windows
  • Miscellaneous vendors SLAs and time needed for the procurement, build and validation phases
  • Organization’s maturity - availability of infrastructure (Network, Compute and Storage), applications and business data related to source environment
  • Stake holders’ resource plan and skills & maturity level
  • Swing infrastructure (Network, Compute and Storage) availability and migration tools capabilities
  • Security and Compliance Needs
  • Migration Methods Needed and Utilized:
    • Physical Moves (Lift-n-Shift)
    • Logical Moves (Server Image and Data over Wire)
    • Green Field (Build and Deploy)
  • Environment Nature and Size:
    • Number of Physical Devices
    • Number of Operating System Instances
    • Number of Applications & Types
    • Total Storage
    • Number of Databases and Total Size
    • Number of File Shares and Total Size
    • Number of Network Zones and VLANs
    • Number of Firewalls and Load Balancers Rules
    • Number of Components between End User(s) and Server(s)
    • Number of Data Centers and WAN Sites
    • Number of Environments in SDLC
    • SDLC Types & Timelines
Category: General
Posted by: bagheljas
The Application-2-Infrastructure Mapping for an application is the information about the network, compute and storage used for the application system deployment. Application-2-Infrastructure Mapping is mission critical for system deployment life cycle. In most organizations, the Application-2-Infrastructure information is not easily available and often it is tribal knowledge. There are tools in the market claims to auto-discover and create the mapping for you. The reality is that there is no tool in the market that can auto-discover and create Application-2-Infrastructure Mapping for an enterprise applications portfolio. The first iteration of creating Application-2-Infrastructure Mapping is manual in nature. The Mapping tools such as BMC ADDM and HP ADDM will auto-discover the infrastructure elements also known as application elements but application owner needs to define the mapping rules. The tools have a library of these rules for some of the popular applications technology stack that doesn't cover 100% of an enterprise application portfolio. The standard library often misses covering the custom implementations for a popular applications technology stack.

Sample Schema Elements for Application-2-Infrastructure Mapping:
  • application Name
  • application Description
  • application environment/landscape(s)
  • application serviceUrl(s)
  • serviceUrls DNS / GTM / GSLB / L7LB Configuration
  • application VIPs / LTM / LSLB / L4LB Configuration
  • application Network Information
    • Internet / WAN
    • Zones / vLANs / ServerGroups
    • networkfirewallRules
  • misc access and security controls
  • web server(s)
  • application server(s)
  • database server(s)
  • misc servers such as batch, messaging queue etc
  • data replication methods and tools
  • server(s) storage LUNs mappings
  • server(s) NAS mappings
  • server(s) technology stack
  • server(s) Operating System Processes
  • application dependencies - common/core services
  • application dependencies - enterprise applications services
  • application dependencies - external applications services
Category: General
Posted by: bagheljas
Estimating Efforts for Applications Infrastructure Migration is an art and science. There is no simple answer and can't be estimated by just looking at the technologies involved. Technology is one of the important domain but not everything to create estimates for timelines and resources required to complete such a task. The domains that has direct and indirect relationship for estimating efforts for Applications Infrastructure Migration are given below:
  • ITO Service Model
  • Applications Meta Data
  • Transformation Complexity
  • Organization
    • IT Maturity Level
    • System Deployment Life Cycle
    • Structure
    • Culture
    • Miscellaneous Constraints
Category: General
Posted by: bagheljas
BigData Hadoop Implementation Maturity Model
Category: General
Posted by: bagheljas
Application Deployment Maturity Model
Category: General
Posted by: bagheljas
Solution Lifecycle
Category: General
Posted by: bagheljas
Any Disaster Recovery (DR) solutions can be mapped into one of the following deployment models:

  • Fault Tolerant: No impacts to the services to users in the event of disaster scenario and users consumes services actively from multiple data centers all the time. This model is also known as multi site active-active deployment.

  • Auto Failover:In the event of disaster scenario users are routed to the disaster recovery site. This model is also known as multi site active-hot-standby deployment.

  • Coordinated Fail-over: Someone needs to call out that it is a disaster event and services platform administrators’ runs configurations updates to make services available at the disaster recovery site and then update configurations to route the users at the disaster recovery site. This model is also known as multi site active-passive deployment.

  • Backup & Build: You will stand up services platform systems from backup and build at the disaster recovery site. You will run minimum verification to ensure that services for users are restored as expected and then manually route the users at the disaster recovery site. This model is also known as multi site active-cold deployment.

The diagram suggests the factors that needs to evaluated to select a DR deployment model for an application platform. In an enterprise, you will find multiple DR deployment models to meet needs of the entire applications portfolio economically.
DR Deployment Model Selection Factors
Category: General
Posted by: bagheljas
Application Availability Uptime SLAs Deployment Models
<% %Y ()%>