1 Introduction

Sustainability computing and cloud computing are models that enable users to access configurable resources, such as networks, servers, storage spaces, and web-based applications according to their needs and the SLAs they have with their service providers. Process resources can be provided by minimal management effort or minimal interaction with service providers. Virtualization is a valuable technology in cloud computing. It maximizes processing power through virtualization. Cloud computing services include the following three types: cloud platform as a service, cloud infrastructure as a service, and cloud software as a service [1, 2]. Cost-saving, scalability, easy management, etc., are among the main advantages of cloud computing, which enable service providers and different companies to use this model [3,4,5].

A cloud infrastructure provider offers their users virtual machines (VMs) as service resources. The management of resources for cloud infrastructure providers is crucial. A resource management process involves resource allocation, requirement mapping, trading, estimation, and modeling. It is crucial that a cloud provider implements an efficient allocation technique that reflects the market conditions. This is the process through which a client determines how much they paid for the service received, and the provider determines how much they received for the service delivered. This is a fundamental issue in resource allocation. Cloud-marketplace is an online storefront that operates by the provider of cloud service. Cloud-marketplace enables the providers to supply their products as well as enables the clients to raise their requirements. Among the advantages of the cloud, the marketplace is controlling and simplifying the buy and sell processes for both parties; besides, the exchange in the market can help the price control and prevents the market to become a monopoly [6,7,8]. AWS Marketplace, Oracle Marketplace, Marketplace Azure Windows Microsoft, and Salesforce AppExchange are examples of cloud-marketing [9,10,11]. In finding out the price at which a resource will initially enter the market, there is an important issue and challenge involved. Initial pricing is a part of determining the price at which a resource will initially enter the market. Initial pricing can be significantly affected by the choice of pricing method and model, for example, if the auction method is used, the initial price would be equal to the final bid price of the last auction [8, 12,13,14]. Studying the initial prices of cloud resources or services is the purpose of this paper. In addition to creating the initial pricing, we have focused on the overall pricing. Along with the fixed prices, the market conditions should also be considered when creating an initial price for a service. Therefore, to create the initial pricing, along with the parameters and factors that lead to the creation of fixed costs, the variables and parameters that lead to the creation of variable costs should also be determined. When determining the price, we will consider all parameters and factors. It is possible that an agreement will not be reached between the buyer and seller if the initial price and the negotiated price are significantly different. A closer distance between the initial and negotiated prices reduces productivity and, therefore, the starting point of the initial price and the negotiated price should not be too far or too close. Thus, determining an initial price that is appropriate for the market will result in higher convergence rates and eventually more productivity. Furthermore, pricing has a direct impact on the profit of the traders, so the better the pricing, the greater the profit both parties realize. This study aims to develop an initial price based on different factors and conditions, which will result in a suitable agreement that will benefit both parties. The following are the objectives of the research [15]:

  • Obtaining the effective factors in determining the initial pricing of the VM type and checking the response time.

  • Finding the weight and the impact of each effective factor in the initial pricing of the VM type.

  • Combining the extracted factors properly and investigating the SL.

A novel dynamic initial pricing method has been presented in this study to set up a service-level agreement based on qualitative and quantitative findings. Managing cloud services according to the market-oriented approach is one of the most common methods. We are trying to construct the VMs’ (VM (virtual machine): A virtual machine is an emulation or virtualization of a computer system. Virtual machines resemble physical computers in their architecture and provide the functionality of one. Specialized hardware or software may be used in their implementation SLA) initial price by considering market dynamics and regression. Statistical modeling, also known as regression analysis, is a method of estimating relationships between a dependent variable and independent variables in cloud computing, which we have used. A linear regression analysis is the most common form of regression analysis in this field, which identifies the line (or a complex combination of lines) that most closely fits the data according to a mathematical condition. Negotiations in the market are based on negotiation-based architecture, where multifactor architecture is used for the negotiations.

The research is notable for its contributions to:

  • Dynamic initial pricing of VMs as a means of setting SLAs in a competitive market.

  • Using a market-oriented approach to negotiating market deals.

  • Improved SLAs (SLAs (service-level agreements) are agreements between cloud service providers and their customers that ensure minimum levels of service are maintained) are indicated by categorizing VMs using regression and using regression to categorize VMs.

2 Definitions and research background

The aim of negotiation of a cloud SLA (service-level agreement) is a common decision-making process between the cloud service providers and cloud server clients to solve their conflicting goals. If the negotiation between the provider and clients is done manually, it can become a bottleneck [16,17,18,19]. In [4], this issue has been studied as, if the parameters, such as deadline and the initial offer value, have changed, what is the effect on the outcome of the negotiation. Figure 1 shows the life cycle of a service that generally has five phases.

Fig. 1
figure 1

The life cycle of a service

Full size image

