This is an essay I wrote for the course IT Management. The task was to write an essay about one of five given topics. The topic I chose was cloud computing.
In the past decades, there has been an explosion in terms of available computer resources. Smaller, cheaper, faster, robust, and scalable computer systems. Virtualization and cloud were a few years ago – and still is some of the most popular buzzwords in IT. It opened a completely new dimension for the computer industry. Instead of investing in a large data center that was used only an hour a day, the computer resources could instead be hired from a cloud vendor such as Amazon or Microsoft. Although many techies says the cloud is the solution to everything, there are several risks and challenges when it comes to exploiting the great advantages of the cloud. In this essay, I will mainly discuss challenges around using PaaS (Platform as a Service). In addition, I will also discuss cases where PaaS would be an excellent choice for an application instead of running the application on premise.
About a year ago, I had a discussion with my father on why having an off-site backup in the cloud is a good idea. As my father is a sceptic, he asked the question: “If the cloud is so popular and grows so rapidly, when will it start raining?” As a hang-glider pilot, he knows how unpredictable the weather may be. Although my father may be a bit paranoid when it comes to IT, he still has a good point. Even though we do not have a weather forecast of the cloud, there are important challenges to consider when we start using the cloud. In this case, the question was mostly around trust but also about what would happen with the data if there is a natural disaster, the company goes bankrupt, or if the company will still store all the data and applications in 20 years. One aspect is also in the event where migrating the application to another service provider would be an option, not only because of bankruptcy but also if someone else would be able to provide better and/or cheaper service. Even though these are mostly SaaS-related issues, they also apply to PaaS.
Figure 1 – The cloud stack illustrates the relation between cloud services and different technologies.
Platform as a service allows developers to write an application, for example a web application, then deploy it in the cloud. Software as a service may be the deployed application, while infrastructure as a service may be the web-server, frameworks, operating system and the virtual machine beneath the hosted software. PaaS has a focus mainly on deploying an application to the cloud. An important aspect is that PaaS allows companies to focus on their application instead of having to worry about the underlying infrastructure of the application. What makes it different from running it on-premises is that we no longer need to purchase large servers used only a few hours a day. Neither do we have to worry about configuring the servers either. The cloud vendor takes care of managing the hardware and installing the required software and the servers are just waiting for developers to deploy their code by using the tools provided by the vendor. PaaS is in many ways a toolkit that makes it easy for developers to develop, test and deploy applications.
Although PaaS offers much flexibility in terms of scalability, one obstacle in terms of flexibility is the underlying components in the cloud stack. Each cloud vendor has their own set of developer tools and framework APIs. One of the reasons for this is to make deployment to the cloud as simple as possible. With a push of a button, an application deploys from an IDE to a virtual test-environment in the cloud. After testing and quality assurance in the test environment, the application is ready for the production environment. However, investment of licenses and learning the IDEs may be required depending on experience and the PaaS vendor. (1) Even though it is often possible to use other IDEs, it may be required to use other IDEs by the vendor. In fact, one great advantage by using PaaS is that an application can be deployed with the push of a button directly from the IDE. This may only be possible from a licensed IDE specified by the provider.
The lack of experience is not only limited to the IDE, but also the underlying framework for the target PaaS platform. If a developer team has a lot of experience with Java and C++ on Sun servers, it might be a disadvantage to choose C# on Microsoft Windows Azure instead of Java on Amazon Web Services. In addition to a new IDE, the developers would have to build up experience and knowledge around new frameworks. Another disadvantage may be that the developers does not know how to use the new frameworks as efficient as other frameworks. However, if such a transition is required, platform vendors such as Microsoft and Amazon try to design their frameworks and parts of their languages so the transition phase would become as smooth as possible.
Standardization among cloud vendors is a well-known issue in cloud computing – hence the term vendor-lock. (1) Each vendor may provide a different set of APIs that others may provide in a different way. The European commission published a report in 2012 (2) that discusses issues related to cloud computing. The report also discusses the potentials of the cloud and issues that needs to be resolved.
“A jungle of standards generates confusion by, on one hand, a proliferation of standards and on the other hand a lack of certainty as to which standards provide adequate levels of interoperability of data formats to permit portability” (2) Page 5
Not only is how the lack of standards in APIs among vendors but also the issue related to information silos discussed in this quote. Information silos will be discussed later, however, how Microsoft and Amazon provides different APIs is one aspect which the report targets.
One possible solution to the platform binding is abstraction of the underlying framework. (3) This way, it is possible to write PaaS vendor-independent software that makes it simple to switch between cloud vendors. (3) However, abstraction is never free. Neither in terms of cost or performance. Another issue is how well the layer above PaaS integrates with different vendors. One vendor may be well integrated but another one may have some key features missing in order to get the application efficiently running.
Even though the application may be less vendor dependent thanks to the platform-independent framework, the platform-independent has to support several vendors in order to obtain vendor portability. The portability enforces equal support across different vendors. Key features that is required by the application may also be missing at one vendor but available with another. It is also an issue when the cloud vendors makes new features available as then the new features has to be implemented in the platform-independent framework before it could be used in the application. Another issue may be maintaining the mapping between new and obsolete API calls. However, the discussion related to platform retirement and lifecycle in the cloud will continued later.
When choosing a cloud vendor, it may become hard to switch from one vendor to another. This is because of the underlying framework that the application may use. In addition, the service agreement with the provider may also stand in the way. One of the largest issues around using PaaS is the platform binding. If the cloud vendor in any way stops providing the cloud services, the application has be moved to another provider. The more integrated the application is towards the PaaS provider, the harder it is to move to another provider. Framework calls and database engines may be changes and hours of testing is required to make the application run on another provider.
During the planning of software running on PaaS, laws may have an impact on the architecture of the application. Some countries has laws that permits where information may be stored and transferred. This may become an issue when it comes to scaling. However, this may not be the only issue leading to scaling. As larger systems consists of several other components, there are components that are not trivial to move to the cloud. There may be several reasons for this: One reason may be that the components are old systems that would require a large amount of resources in order to migrate to the cloud. Another one may be of the nature of the application and that therefore it may not be a good idea to move this component to the cloud.
Figure 2 – Information silos: Different software and services for each department often lead to that different computer system gets in a degree isolated from one another.
It may seem like a good idea to keep financial records, emails, user databases, and other information on separate server as they may require special software to run. Information silos is a term used to describe systems that has one or several specific purposes and therefore becomes hard to integrate with other systems. These information silos may become an issue in terms of integration when moving to the cloud. (4) Some of these silos may be old systems. Upgrading existing systems may be an option if this would make it easier to integrate with the cloud. However, the issue regarding integration made a new variant of platform as a service emerge in the cloud market: Integration platform as a service.
Because of the integration issue, a new form of PaaS emerged in the cloud market: Integration Platform as a Service (iPaaS):
“An iPaaS provides a combination of some of the features found traditionally in on-premises integration platform software, such as enterprise service buses (ESBs), data integration tools, B2B gateway software, application service governance platforms and managed file transfer products.” (5)
iPaaS may not only be limited to integrating older systems, but also new ones like social media. iPaaS is in other words a service that makes it easier to integrate with other services. These services may not only be limited to CRM, sales/management or ERP systems but also for integrating towards APIs for social networks and analyzing big data. In other words, iPaaS deliver different services as a middle-ware between the application and other services as a part of the platform a service layer in the cloud stack. “Layering and abstraction solves all our problems” (6) although iPaaS may provide several tools to make it easier to integrate different services, there would always be unsupported systems that would require extra development. iPaaS is a relatively new technology and one consideration may be whether it is ready to be used towards different services. Although some systems may be supported through the iPaaS platform, other systems may require additional adjustments and in some cases a fully development case.
Figure 3 – iPaaS integrates to different services on the same level as PaaS
When an application is hosted in a PaaS environment, there is normally nearly no access to the underlying components in the cloud stack. The cloud vendor may not support customized hardware or settings for fine-tuning the application. However, the vendor may most likely provide some options for configuration and fine-tuning.
Considering the lack of control and flexibility higher up in the cloud stack (See fig. 4), one way to prevent some of the vendor lock-in is to consider using IaaS instead of PaaS. This makes it not only customize and fine-tune the underlying layers of the application but also makes it easier to select other frameworks. Instead of being bound to the frameworks provided by the cloud vendor, it is now possible to choose any supported framework on the host operating system. Although it would be possible to get more flexibility and become less vendor-locked because of IaaS, other issues arises. The cloud vendor does no longer give direct support to the framework, neither is any pre-configured ready-to-deploy environment directly available after receiving the computer resources. The customer has to configure everything from the operating system to the application and much of the point of using PaaS is lost.
The lifecycle plays an important role during the development of an application. Should the application be in operation for three years until it becomes obsolete? What about updates? Should there be only one release of the system? What happens if there is a bug? In which context should we use the system and which technologies it will use are some factors that has an impact on the life cycle of the application. In PaaS, it is not possible to change the underlying framework. For how long would there exist support for the framework and the IDEs?
Each cloud provider has an own policy on how the life cycle of their platforms and products are handled. In Windows Azure, Microsoft would notify customers 12 months before a guest OS or an SDK is retired. Microsoft also advices that the latest SDKs should be used when developing a new application that runs in the cloud. (7)
A large part of the core around the issue of PaaS is around trust and responsibility. The cloud provider must be able to provide service, however, what would happen if the provider went bankrupt? The service level agreement (SLA) specifies the rights of the customer and other guidelines. Although it may not be possible for the vendor to abide all these agreements, the damages of a cloud vendor may be extreme. In the cloud stack, the extent of the bankruptcy increases higher up in the stack towards SaaS. On IaaS, the customer can retrieve the data on the virtual machines. It would also be possible to recover the application and other data from a PaaS vendor. However, the application would still require the APIs that the cloud provider offered that the customer might no longer have access to. This would require a re-mapping or perhaps some re-mapping of the APIs and perhaps some redesigning. However, the greatest impact is on SaaS where the customer may not even have right to the application data and application access is simply lost.
Figure 4 –extent of bankruptcy increases higher up in the cloud stack as with vendor lock-in
One way to mitigate the damages from a bankrupt cloud company is to choose a well-established provider and make investigation on the underlying vendors for the cloud provider. A paper by David S. Caplan from Law Offices of David S. Caplan discusses different aspects of how bankruptcy may affect its customers. (8) One of the main highlights in the article is that the extent increases higher up in the stack as illustrated in fig. 4. Under IaaS, bankruptcy may in addition to the user, affect the hardware host, software provider and the network provider. The article fails to reflect aspects under PaaS, but it mentions that the extent would be far more severe as the user must rely on different software and interfaces (APIs) that the provider has to offer.
As discussed above, the result of a bankruptcy may be that another third party may get access to the business and application data. However, this may not be the only case where another third party may gain access to the data. The vendor has to provide transparency into the routines of the security of their services so that customers can understand how the vendor manages security. Although there is no direct solution to this, it is a heavily discussed subject in terms of information security. A cloud vendor may provide better security compared to hiring security analysts for a system running on premise. On the other hand, a common saying is “security is an illusion” where the provider may not actually provide the security and routines specified in the SLA.
Whether the provider would be able to provide better security than security personnel on-premises has created great debates. Under a debate in Network World (9), Harold Moss from IBM Security Solutions and Jim Zierick from BeyondTrust discusses if the cloud provider is able to provide better security than running the application on premises. Harold Moss discusses how false sense of comfort leads to poor monitoring and security management as well as several aspects around why the cloud provider may provide better security. Jim Zierick discusses how humans will always be the weakest part of the chain and how the statistics points in the direction that few companies trust the cloud very well. Moss may be right depending on the size and type of company or organization. A small IT startup may not have as skilled information security personnel compared to a larger, well established IT company. Nevertheless, this is an example and the situation could easily be the other way around. Zierick concludes that it would be better to run the application on premises if the risk factors are lower than running the application in the cloud. This would be a contradiction to Moss as he says that the cloud may most likely provide better security, however this may not always be the case.
The security aspects of the application may be different in the cloud. As the application runs in the cloud, restrictions to the application may no longer exist through design but by manually specifying the restrictions. These restrictions may not only apply to the application itself but also around the control panel for the application itself. A user of the application may only access the application through a corporate VPN or only from the corporate network. Access management in terms of corporate positions may also be an issue. There must be a way to tell the cloud application after the termination of a worker and that this specific person should not have access to the application any longer.
Microsoft has posted an article on TechNet discussing issues around authentication, access control and authorization. (10) The article provides a checklist for what to look for when considering a cloud provider regarding password policies:
- Password complexity requirements
- Time expiration of passwords
- What is done to prevent password compromises, for example two-way authentication
The article also discusses how authentication towards a centralized point that in this case is running on premises can solve several issues related to authentication. As this makes the cloud solution move in a direction to a hybrid-cloud, it also creates a single point of failure. If the mainframe that holds the authentication system goes down there is no way for uses to access the application.
In terms of access management, the security of the data connection may also be of concern. An increasing trend is bring your own device (BYOD) and it should be possible to work from anywhere at any time. This introduces new risks such as man in the middle attack. After Edward Snowden informed the world about how national agencies are collecting data from almost everywhere, (11) surveillance by government agencies quickly became one of the largest cyber threats to companies: Microsoft considered this threat as an “advanced persistent threat”. (12) Even though companies “has nothing to hide” for the government, confidential data is not something the government should have direct access to. As the data travels through public internet connections, not only may the “bad guys” capture sensitive data, but also the government.
It would be possible to mitigate some of the issues related to BYOD and man-in-the-middle attacks by using VPN connections and enforcing applications to use SSL/TLS. Several surveys shows that companies does not often trust the cloud vendor when it comes to private/sensitive data, this survey will be discussed later on. (13)
That the cloud provider is trustable is one of the most, if not the most important factor when choosing a cloud provider. This applies to almost any scenario where outsourcing is an option. According to a survey by Lieberman Software (13), 88% of IT professionals consider that data in the cloud could in any way be lost or be handed over to another third party. 86% had chosen not to store sensitive data in the cloud. On the other hand, 46% believes that they got better security by moving to the cloud. However, this may change after time as companies trusts the cloud more and more.
Transparency is a key word when it comes to whether or not vendors can be trusted. “Security by obscurity” is an old saying in information security. Knowing that the cloud provider has routines and is able to provide good enough security may be comforting, however even though the risks factor may be mitigated to some extent, the consequences of a security breach may still be fatal. The Cloud Security Alliance published a report in 2010 on the top threats to cloud computing: (14)
- Abuse and nefarious use of cloud computing
- Insecure interfaces and APIs
- Malicious insiders
- Shared technology issues
- Data loss or leakage
- Account or service hijacking
- Unknown risk profile
According to the report, everyone except number four applies to PaaS. However, underlying security in the cloud stack is something that should be of concern. On the other hand, it may not be possible to know that the provider can offer service that has a satisfactory level of security for the application needs. Encrypting data in the cloud and have regular backups are two ways of reducing this risk factor.
Under SaaS, the customer often loses the rights of the data uploaded on the service. However, PaaS tells a different story depending on the contract and the laws in the country of the provider and the laws in the locations of the data center where the application may run. Who has rights to the hosted application and the data in the cloud is an important aspect if for example the provider may go bankrupt. If the customer has no rights to application and the service agreement does not even mention what should happen during a bankruptcy, there would be a large chance that the customer may lose all the application data.
There are mainly two available options for payment in the cloud: Pay-as-you-go and a monthly plan where the resource usage is given. If the resource usage is given, there may be a possibility to save extra costs as these plans are in general cheaper than pay-as-you-go (15) (16). However, neither of these is a good option in case an application-level denial of server may occur. With the pay-as-you-go, there would be a possibility to get a very large server bill, while with the monthly plan there is a chance of service interruption. The service agreement should provide guidelines on what would happen in the event of a denial of service attack. In the ideal world, the perfect cloud application could possibly start scaling out over an entire cloud in the event of an application-layer denial of service attack. Having a mathematical model that would predict the usage of the application is an option but is not capable of predicting that a mobile application would go viral, nor large attacks. Just like how hard the weather is to predict, predicting application usage is hard depending on the type of application.
Even though the cloud may provide nearly endless possibilities when it comes to scalability, this does not necessarily mean that the application would be any faster. The geographical distance of the location of the user and the data center where the application runs may under extreme conditions cause delays up to several hundred milliseconds. This is a common issue related to cloud computing. (17) Even though if the load time of a web page were a few hundred milliseconds, it would be considered as slow if it was a server call for a first-person-shooter that would require low response times. In addition to higher network latency, an internet connection would be required if the application ran on a public cloud. (18) Although the application design might be a source of the latency, the network would be the biggest bottleneck in most cases. Network latency can to one degree be mitigated by deploying the application to nearby data-centers and optimizing network routes, but it still may be the biggest bottleneck for the application performance.
An ideal application to move to the cloud
Even though there are many issues relating to using PaaS, there are applications that as easier than other to deploy in the cloud. Even though there is no real answer to what is the best application to move to the cloud, there are key points for which types of application that fits in the cloud. Several sources discusses which types of apps fits well into the cloud. (19) (20) (21) Some of these articles covers applications running in the cloud (SaaS), however these applies also to the type of application that is developed and hosted under PaaS. The discussed categories are as following:
- Applications that require scale
- Collaboration applications
- Applications that require rapid deployment
The first category is for applications that require scale. The big buzzword in the cloud is scale. Large amounts of computational power is available and the application should be able to scale out in the cloud to serve more users. The other category is for applications where many users gets together and start working together. It may be an online collaboration tool or an online game. The last category is more development-oriented. Applications that require different staging environment may sometimes be well suited for the cloud. This is a typical category for cloud applications. Most vendors provide different staging areas for application deployments. As some applications require rapid deployment, the cloud may be well suited for these types of applications.
A mobile instant messaging application would be an excellent application for several of the categories discussed above. Several thousands of users may begin using the app overnight. If the application would run on premises it would require 24/7 monitoring and installation of extra hardware and servers in order to meet the new performance needs. If all the users suddenly stopped using the application, barely any of the servers would be in use. Amazon once had a large amount of server capacity to meet the large amount of traffic during periods where people would go online and shopping. They decided to lend out the server capacity when they did not use it and it was the beginning of Amazon’s role in the cloud.
The cloud application require that several users interact with other through instant messaging and perhaps other ways like sending images, audio or video. In other words, it fits well into the second category. It also fits well into the last category as hotfixes could easily deploy to the cloud.
There are however different cloud models: Private cloud, hybrid cloud, public cloud and community cloud. Under the private cloud, the application would run on resources specifically allocated for the customer. Guaranteed resources is a description often used for this cloud type. Under community cloud there may be several customers who share the same computer resources. Application running on public cloud may share resources with anyone. Because of this, many companies chose to run their application on a private cloud. Some of the security issues discussed earlier may no longer exist but several other issues would always exist in the cloud such as the vendor lock-is issue, risk factors and so forth. Hybrid cloud is a way of keeping a part of the application running on premises while the rest us running in the cloud.
Companies never move their entire computer systems into the cloud as one big cloud project. This would be a hybrid cloud solution in the beginning. iPaaS as discussed earlier would be an excellent tool to make different services running in the cloud talk together while at the same time have several other services running on premises by making the transition to the cloud more agile. By moving out one and one system each as one separate project it is also easier to evaluate whether the cloud transition was successful or not.
Several risk factors needs to be analyzed and mitigated. The vendor should be able to deliver the promised service and the application should be as secure as if it was running on premises. Investigating how well the cloud provider and its underlying providers stand financially may be a good beginning to the bankruptcy problem. The SLA should specify which rights the cloud customer has in the event of a disaster or hardware-failure in addition to bankruptcy. Using cloud-platform-independent tools makes the application less vendor-bound although this layer of abstraction has its downsides.
When and in which degree the company should use cloud technologies should be a question that should be answered in the IT-strategy. It is a question that should arise during the phase of the Y-model that discusses what needs to be done related to IT. As discussed above, the transition to the cloud should not apply to all the systems owned by the company but instead a few systems at a time. Whether it is a good idea or not to move the system to the cloud should also be discussed. Some systems may not fit for the cloud either because of their nature, design or law restrictions.
Developing an application under PaaS is not an easy job. Several issues will arise. Although it may not be possible to eliminate all the risks, vendor lock-ins and legal issues, the cloud may still be a better choice than hosting it on-premises. Some vendors says, “Everything will be taken care of” and there are no risks. However, the real world is unfortunately not that simple. The cloud would require trust, different application design and lawyers. Although the issues that existed when the application was running on remises does no longer exist, the real issue now is that the vendor would have to worry about these issues and does an equal or better job.
There is indeed nothing perfect in the world, and nothing is free. Considering the difficulties when using PaaS or other cloud technology is in many ways like looking into the future. The vendor must be able to provide its service and not go bankrupt. APIs should not be retired and legal issues should not arise months after the development of the application. To make the hardware “abstract” in the cloud through the cloud provider will probably not be free of issues but current issues may probably transform to new issues. Looking into the future is not easy, just like the weather. Moreover, the cloud does indeed need a weather forecast.