Cloud solutions
6 Cloud solutions
For a cloud based solution there are several possibilities. In this chapter the pos- sibilities for putting a product in the cloud will be discussed. Of course attention has to be paid to the architecture, but as mentioned before the business model will change as well, so this is something that should be kept in mind while designing a cloud solution.
6.1 General requirements
Outsourcing computation will have some risks for the users, especially when per- sonal data or business critical data is needed for the computation. It is difficult to have a solution that meets the security requirements since the solution has to meet several challenges. The first challenge is that the computational complexity of the system should not be too high, it should be practically feasible. If this complexity is too high the user’s costs can become prohibitively high or the outsourced com- putations might not be completed within a reasonable amount of time. Second it must provide sound security guarantees without restricting assumptions about the system. When the system assumptions are too restrictive the performance of the system will go down again so there has to be a good balance between security guarantees and practical performance. As third the system must provide benefits (e.g. financial savings, less effort, less responsibility) for the user compared to the local computation, otherwise the users will have no reason to outsource their computation. [9]. It is also important for an organization to check whether the software they want to put in the cloud is suitable for being put in the cloud. Some basic situations in which applications could be put in the cloud are:
• Applications that have little or no interaction with back-end systems. • Web servers. • Applications that have large fluctuations in the work-load. • Applications that are used for short term. • Applications that have to be set up quickly.
An application should not have much interaction with back-end system since all the data has to be transferred over the network or Internet. This will result in a lot of overhead and latency, therefore applications with a lot of interaction between them, should be located close to each other. Web servers are very suitable to be put in the cloud since they are accessible over the Internet anyway. When there
6.2 Target group
are large fluctuations in the work-load, these fluctuations can be easily captured by some cloud resources. By doing this an organization will not have to buy the hardware to handle the peak load. When an application is used for a short term it might be wise to use it as a cloud service, this prevents an organization from buying hardware for only a short term. Once it is determined whether an application is suitable to be put in the cloud there are some general requirements that are commonly expected for a complete cloud solution. The requirements that almost everybody wants to have in a cloud solution are listed below:
• The application must perform as well as on-premise applications • The solution must be scalable • The solution must be secure • The solution must have a high availability • The virtual machines and services must run stateless
A cloud application will not be accepted as a replacement for an on-premise appli- cation when its performance is much worse. In order to guarantee this performance when the application is used by more people, the application has to be scalable in order to respond to the changing demand. Furthermore the application should have a high availability to guarantee that the user can use the application whenever
he wants. Since security is a great concern when talking about cloud computing, the application has to be secure. In fact being secure is not enough, the security measures should be explainable to the potential customers. Last but not least, a cloud application has to run stateless, otherwise there will be the risk that when an instance breaks, data will be lost. This means that data cannot be stored in
a service or virtual machine. Data has to be stored via specific storage services. This has the benefit that data will be accessible for all instances instead of one particular instance. Another advantage of stateless applications is that it has the same execution paths, every time it will be run. So, stateless applications do not contain a state. This means that they don’t contain data and specific settings for every person or run. Such application will start with the same state every time it is used.
6.2 Target group
When moving to the cloud it is also important to consider the people that have to be reached. An important thing that a cloud service provider should do is thinking from the customer’s viewpoint. In order to do this it is necessary to
6 CLOUD SOLUTIONS
define the possible customers. It might be the case that only a specific group of people is interested in the solution so why focus on the rest. Another possibility is that large organizations are only interested in private solutions and smaller organizations are more interested in a public solution. This last point is actually not a shared opinion [17]. This means that a cloud service provider, once the potential customers are known, has to pay attention to how to satisfy specific needs. As already mentioned, in order to do this the customer’s viewpoint has to
be the starting point: which problems should be solved?; why is this interesting? Once the expectations of the customer are known, it is important to manage these expectations otherwise the customers might get dissatisfied. So it is important to communicate with the customer about the possibilities of the cloud solution.
6.3 Architectures
For a cloud solution there are several architectures possible. In figure 5 an archi- tecture is shown in which an instance of the product is running for every customer. By implementing this, the customer has its own private solution which might give more confidence in the security because the application of one customer is sepa- rated from the other customer. Furthermore, more customization is possible. For the provider this solution results in more work because all separated instances have to be maintained, of course this could be compensated with the price. In figure 6 there is an architecture in which there is an instance of the product running for every version of the product. In this solution there can be several versions of the software next to each other. For the provider this will result in more software that has to be maintained. For the customer this means that he doesn’t have the newest software automatically. This can be useful when there are software updates that require some kind of action at the client side. In figure 7 there is a picture of
a solution in which all customers are using the same instance of a product. This is the most general solution of the three. For the customer this means that he is always using the newest version but that he cannot personalize the software that much. For the provider this means that he has to maintain only one version and that he has to provide a really scalable solution. In this solution it isn’t likely that only one instance of the product will run because of availability concerns. There can be running copies of the same instance in order to guarantee the availability and maintainability of the system. When updating the system in such a situation it is just a matter of replacing all the copies with copies of the new version. When this is done by one at a time there will even be no downtime, which is an important requirement for a cloud service. The products that are shown in the figures can run in the public cloud as well as the private cloud. Of course there is also a combination possible in which some components of the product will run in the cloud and the rest is done outside the
6.3 Architectures
Figure 5: Cloud solution with an in instance for every customer
Figure 6: Cloud solution with an in instance for every version
cloud. Another possibility is that they run in both the public and private cloud. In this situation it is possible to give the customers a choice. It is possible to use the public cloud as spare resources in case that the private cloud gets overloaded. A second possibility is to offer the public cloud as a basic product and offer a private cloud is case that the public offering doesn’t fit the customer’s needs. Reasons for this might be found in legislation. While on-premise applications often have access to many internal applications or storage resources, this is an undesirable situation when an application is moved to the public cloud. Since in a public cloud the same application is used by many different customers, it is not a good idea to give this application access to internal systems. In general it is a much better option to let the on-premise applications push the data that has to be processed to the cloud.
6 CLOUD SOLUTIONS
Figure 7: Cloud solution with one instance for all customers
In order to get the promised availability, it is often necessary to run multiple instances of the software in the cloud. By running multiple instances it is possible to increase performance. In order to increase this performance it is necessary to have some kind of load balancing mechanism that spreads the request over the multiple instances. When the load on an applications is very unpredictable, load balancing will not be enough. It is possible to add new instances by hand, but in a lot of situations it would me much more convenient to automate this (with a maximum number of instances set). In order to be able to automate the scaling process the platform on which an application is deployed, should offer an auto scaling mechanism.
6.4 Choosing a provider
Once an organization has decided that they want to use or offer a cloud service, they have to decide whether they are going to develop a cloud completely on their own or that they are going to use services from an existing provider. In chapter 5 there was a list of existing platforms but this is not the only thing about which an organization has to worry when choosing a provider. It is important to make arrangements about a lot of things. For example the SLA; it must be clear how this SLA is organized. A monthly SLA is better than an annual SLA since an annual SLA can have a larger period of time in which the service is not available. Furthermore it is important to make clear arrangements about the ownership of the data, back-up activities and data format in which data will be delivered when it is removed from the cloud. There is a general checklist which should be checked before signing a contract, this checklist can be found in the report of ENISA [35].
6.5 Implementation approach
6.5 Implementation approach
Every company could start using the cloud but for existing companies it is impor- tant to do this in steps. Since existing software is not written for use in the cloud, there are some problems that could occur when this is not done. A company that wants to start using the cloud should start standardizing and consolidating. By doing this it will be guaranteed that the software is basically the same for every- body. If the software would be unique for a lot of persons it doesn’t make sense to put it in the cloud because than there should be an instance for every customer and the maintenance benefits would be lost. With the consolidation an organization should try to find the components in the software that everybody uses and that could be combined. Furthermore the infrastructure should be virtualized since that creates the possibility to use the hardware more efficiently [28, 45]. Once all the steps are completed and the IAM properties are set, the software can be placed in the cloud. Of course it is also necessary to have a valid business model because otherwise it will be hard to make money with the solution.
7 BUSINESS MODEL