In the service discovery phase, the user’s need is captured as an input for discovering the most appropriate service. In the SLA negotiation phase, both sides are negotiating the quality of service and an agreement achieves between them. In the monitoring phase, the negotiated service is continuously monitored and if necessary, the service scale increases.

Two different scenarios have been considered to show the results of the test. In the first scenario, a third party is responsible for providing the negotiating strategy for both sides, where its main target is maximizing the number of transactions and fairness of the result for both sides. In the second scenario, there is no third party, and both sides are willing their profit. After describing the test’s scenarios, some issues are addressed. First, the initial offer price and the performance of time-dependent techniques can affect social welfare and satisfaction. Second, the strategy provided for the negotiation can be effective in increasing the profit of the providers. The success or failure of the strategy is computed based on the number of allocated VMs [20]. The last issue, which is studied here, is determining how reactions to the different conditions of the market lead to an increase in the profit of the negotiation strategy. The negotiation strategy presented in this research has been tested with different load working, and the obtained results show that the time-dependent negotiation strategy can dynamically help providers increase their profits. In [9], the different pricing models have been investigated and compared.

Pay-as-you-go model pricing: This pricing model is one of the static pricing methods, and the price is determined by the provider and remains fixed. This method has some advantages, including that the customer is aware of the cost needed to pay, and the resources are reserved for the customer. However, one of the disadvantages of this method is that the service provider may allocate more resources for a customer to use. Moreover, the provider is not able to raise the price when demand increases, also the customers have to pay more in a case where the demand is low.

Subscription pricing model: This pricing model is another static pricing method wherein the price is defined based on the subscription period of the customer. In this method, sometimes the customer has to pay more than they must pay and vice versa. The advantage of this method is that the customer has to pay less for the resources if they use the resources widely, and the disadvantage of this model is that the customer has to pay more when the customer has less use of resources.

Pay-for-resources pricing model: This model is a static pricing model. In this method, productivity of resources is maximized. The difficulty of the implementation is the weakness of this model. In [21], it has been shown that if the provider uses fixed pricing, the welfare loses (Fig. 2).

Fig. 2
figure 2

The comparison of the seller profit in statistics and dynamic pricing

Full size image

When the demand is low, according to the fixed pricing method, the resource price will have a price more than the market price and cause the buyer to think of other options. Moreover, in a case where the demand is high, fixed pricing limits the welfare of the seller, because in such a case, the price of the resources can increase.

In [22], a negotiation-based resource allocation model has been presented and developed in the CloudSim environment. The proposed mechanism is used so that the buyer and seller are in direct contact. Supply and demand, in a normal market model, are shown in Fig. 2.

Figure 3 shows three different cases denoted by 1, 2, and 3. Case 1 is a scenario wherein the demand is over-provisioning. Case 2 demonstrates the balance of supply and demand, and case 3 is a scenario of under-provisioning of the demand. Among these three scenarios, cases 1 and 3 are inefficient, because the traders are not able to execute the sell and buy tasks well.

Fig. 3
figure 3

Supply and demand in the market

Full size image

Figure 4 shows the messaging process between the buyer and the seller. This means that at the time t = 0, an offer is sent to the buyer from the seller and usually the first message is called a template. Templates are the first offers that are sent, made by the seller, to establish a negotiation.

Fig. 4
figure 4

Messages exchanged between the seller and the buyer in the market and in the time range t = 0 to t = 2 to reach an agreement

Full size image

In [23], some software pricing factors have been introduced, including price formation, the structure of the flow assessment base, price discrimination, price bundling, and then the SBIFT (the SBIFT pricing model was introduced by Iveroth et al. as part of a comprehensive taxonomy of pricing models) model was investigated. SBIFT model is a category of different pricing methods based on the five dimensions that include scope, base, influence, formula, and temporal rights. The items of the SBIFT model and the software pricing parameters have a lot in common. According to this, by combining the items that exist in the SBIFT model and the software pricing parameters, a seven-dimension model can be obtained, and this new model can be used in the cloud concept.

In [24], a model has been presented for the providers of the cloud software service. By using the proposed model, the cloud service providers can use the resources they have access efficiently and maximize their profit. The system factors include the users, the SaaS providers, and the IaaS providers, who own the resources, supply the resources as VMs, and provide them to the SaaS providers, whereas SaaS usually rent the resources from them. In the proposed model, the system analyzes the requests sent from the users to the SaaS providers using two factors: admission control and scheduling, which decides whether their service requests are accepted or not. The admission control parameter performs the analysis and makes a decision using four strategies. These strategies use the related parameters for making a decision which include inPrij (the price of the input data), outPrij (the price of the output data), iniTijl (time taken for installing the VM machine of l-type by the j provider), subT (time requested by a user), B (the maximum price that a user pays to a SaaS provider), β (penalty rate), profijlnew (profit of a SaaS), costijlnew (the sum of the costs that a SaaS provider pays to complete the process of the user request on the VM machine of l type which receives from the j provider), Pcijl (process cost), DTCjl (data transfer cost), ICijl (initial price; the initial price of the VMi machine depends on the type of the machine which creates in a data center of an IaaS provider), PDCijl (delay penalty), DTTijl (data transformation time), Tijl (new request-response time), and retijl (return of capital).

