Cloud computing discovers best practices to integrate new services and extend business functions

The author will detail how to apply the cloud adoption pattern, each of which outlines its specific characteristics, to support the business and technical requirements of the Enterprise's cloud implementation. These examples show how cloud solution vendors build private and public clouds, hosting client applications all in a cloud environment (for example, IBM® cloud services offerings), or partially hosted in the cloud, partially hosted locally.

Patterns include best practices and expertise that are repeatedly extracted from customers and partner activities for complex tasks. Patterns can help users define good solutions in a clear format, deal with recurring problems, and apply that pattern to specific use cases, regardless of the technology (including software, middleware, or programming language).

As more and more solutions are deployed into the cloud, as cloud computing becomes an emerging area of development, many new products and new technologies are available to cloud users, and understanding cloud patterns, especially patterns, and coordinating the best suited enterprise scenarios, motivations, and mitigation patterns can help you build a good cloud application.

For example, if the solution requires integration with IT components residing in an internal cloud environment or other cloud environments, the complete solution, where all IT resources reside in the cloud, may not be the best solution. Integration with certain requirements matching topologies and schemas helps architects narrow the scope of solution elements to support functional and non-functional requirements.

Patterns can also help users identify the impact of choosing a pattern on another pattern, which helps the architect highlight the diversity of choices to the enterprise.

The purpose of this article is to help cloud architects choose a suitable cloud adoption model that can help extend business functionality and integrate new services from existing local systems and cloud vendors. The focus of this article is on integration, use patterns to support cloud service models in an abstract form (infrastructure i.e. services [IaaS], platform as services [PaaS], software as services [SaaS], and business processes as services) and cloud types (public, private, mixed, and community) To classify cloud solution products. These abstract forms will help you to follow your own business model, the required cloud maturity levels Select the appropriate adoption models and technologies (e.g. software, platforms, and tools), and their primary goal is to provide you with the first critical step towards a practical and holistic approach to the implementation or scaling of the cloud.

In the following section, we review the key cloud adoption patterns and describe their attributes, characteristics, topologies, motivations, and other decision factors; we have provided some examples of user scenarios and case studies to help provide relevant backgrounds.

Meet Cloud adoption Patterns

In general, the cloud pattern can be grouped into 4 categories, based on the shared features of the application, data, and infrastructure:

applications are hosted on the local Cloud (private cloud), and data and infrastructure cannot be shared. Applications are hosted on a public cloud, and data and infrastructure can be shared. Applications combine private and public clouds (mixed clouds), and data and infrastructure can be selectively shared. Community Cloud, designed for specific community functions, allows community users to collaborate with each other.

These cloud patterns are related to the cloud service model but are different from the cloud service model. The Cloud service model (for this article) can also be divided into 4 groups:

The

infrastructure, the service platform, the service software, the service business process, is the server to support different types of services

The adoption pattern described here is based on the first set of features and includes all cloud service models. The cloud uses patterns to call it:

Primary Mixed Cloud (PHC) Extended hybrid Cloud (EHC) Full Cloud (FC) Extended full Cloud (EFC)

The following subsections outline the properties, characteristics, and topology of each pattern. The subsections will also provide you with the motivation to use them, the pros and cons of choosing a pattern, and the impact of adopting a specific pattern.

Main mixed Cloud (PHC)

The primary mixed cloud model is a way to extend a local or managed deployment to a cloud environment. Processing instances are deployed or pre-configured according to requirements and are not usually integrated into the runtime service feed.

This mode has a one-way scheme to deliver service delivery, relying on only one running resource at a time. Data center features provide such services as data services, business support services (for billing, customer management, and so on), operational support services (e.g., service automation, metering, and so on), support services, monitoring services, security services, and network services.

Characteristics

This pattern allows for limited integration with local components, and is loosely coupled between components and non-bidirectional synchronization. This pattern is not integrated with other cloud solutions.

Topological structure

Conceptually, the main blending modes can be represented by diagrams:

Figure 1. Main mixed Multi-image flutter structure

The integration between the local component on the left and the cloud residing on the right is limited. Logically looks like Figure 2:

Figure 2. Main mixed cloud logical structure

Motivation

Motivational reasons for adopting the model include:

You need to use additional functionality to handle situations where the local system does not meet and does not restrict the operation of local system input. You need to process some raw data beforehand, but you do not need to store the raw data locally; You need to use some software components that you can't run locally you don't have a ready-made skill set to build your environment or run your local software. Your time-to-market is too short, and only cloud vendors can meet their business needs, and internal technology cannot meet those needs. You think you might need a mixed cloud of expansion, but you're not ready yet.

Key User Scenarios

Enterprises that use the primary blending mode typically have the following business requirements:

you want to run another batch process, but there are currently no processing windows on your local system. You have a large data project that collects data from the Internet, but you want to do data mining on your local system's input (for example, Business Intelligence [BI] reports). You want to host a content management system in the cloud that contains a subset of the local content management system. You want to test a new application running on the operating system that can run in the cloud but not run locally. You want to share local data with external users by replicating. You want to provide services other than core services, such as data analysis, that are based on the local system, but are not required for the core business. You want to use outsourced e-business capabilities to provide SaaS providers, such as payment services or billing services.

Determinants

The factors that determine whether you are using this pattern are:

wants to limit the commitment to a full cloud deployment. Risk isolation: For example, a batch process may fail, but it has no serious impact on the common environment, and risk isolation reduces the impact on your core business and does not require much internal device support. Investment minimization: You want to get a quick initial cloud experience before publishing a full cloud. Flexibility: This model enables you to extend your existing business with minimal commitment. Minimize integration and process dependencies. You do not need to partition your data. No real-time transactions are required.

Influence

If you take this primary cloud model, the key implications to consider include:

Need to maintain a cloud support structure and a local system support structure that may include redundancy or conflict. If your cloud environment requires local monitoring, you may need to provide your own monitoring, which can be very performance-less. The work you need to do is to limit integration from the local system to the main mixed cloud services. Work with cloud vendors to build governance models (e.g., change control, QoS) and standards. Contract management, terms and conditions need to be established. Cloud solution security may be different from a local solution. Existing operational support capabilities can be extended to cloud solutions and may require review and improvement of the current support architecture. Establish metrics to validate and audit services provided by cloud vendors. User education and training may be required to include extended functionality. Need for application migration and batch management support. A disaster recovery plan is needed to include the cloud extension. The ability to receive real-time integration and primary mixed cloud services may be limited.