As the CSO and CIO you may be wondering why I created a diagnostic test which deals with understanding the most important for your website. The original purpose of the diagnostic to see the application and how the application is ported successfully to Cloud service providers. Determine the diagnostic and IaaS Cloud products (storage components, network components, and machine virtualization) that required for an application. It addresses platform components (server / operating system and web server) in the PaaS layer. Finally, focusing on SaaS software applications.
Once, this analysis is done accurately, all the corporate top 10 applications that are mapped to a public cloud / private. Simple port (different versions of virtualization software or a newer release an operating system) can occur as long as they do not affect the software running in a layer of SaaS. A matrix can be made for all ten applications and it is possible to integrate more than one application on different parts of the infrastructure products. So what should be tested to ensure success?
I argued in a previous article that the disaster recovery test is the most important and difficult for service providers who can demonstrate to potential clients Cloud. Therefore, testing of disaster recovery plan is a very high priority. In addition, it only happens that the information collected for disaster recovery is a superset of the information necessary to port your application to a major web service providers Cloud. Depth analysis of each application showing service providers how to port and test it in the Cloud. This is a test basis in the configuration of application services provider Cloud (what is needed for all ten applications) as well as additional functions necessary for a successful disaster recovery of the same application.
More importantly, a diagnostic aid in determining what functions are needed for input into the SLA (Service Level Agreement) between a company and service providers Cloud. Accurate creation of the SLA is the ultimate goal of the analysis. How does one gain confidence that the SLA covers all different types of failures by the service provider? What should be analyzed first? Performance metrics are required for each application supported. Here are some other questions that need to be answered to determine correctly display the performance metrics. Again this is a representative list, it is not necessarily complete.
Lastly, information boxes, lines of each application, should be incorporated into the SLA. With the SLA, each application must have the functionality requirements, performance metrics and financial penalties for various types of errors downtime. Note the service provider is not required to deploy an architecture that is identical to the product and the same software release as an architectural model and the client. Service providers must meet the functionality and the same response time. Areas of risk architecture should also be noted in the SLA. For example, database products in the PaaS layer may be only one vendor. Weaknesses in the vendor database that was released by the software may have an impact on all applications that use a given database, the systemic risk. It should be noted and taken into account the cost of downtime. The cost of brand damage (if the application has a secret data) and potential lawsuits should also be included in the SLA for each application.
In summary, the diagnostic can be used to critically analyze the company's web-based application for consideration of placing the company in its application by Cloud providers. Providers do not need to use the same architecture or product but must meet the SLA for each application. In addition to a few diagnostic questions in part the performance data required for web applications that should be collected so that the SLA will be complete.
No comments:
Post a Comment