In [12], the auction pricing method is investigated. Each auction is done in a period, i.e., the time from 0 to T. Determining the initial price is one of the main parts of every pricing method. In the auction, the initial price of the services is determined in the following method: If, in the previous round, the average price of the auction proposed for the k3 machine is P, then the base price at the start of the next auction round for the k3 machine is considered P.

In [25], the BSM model was studied, which is a pricing model that was introduced by three economists. In this study, the cloud parameters were mapped into BSM to enable cloud pricing. The aim of [26] was to help customers select an appropriate pricing method. This research also investigated the factors that had positive and negative effects on the customer’s profit. To determine the price of a service or a product, some factors, such as production and maintenance costs, competition in the market, and the recommendations of the customers, should be taken into account [27]. In [28], the tendency to use cloud process technology in companies and organizations was addressed. DOI theory is a fundamental theory and method to understand how new technology is broadcasted. Researchers obtained other factors that affect the broadcasting of a new technology, combined them with the DOI theory, and achieved the technology-organization-environment (TOE) framework. TOE is a framework for spreading innovation; this research determines how each factor in the TOE framework is effective in selecting a pricing method by the cloud providers. Moreover, this research explains that the pay-as-you-go pricing method in cloud technology is a distinction of this technology compared to other technologies. In [5], the basic question of whether to pursue cloud processing or not is addressed by providing different scenarios and available computer resources, such as the number of processors, memory, storage volume, and bandwidth, which helps the user to decide whether to buy or rent resources. The costs of the server, network, middleware licenses, physical space requirements, costs, and expenses other than electricity costs are among the fixed costs for cloud implementation and the overhead cost of using electricity (such as cooling, idle time, the use of electronic means), internet costs, maintenance costs, hardware, data connectivity, and the cost of using servers, are the variable costs. In our research, these variable costs can be used as effective factors and parameters in the fixed part of the initial cost.

3 The proposed method

In this section, the effective parameters of the initial price are investigated and extracted [5]. The extracted factors are effective, fixed, and dynamic factors in the initial price of the VMs. Then the dynamic initial pricing model of the VMs is provided in a competitive market along with the market entities and architectures. Deals in the recommended market are executed using the relaxation of negotiation criteria. Moreover, to make complicated decisions in such a trading market, the software factors are designed.

3.1 Effective factors of the initial dynamic price section

3.1.1 Penalty rate (PR)

In a case where the cloud service providers are not able to fulfill their SLA commitments, they should pay to the consumers based on the PR selected method. In [29, 30], three effective items are defined in computing PR:

  • Calculation method: There are three methods to calculate the penalty which are all based on the violation level (for example, unavailability or downtime). These three methods include (1) the ratio of the total charge which, based on the violation, a certain percentage of the amount paid by the customers will be returned; (2) fixed value, where a fixed amount will be returned to the customer; and (3) the ratio of downtime.

  • Penalty capacity: The maximum value that a provider returns to the customer as a penalty.

  • Payment method: Most of the providers do not pay credit or money directly to the customers as a penalty, but also the penalty will be paid from the total cost of the future purchases of the customers.

3.1.2 Market entities

In the following, the extracted entities from the market have been investigated and presented.

  • VM type characteristics: The providers of the VMs categorized their resources into different VM types to provide to the demanders. Each type of VM has predefined characteristics <Core, Ram, Disk Space>.

  • Market: The market entity helps the customers and providers interact with each other by creating a framework to allocate resources based on the negotiation.

  • The reservoir of a record of the previous trading markets for buying the VM type (C_BehaviorDB): This includes a local database in which the transaction ID, the applicant ID of the virtual machine, the provider ID, and the result are determined.

  • Resource demand file (VMDemand_File): This file includes the specifications of the VM type requested based on <Core, Ram, Disk Space>, reservation price, and the initial price, rent time of the VM, and deadline.

  • Resource supply file (VMSupply_File): This file includes the characteristics of the resources supplied by the resource provider (Supply_VMType Characteristics), minimum offer price, maximum offer price, and the number of disposable resources by the provider, the quality level, and the deadline. Some of this information is confidential and some of it is not.

  • BillboardSubMarControlAi: This includes the number of resource providers in the trading market, the number of applicants in the market, and the current round of the trading market.

  • BillboardPrivateProj: This is used to share price information for the balancing protocol and only the children (to participate in the submarket to deliver their specific product, each of the PDA and CBA factors produce a child (sample) that can be represented in the submarket) of factors have access to its content. The recommended billboard is composed of the following:

  • The maximum price that has been received from the customers for the VM with the quality X.

  • The maximum price comparison between the final result and the potential for the type of virtual machine with quality X.

