In the early days of cloud applications, PAAs service users raised the portability of their applications

Drunken Cloud Blog

Few companies can tolerate the binding of their own application development practices to a single vendor, but many companies are unknowingly tying application development and unique cloud providers together.

As the cloud becomes more competitive and some providers have a long-term stability risk, the developer must understand that the platform as a service (PaaS) is a trap because the platform features support is uneven and some PaaS providers pose greater risks than other providers, All PAAs choices can become more portable and user-friendly with the right project steps.

Even in the early days of cloud applications, PAAs service users raised the portability of their applications rather than asking the PAAs provider questions, rather than questioning them when they moved from the first provider to a different provider, or even to the data center. In some cases, this conversion requires major changes in the software, and results in project latency and even loss of productivity. The main problem is two specific problems that developers must address when creating portability applications for PAAs.

The first issue with PAAs portability is the lack of a consistent platform definition between PAAs providers. Using infrastructure as a service (IaaS), developers work with bare metal to provide all the system software needed for application. The problem with this platform is portability, since migrating from one IaaS provider to another can even migrate to local virtual machines. With PAAs, providers choose the operating system and middleware elements they support, and if the provider makes a different choice, then the performance used in these different areas will not migrate. If some PAAs performance is customized by the provider, it is even harder to apply the migration to the same platform locally.

The best solution for this portability problem is to create a platform reference point. PAAs services are typically provided around an operating system (e.g., Linux, Windows), a group of middleware for communication and database services, and management and development tools. While multiple cloud providers may provide the same infrastructure and transform middleware and tools, it is important to draw your first platform type performance chart highlighting what is not uniformly supported performance/tools. By avoiding these performance and tools, portability issues can be avoided.

The second problem is the lack of reliable platform substitution providers. Today's PAAs services typically provide two of different forms. First, the platform "owner" (Windows/azure of Microsoft, for example) may provide a cloud version of a valid server platform. In this case, the first category of Paasi business advantage may also hinder competitiveness, although platform providers have considered (Microsoft recently changed Windows Server to promote non-Microsoft Windows PAAs products. )

When a dominant provider suppresses PAAs competitiveness, the only alternative available to cloud users is to use IaaS services, including the PAAs "platform" section of their machine image. If you do this, the key is to ensure that all PAAs performance is available for the local server configuration. The risk of major platform providers (such as Microsoft, IBM, HP, or Oracle) may simply be to avoid small PAAs operations, but where small providers are PAAs's only option, it is prudent to plan an IaaS retreat.

The second solution to the problem is the adapter design pattern. Cloud applications must reference services that may not be available to all providers, encapsulate references to higher-level software elements (follow adapter design pattern principles, have a common object-oriented design), and transform common requirements to the specific forms of PAAs service needs.

For example, suppose an application is developed for Amazon's redshift warehousing service. However, IaaS services are compatible with the widely used Amazon EC2, and other IaaS providers do not provide redshift, and applications are written for "Minipaas", ec2/redshift cannot migrate without changing all project references to redshift. A developer wrote a small software object, called "Warehouse", to replace the Redshift application interface (API). Inside the warehouse, the code may change the database operation parameters, become the redshift format, and then invoke redshift. If the application then shifts to a provider that does not support redshift, the warehouse will have to be changed to perform the correct database access API requirements to simulate. A single change to the warehouse object allows for application migration.

This abstract based mechanism also applies to the management of application portability, which requires building a cloud application on a platform's performance, and competition analysis shows no widespread support. The key is to ensure that there is at least a reasonable way to deliver the same performance/functionality on multiple platforms, even if the same APIs do not work across platforms, such as the warehouse example mentioned above, there is no comparable service on one or more alternative platforms. Then the adapter design pattern mechanism does not easily support portability among them.

Over time, the biggest portability risk for PAAs is not a normal PAAs platform, such as Azure, but as IaaS services evolve into PAAs services by adding some performance, such as Amazon's redshift or caching services. Many users of these platforms will never see themselves as PAAs users, and may be surprise when they first try to transfer applications to another provider. A small amount of advance planning can prevent major problems, and experience can also assist cloud experts to understand the potential for PAAs portability as a performance differentiator for enduring stress.

(Responsible editor: admin)