Java and Lock-in in the Cloud Computing Platforms

Java and Lock-in in the Cloud Computing Platforms is obvious result of combination of three factors. To avoid some fundamentals must be taken into account. Cloud computing and specifically the model PaaS is becoming more and more practical guide point for businesses and it can happen that a developer is required to deploy on fully or partially vendor locked cloud platforms such as Amazon Cloud or Google App Engine or Cisco Cloud. There are some fundamental differences which must be taken into account when programming, and we are going to discuss briefly in this article on Java and Lock-in in the Cloud Computing Platforms.

 

Java and Lock-in in the Cloud Computing Platforms : Three Factors

 

Java and Lock-in in the Cloud Computing Platforms is obvious for three reasons as we said. What are these three factors ? First is Java EE platform itself. Second is the vendors’ or providers’ specific aggressive mentality to implement the Vendor lock-in, which is obvious in case of Amazon Cloud or Google App Engine or Cisco Cloud. Third factor is not immediately visible but flows beneath quite steadily. This is the free options provided by the Vendor locked companies. They offer the Open Source companies the resources, involves the community to get involved, develops the product with many engulfed parts of coding and suddenly withdraws from being a Free Software. There are numerous examples, EyeOS is perhaps the biggest example.

 

Java and Lock-in in the Cloud Computing Platforms : Practical Tips to Avoid

 

While the offering of Free Resources can be used but dependency overkills the need, so we need to avoid the dependency. How to exploit that way ? We know the difference between the instance variable and variable class, the first is not static, while the second is. We use a static variable to tell the JVM that there should be only one instance of the variable. If the static variable is declared by finalizing it, then there will be problems in a distributed environment, because its value will never change. The problem exists when we expect the value of the variable can change. As in a clustered environment like GAE you as a developer will run your application in multiple JVM. If the value of your static variable is changed in the JVM, will not be propagated to the cluster thus leading to inconsistencies. Therefore recommended to avoid static variables unless they are configured as Final and at the development stages non-platform specific development is also done.

Caching Strategy concerns the performance to prevent certain operations. Sometimes we need to cache the objects in memory and then we implement our strategy of caching through the use of a simple methods or other caching solutions available for free. Caching has many benefits, but implement a caching strategy should be a practice to be treated with care. This is because the cache has the same problem with static objects.

 

 

In the event of a granted session data applications on the server, especially while using Google App Engine, some problems with session management are not unusual to face. Google has addressed many of these issues with its mechanisms for managing sessions Java applications. Most applications are written without having in mind any approach to PaaS with which we are working, so we use JEE as it is, with an approach that would work in the deployment of any self-hosted cluster environment, except for the Google platform specifically. The session data is always written synchronously in memcache. If an application tries to read the session data when memcache is not available, it will not succeed by connecting to the datastore, which might not yet have the data of the most recent session. This means that the asynchronous persistence may bring your application to a stale condition.

 

In case of PaaS we face a clustered environment that is not managed by us, with a different stack. In an environment such as GAE, it is difficult to know which instance will be triggered and execute the task only once.

 

This Article Has Been Shared 6437 Times!

Facebook Twitter Google+ Pinterest