3.1.3 Trading scenario

The trading scenario in the recommended market includes five steps:

  1. 1.

    Demand submission: When an applicant requests to use the computational cloud VMs, the applicant submits the specifications of the requested VM along with the request conditions and the functions they want to use during the trading as a source demand file format (VMDemand_File), using a user interface. By submitting the request, the market coordinator (MarCoordinator) orders the creation of a corresponding CA for the resource applicant to the entities’ construction factors (TradingCA). The CA factor separates the Demand_VMTypeCharateristics from the VMDemand_File, delivers it to the market control factor, and the demand submit process ends.

  2. 2.

    Supply submission: When the resource provider wants to supply its resources in the computational cloud, the provider submits the characteristics of the supplied VM machine type (Supply_VMType Characteristics) along with the supply conditions and the functions they want to use during the deal as a resource supply file format (VMSupply_File) via the user interface in the cloud trading market environment. Once the resource supply file is submitted by the provider, the market coordinator (MarCoordinator) orders the entities’ construction factor (TradingCA) to create a PA factor corresponding to the resource provider. Then, the PA factor submits the Supply_VMType Characteristics section of the reservoir related to maintaining the characteristics of the supplied resources by the resource provider (P_VMCHarDirectory) and the submission process of the supplied resource finishes.

  3. 3.

    Preparing the trading platform: By submitting supply and demand in the trading market and after creating the PA and CA factors, the market coordinator factor receives the Demand_VMTypeCharacteristics/VMSupply_file from every CA customer/PA provider factor. If the provider submits the supply file and it is not founded in the appropriate market, its characteristics are registered in the reservoir and wait until the creation of the submarket in accordance with the characteristics of the offered service. On the resource applicant side, in the case of a lack of finding a submarket in which the service, in accordance with the features of CA, provides the requested resources, the MarCoordinator factor searches for a market on the general blackboard wherein the requested resource is provided, regardless of quality level of the service. In the case of finding an appropriate market to create a submarket, the P_VMCHarDirectory reservoir should be searched first to find a resource provider(s) that is capable of servicing the request of the resource applicant (with the desired quality level).

  4. 4.

    Trading: Trade is done in discrete time. In the odd periods, the applicants of the VMs are allowed to send their recommendations, and the providers are not allowed to do anything, and in the even period, the providers of the VMs are allowed to send their recommendations, and the applicants are not allowed to do anything. In the first round of creating the market, all CBA factors announce their proposed prices (PConRoundT) for the VM providers in the submarkets in the Initial_Negotiation message format. In this round, the providers are not allowed to do anything.

Providing the transactions, a platform for the proposed algorithm and investigation of SLA in Algorithm 1 and its details are shown in Fig. 5.

Fig. 5
figure 5

Providing a trading platform for the consumer algorithm and SLA review

Full size image

3.1.4 Market factors

The factors involved in the market have been listed in Table 1 with their tasks. It consists of consumer agents, consumer broker agents, provider agents, etc. It also includes information on how resource demanders submit their conditions.

Table 1 Factors that work for the resource demanders [5]
Full size table

3.1.5 Trading transactions in the proposed market

The transaction in the proposed market has five stages that include (1) demand submission, (2) supply submission, (3) preparing the transaction platform, (4) performing the transaction, and (5) finalizing the results obtained from the transaction.

Demand submission

When a resource applicant requests to use the computational cloud VMs, the requested VMs’ characteristics, along with the demand conditions and functions that are willing to be used, are submitted during the transaction as a resource demand file format (VMDemand_File) via the user interface. By submitting the market demand coordinator (MarCoordinator), the command is issued to create the CA factor corresponding to the resource applicant for the entities’ construction factor (TradingCA). The CA factor separates the Demand_VMTypeCharateristics from the VMDemand_File and delivers it to the market control factor and the demand submission process ends.

Supply submission

When the resource provider wants to supply its resources in the computational cloud, submits the characteristics of the supplied VM machine type (Supply_VMType Characteristics), along with the supply conditions and the functions they want to use during the trade as a resource supply file format (VMSupply_File) via the user interface in the cloud trading market environment. Once the resource supply file has been submitted by the provider, the market coordinator (MarCoordinator) orders the entities’ construction factor (TradingCA) to create a PA factor corresponding to the resource provider. Then the PA factor submits the Supply_VMType Characteristics section of the reservoir related to maintaining the characteristics of the supplied resources by the resource provider (P_VMCHarDirectory) and the submission process of the supplied resource finishes.

Preparing the trading platform

By submitting the supply and demand in the trading market, and after creating the PA and CA factors, the market coordinator factor receives the Demand_VMTypeCharacteristics/VMSupply_File from every CA customer/PA provider factor and searches a submarket in the general blackboard, wherein a service matching the requested features of the CA factor and/or matching with the provided service by the PA factor is sold/supplied. If the provider submits the supply file and it is not founded in the appropriate market, its characteristics are registered in the reservoir and wait until the creation of the submarket in accordance with the characteristics of the offered service. On the resource applicant side, in the case of a lack of finding a submarket in which the service, in accordance with the features of CA, provides the requested resources, the MarCoordinator factor searches for a market on the general blackboard wherein the requested resource is provided, regardless of the quality level of the service. In a case of finding the appropriate market to create a submarket, the P_VMCHarDirectory reservoir should be searched first to find a resource provider(s) that is capable of servicing the request of the resource applicant (with the desired quality level). Finding an appropriate submarket means the existence of the market and the appropriate MarControlAi factor; therefore, the MarCoordinator does nothing to set up a similar market and puts the CA/PA factor into the available market, and the MarControlAi factor sends the establishing message of a negotiator PDA/CBA to the corresponding PA/CA. The PDA/CBA factor locates in the market and creates a child, then locates in the submarket. MarControlAi sends the updating command to update the information contained in the blackboard to the MarBillboardA factor.

If the provider submits the supply file and the submarket is not found, its characteristics are submitted in the reservoir and wait until the creation of a submarket matching the features of the provided service. On the source applicant side, in the case of lack of finding a submarket wherein a service matches with the features of the requested resource of the CA factor, the MarCoordinator factor in the general blackboard searches a market wherein the demanded resource is provided, regardless of the quality level of the service. In the case of finding the appropriate market to create a submarket, the P_VMCHarDirectory reservoir should be searched first to find a resource provider(s) that is capable of servicing the request of the resource applicant (with the desired quality level). In the case of a lack of finding a list of resource providers, no actions are not taken for the transaction (existence of at least one provider to start the transaction is necessary).

Finding an appropriate submarket means the existence of the market and the appropriate MarControlAi factor; therefore, the MarCoordinator does nothing to set up a similar market and puts the CA/PA factor into the available market, and the MarControlAi factor sends the establishing message of a negotiator PDA/CBA to the corresponding PA/CA. The PDA/CBA factor locates in the market and creates a child, then locates in the submarket. MarControlAi sent the updating command to update the information contained in the blackboard to the MarBillboardA factor. In the case of lack of finding an appropriate market, if the provider submits the supply file, its characteristics are recorded in the reservoir, and it should wait until the creation of a market that matches the features of the provided service. For the resource applicant, in the case of lack of finding a market, it first searches for a P_VMCHarDirectory reservoir to find a resource provider(s) which is (are) able to service the resource applicant’s demand (with the desired quality level). In a case of finding resource provider(s), it creates a market and submarket and issues a command for the market construction factor (MarplaceAC) to create them. Moreover, it sends the message to the entity construction factor (TradingAC) for creating the market control factor (MarControlAi), and the applicant/provider of VMs puts the PVs in the new markets. After locating the MarControlAi, PA, and CA in the market, the MarControlAi factor sends a message for creating the CBA and PDA trader factors to the entity construction factor (TradingAC). The PDA/CBA factor creates a child and then puts it in the submarket. MarCoordinator and MarControlA send the command to the MarBillboardA factor for updating the billboard to update the information contained in the general blackboard and market. By constructing the trader factors, these factors receive the negotiation protocol from (MarControlAi). The negotiation clue between the traders is created by the (MarControlAi) factor. Finally, the billboard updating command sends the MarBillboardA factor to update the information contained in the submarket billboard.

It should be noted that if CBA/PDA corresponding to the applicant/provider of VM type exists in the market and the applicant/provider again enters the same market to buy/supply the VM type, its corresponding CBA/PDA will not be constructed, and CBA/PDA will construct a child as its representative and put it into an appropriate market.

Trading

The deal is done in discrete time. In the odd periods, the applicants of the VMs are allowed to send their recommendations, and the providers are not allowed to do anything, and in the even period, the providers of the VMs are allowed to send their recommendations, and the applicants are not allowed to do anything. In the first round of creating the market, all CBA factors announce their proposed prices (PConRoundT) for the VMs providers in the submarkets in the Initial_Negotiation message format. In this round, the providers are not allowed to do anything. In the second round, PDA factors act as follows [5]:

  • Create a price based on the selected strategy (PProCtr, Round T)

Comparing the results of the applicant’s offered price (PConRoundT-1) with the price obtained from the selected strategy (PProCtr, Round T), if the offered price by the applicant is more than the price obtained from the strategy, the offer of the VM applicant is submitted and enters the price coordination stage, 2-1. Otherwise, it enters the price virtualizing stage. If constructing a virtual price is not possible, the price obtained from the selected strategy (PProCtr, Round T) is submitted and enters the coordination stage. However, if constructing the virtual price is possible, it compares the virtual price and the price obtained from the selected strategy (PProCtr, Round T); if the virtual price is more, then it enters the coordination stage as the submitted price. Otherwise, the price obtained from the selected strategy enters the coordination stage.

Comparing the prices acquired in the coordination stage, and finally, the message for accepting the VM type, applicant price, and/or the new price will be announced by the New_Price message format.

The consumers receive the price from the VM type provider and compare the offered prices of the VM provider with the price obtained from the selected strategy. If the price offered by the VM provider is less than the price obtained from the selected strategy, the price will be accepted and will enter the finalizing step of the result obtained from the deal. Otherwise, the price obtained from the strategy will be announced to the VM providers as a new message format. The negotiations between the applicant and the provider of the VM type will continue in this way until the last round is reached, and in the case of failure to achieve an agreement in the negotiation, Resource_allocation_process_Termination messages must be sent to the CBA (PDA) and MarControlA.

Virtual price construction stage

By reaching half of the rounds in which a VM provider can stay in the market, and in case of the failure of an agreement, to improve the negotiation trend, the virtual price will be constructed. Before constructing a virtual price, it is necessary to check whether there is a possibility or not; therefore, (1) the number of allowed rounds to keep itself in the market will be checked and if it reaches half of the rounds that a VM provider needs to stay in the market, it enters the next stage. (2) When comparing the offered price by the VM type applicant with the maximum price offered by the customer for the machines with lower quality, if the applicant’s offer price is higher than or equal to the maximum offered price for the VM type with the lower quality, constructing the virtual price is possible; otherwise, given that the VM type provider is not allowed to sell the higher quality VM with the lower price with a lower price of lower quality VM, constructing the virtual price is not possible.

In the case of the possibility to construct the virtual price, PDA requested the following factors from the PDA, respectively [5, 31, 32] (Fig. 6):

  • MarBillboardA: the number of competitors and the number of applicants under the VM type (information on the private market blackboard)

  • Provider Dealer Agent: the number of successful instances of cooperation between the VM provider and buyer

  • Market Control Agent: the number of instances of cooperation of a VM applicant with other providers

  • Given that the calculated flexibility is a percentage value, the following method is used to convert it to a currency unit.

Fig. 6
figure 6

The number of competitors and the number of applicants under the VM type (information on the private market blackboard)

Full size image

Coordination stage

In the stage, it will be controlled that the VMs with any quality are not sold with a price lower than the maximum price of the VMs with the lower quality.

The input of this stage has the following three cases:

The offered price of the VM type applicant is higher than the price offered based on the selected strategy of the VM provider. In this case, a price that is entered to this stage to be checked will be the offered price by the VM applicant.

The offered price of the VM applicant is lower than the price offered based on the selected strategy of the VM provider, it is lower than the maximum price of the VMs with lower quality (MaxPvnwithSowerQ), and the construction is not possible. The price that is entered in the stage will be the price offered based on the selected strategy.

The offered price of the VM applicant is lower than the price offered based on the selected strategy of the VM provider; it is higher than the maximum price of the VMs with lower quality (MaxPvnwithSowerQ) and enters the virtual price construction stage. The output of the negotiation of the virtual price construction stage will enter the coordination stage.

In this stage, the price of every VM type compares with the maximum price of the VMs with lower quality, which is introduced as the submitted price. If the price of the VM type is higher than the maximum price of the VMs with lower quality, the price of the VM type (the VM type, applicant offered price, or price obtained from the strategy) is announced as the final price, and if the VM price is more than the maximum VM price with lower quality, the maximum VM price with lower quality is announced as the final price.

Finalizing the results obtained from the deal

Finalizing the results obtained from the deal will be done by receiving two messages: accept, reject, and/or Resource_allocation_process_Termination.

If the “accept” message is received, the CBA (and corresponding PDA) factors announce the deal result to the MarControlA factor and CA (and corresponding PA) factor trading on its behalf. The information on the customer behavior and the results of the transaction are updated by the market control factor (MarControlA) in the record deal maintaining reservoir and the previous transactions in the purchase of VMs (C_BehaviorDB). Moreover, PA is responsible for updating the remaining capacity of the reservoir used for maintaining the specifications of supplied resources (P_VMCHarDirectory). Then, the MarControlA factor deletes the transaction clue between the PDA and CBA factors. By deleting the transaction clues, the MarControlA factor sends the billboard updating message to the MarBillboardA factor, and the MarBillboardA factor updates the submarket billboard. Finally, the PA factor schedules and runs negotiated demand for its physical resources and updates the remaining capacity in the reservoir (P_VMCHarDirector).

If the “reject” message is received from the provider to the applicant or vice versa, the CBA/PDA factor must announce the result to the MarControlA factor as well as the CA/PA factor that deals on its behalf. The MarControlA factor deletes the transaction clue between the PDA and CBA factors. By deleting the transaction clues, the MarControlA factor sends the billboard updating message to the MarBillboardA factor, and the MarBillboardA factor updates the submarket billboard.

If the “Resource_allocation_process_Termination message” is received, which means that a round has been reached where the provider is not capable of staying in the market (NProRound = Deadline), it is necessary that the PDA factor announces the MarControlA factor and the PA factor that deals on its behalf, and if they exist, CBA/CBAs that are negotiating with it to pass the Deadline. The MarControlA factor deletes the transaction clue between the PDA and CBA/CBA factors. By deleting the transaction clues, the MarControlA factor sends the billboard updating message to the MarBillboardA factor, and the MarBillboardA factor updates the submarket billboard.

If the “Resource_allocation_process_Termination” is received, which means that a round has been reached where the VM applicant is not capable of staying in the market (NMarRoundk = NConRound), it is necessary that the CBA factor announces the MarControlA factor and the CA factor that deals on its behalf, and if they exist, PDA/PDAs that are negotiating with it to pass the Deadline. The MarControlA factor deletes the transaction clue between the CBA and PDA/PDA factors. By deleting the transaction clues, the MarControlA factor sends the billboard updating message to the MarBillboardA factor, and the MarBillboardA factor updates the submarket billboard.

Some samples of the described architecture are as follows: (examples 1 and 2 in Tables 2, 3, 4, and 5).

Table 2 Example 1—the offer price of three different customers for three different virtual machines
Full size table
Table 3 Example 2—the offer price of three different customers for three different virtual machines
Full size table
Table 4 Details of offer price for three different virtual machines in Table 2
Full size table
Table 5 Details of offer price for three different virtual machines in Table 3
Full size table

Table 2 shows the offer price of three different customers for three different virtual machines.

To pass the deadline, it is essential that the CBA factor announces both the MarControlA factor and the CA factor that deals on its behalf, as well as PDA/PDAs negotiating with it. When added to CBA and PDA/PDAs, the MarControlA factor deletes the transaction clue. To update the submarket billboard, the MarControlA factor deletes the transaction clues and then sends the billboard updating message to the MarBillboardA factor (Table 4).

4 Simulation and results

In designing a system for a large-scale cloud data center, it is necessary to perform various tests and experiments on the cloud infrastructure to evaluate the proposed algorithm, given that performing such rests on the cloud infrastructure is very difficult and costly, especially if it is necessary to repeat the tests (Fig. 7). For this reason, to evaluate the method proposed in this research, a simulator called CloudSim is used, which is an open-source library based on the Java language and the NetBeans programming environment is used [5]. Moreover, Docker has been used for information storage. The input of the system is a set of tasks that denote a working load (limited to the processor and/or input-output). The number of commands in terms of millions, the number of processing units, the size of the input and output file, the time entering the process, and the production model of the memory bandwidth and the processor, compose a task. To perform the simulation, it is necessary that the number of commands in terms of millions, as well as the time entering the process, be determined randomly. To obtain a random value for the number of commands, the normal distribution function with average value μ = 4000 and standard deviation a2 = 10,000 was used. As a result, the entering time of about 95% of the generated values fall in the range of 20,000 to 60,000. The Poisson distribution function was also used to obtain the random value for the tasks’ entering the time parameter. Since we want, on average, 100 tasks to enter the cloud network in each time unit, h = 100 has been considered. To prevent mathematical-related complexities, the Colt package was used. The size of the input and output files of every duty was considered a constant value equal to 3000 kb.

Fig. 7
figure 7

The details of implementation for market coordinator

Full size image

To evaluate the proposed algorithm, two scenarios were considered for the transaction in the market: using the regression for categorizing the supplied VMs and the lack of using a regression for categorizing the VMs. To implement the proposed algorithm, Docker and NetBeans were used as storage space and for algorithm development, respectively.

4.1 Market and dataset generation

Given the specifications mentioned for a proper dataset, to evaluate the efficiency of the proposed method, the design and simulation of the desired dataset have been done. In the following, the proper evaluating criteria for each part of the proposed method are defined and described to determine a definite criterion and compare the efficiency of the proposed method. Cloud as the only connector technology, processing and distributed resources to market demand and supply, includes many features of the demand market and free market. This shows the fact that every VM and its corresponding demand are known as a product in a market, called the processing resource market, and as a result, the cloud supplies its rental and processing products in the free market. One of the most important features of the products’ free market, which is highly emphasized in the literature of free market, is the demand iterative algorithm. This algorithm provides a reliable structure for supply and demand products, which helps the business manager to make decisions. Therefore, in this research, the dataset is simulated based on the demand process repeated on different days. This means that, in the presence of a little noise, the trend and amount of demand in different workloads and demands are iterated.

To generate and simulate this dataset, the data generation is done in a 2-min period, wherein at the start of each round, the algorithm of the proposed method runs automatically. Therefore, in 1 day, there are 30 × 24 = 720 iterations. Another parameter that should be taken into account in dataset generation is how to input the demand into the cloud. This, indeed, shows the amount of demand distribution at different times of the day. Although, the prediction of the workload amount based on the time has not been made yet, and the relationship between consecutive values in the time series of predicted workload will be decisive. To distribute the demands at different times of the day, in this research, we make a function by combining some normal functions (Fig. 8) [7, 14, 17, 18].

Fig. 8
figure 8

The details of implementation for market coordinator parameters are divided into two submarket and global levels

Full size image

The parameters on the global level mean that they do not depend on the market type, are consumer-dependent, and if calculated, it can be used for a consumer in all submarkets wherein there is consumer presence. The parameters in the market level mean that, by changing each submarket, the results will change. Therefore, for each submarket, this parameter must be calculated. Moreover, this parameter is the same for all consumers and does not need to be calculated separately for each consumer.

Degree of competition (DC) ∈ [0,1] denotes the degree of competition that the supply factor faces in round t. DC is calculated from the following formula (Eq. (1)) by considering the competitors and the trading partners:

$$\textrm{DC}={\left[\frac{m_{\textrm{t}}^{\textrm{a}}-1}{m_{\textrm{t}}^{\textrm{a}}}\right]}^{{\textrm{n}}_{\textrm{t}}^{\textrm{a}}}$$
(1)

where \({m}_{\textrm{t}}^{\textrm{a}}-1\) denotes the number of VM-type applicants in round t, and\({n}_{\textrm{t}}^{\textrm{a}}\) denotes the number of competitors. The more/less the DC, the more/less competition a provider faces and needs more/less coordination negotiation to reach an agreement.

This parameter is calculated for a submarket level and a specific quality level of the service.

This parameter is calculated in each round.

Time pressure (time pressure: TP) ∈ [0,1], this parameter denotes the time pressure on the side of the provider factor. The provider factor calculates the time pressure according to the following model:

Where T denotes the deadline and t is the current time, the more/less Tp is denotes the more/less TP and, as a result, needs more/less coordination negotiation to reach an agreement (Table 6).

Table 6 Details of parameters, the submarket level, and specific quality level
Full size table

These parameters are calculated at the submarket level and for a specific quality level of service.

4.2 Running the proposed algorithm in the simulation platform

To evaluate the proposed method, the market algorithm was performed in the CloudSim environment in two cases of using/not using the regression. The SLA comparison obtained from the performing of both algorithms shows that using the regression for separating data in the market leads to an improvement in SLA (Fig. 7).

In Fig. 9, the green line indicates the standard value of SLA. During the performing market in the cloud network, if the SLA output falls under the green line, it means the algorithm is optimized and, if it falls above the green line, it indicates a failure in SLA. As can be seen, when using the proposed algorithm, from time 6 s upward, the SLA moves toward being more optimal, which shows that the proposed method is efficient for the cloud platform.

Fig. 9
figure 9

The SLA for the proposed algorithm

Full size image

4.2.1 Checking response time

A comparison is made between the proposed method and others in this section. SP (36, 60) means that BAZAR is considered with 36 input data and 60 rounds of reputation data. To do this, the variations of the response time from time slots t to t + 1 per market creation per hour were investigated. The proposed method is less time consuming than etiquette and other methods. The load formed with the initial price in the proposed method has a shorter response time, indicating that it has a shorter response time (Fig. 10). The number of tasks from 300 to 1500 was tested for active market modes. The result shows that the proposed method was not efficient for reducing the response time.

Fig. 10
figure 10

Response-time review for the proposed algorithm

Full size image

5 Conclusions

Using cloud services, we provided users with access to virtual resources. A market-driven approach is one of the most common methods to manage virtual and physical machines in a network based on qualitative and quantitative findings. A novel method for setting an SLA using dynamic initial pricing of VMs in a competitive market is presented in this study. Cloud services are most commonly managed using a market-oriented approach. In this study, the main problem is constructing a VM’s initial price given the market’s dynamic conditions. Deals in the market are negotiation-based, and the negotiations are conducted using multifactor architecture. By categorizing VMs using regression, the results indicate that SLA is improved by using regression. When the proposed method is applied and the market is constructed in the Docker and CloudSim simulators, using the resources and checking the response times of the market are optimized compared to when the proposed method is not applied. As part of this study, the process of the construction market and the price of the initial construction project are also discussed, as well as how the service-level agreements are handled. Simulated results indicate that when assigning virtual machines to the market, the cloud market system provides improved service-level agreements (SLAs) and response times. As a result, using the regression method for categorizing the VMs improved the SLA.

For future works, the machine learning [33] and metaheuristics, such as particle swarm optimization (PSO), whale [11, 34], or other prediction methods, can be used to find the initial price for virtual machines in a competitive market. Furthermore, we recommend incorporating the security value of the VMs into the new structure, considering the recommendations provided by the Information Technology Infrastructure Library (ITIL) and IT Service Management (ITSM).