the-journey-to-the-paas_2294x12031

PaaS Cloud – The Rise of The Developer Entrepreneur

by with 21 Comments Cloud

In bad times such as recession, there is the inevitable fact that some people will be laid off by their employer. In these circumstances, when software developer are made redundant they usually set-up shop. The majority goes into providing software development services for small company or friends. They set-up websites to promote their services and few focuses on building their own product.

In London, services based company took a massive hit during the downturn and it is still felt now; well the UK and now in a double-dip recession. So what is my point here? It is much harder to sell services and even harder to export services than products. When providing services, your market has geographical constraint; just think what would take for your to sell your services to a potential client 100 miles from your local?
It used to be hard to build products in the past due to high cost of hardware; to build a java-based product you had to find a suitable host and then pay for a dedicated server or VPS. As you are already tightening your belt, it is likely that you do not want to spend £60 + VAT a month on services to host your product and all the headache of troubleshooting it in case of problem.
Enter the PaaS, Platform as a Service. For this posting I am going to look at PaaS from a Java perspective but it should be applicable to any other programming language.
The competition in the PaaS market is fierce there is no single winner yet. Amazon is the leader for IaaS but not much to be deployed on Beanstalk as yet. If you look around the market, you can see that major technology vendor are jumping on the bandwagon:
Some of those PaaS services are free such as OpenShift and CloudBees. OpenShift runs on JBossAS7 and if you are using Eclipse for it becomes a breeze to develop and deploy, but the only downside is that it’s still in beta stage.
Utilising the current ecosystem of PaaS, you can go from:
inception (idea) -> development -> product
for almost nothing. The prototyping is now free for example you can use Heroku to build Facebook apps  making all the Facebook API directly available to your app and hosted for free (until you out grow your free account of course). I will suggest that developers familiarises themselves with Lean Startup and Lean Software Development.
If you are a developer and out-of work, you have no excuse of no building your cloud apps. Even if you do not want to start a business and you can do it as a learning practice and use that to your advantage next time you are interviewing for a new role.
With PaaS Cloud, every developer is a potential entrepreneur and the barriers to entry are almost non-existent. If you are looking for a job, it is no longer acceptable just to have some sample code on GitHub but you should also have a sample project hosted on a free cloud provider to showcase.
  This is blog was written from Cloudstock 2012

 
vodafone-top-61

5 Things all Java developer should know when developing for the cloud

by with 16 Comments Coding

The last couple of years, “Cloud Computing” replaced Web 2.0 as the new buzzword. You can read, hear and see everywhere the cloud is coming. To most developer, this is still the same old sh*t. If you have experience in developing distributed system then you should be fine, you say. Well not entirely true, the IT department wants to deploy on cheap cloud and therefore some restrictions now applies. I will list 5 things that I think all developers should know when working with cloud Platform as a Service provider such as Amazon Beanstalk or Google App Engine. This list also applies to IaaS architecture. Some of the points might be obvious to the more experienced, nevertheless, they need to be mentioned.

  • Static objects

We all know the difference between instance variable (non-static) and class variable (static variable). We use static to tell the JVM that they should only be one instance of this variable (singleton). If the static variable is declared with the “final” keyword, this will not cause a problem in a distributed environment as the value will never change. The problem is when we expect the value of the variable to change. As in a cluster environment, GAE and Beanstalk run your application in multiple JVM. If a the value of your static variable has changed in JVM, it will not be propagated to the cluster therefore leading to inconsistencies. I recommend that you avoid static variable unless that set as “final” and their values are hard-coded so there is no way to change their values are runtime.

  • Caching Objects
This one is related to performance in order to avoid expensive operations such as running database queries and others. Sometimes we need to cache objects in memory and therefore we implement our own caching strategy through the use of simple HashMap or some other caching solutions available outthere. Caching has many benefits but implementing a caching strategy should be approached with care. This is because caching has the same problem as static objects. Your cache will be in the local JVM therefore not it will not be visible in the cluster. There are some solutions, for example, GAE uses Memcached and Beanstalk can make use of Amazon ElastiCache which is compliant with Memcached. When developing for a PaaS environment, make sure to not implement your own caching system but look for one that is supported by the vendor. I know this can lead to vendor lock-ins.
  • Server-side Session
Something we do take for granted in single environment is storing application session data on the server. Based on experiences, mainly using GAE, I encountered multiple issues with session management. Since then, Google has fixed alot of the issues with the way GAE handle sessions for Java application. To minimize writing session to a datastore, we store application state in memory. Most application are written without any vendor approach in mind; so we use JEE as-is. This approach would work in you deploy in any self hosted clustered environment but Google PaaS. Google implements their own session management which is off by default therefore you need to enable it in appengine-web.xml and make sure that all your objects implements the java.io.Serializable interface.

Note: Note, session data is always written synchronously to memcache. If a request tries to read the session data when memcache is not available (or the session data has been flushed), it will fail over to the datastore, which may not yet have the most recent session data. This means that asynchronous session persistence may cause your application to see stale session data. However, for most applications the latency benefit far outweighs the risk.

 

  • Event-driven Execution
This is more about running a process at a given time such as Scheduling task. Again, in a managed environment, it is straightforward to implement a timer or scheduler service. But this is a clustered environment which is not managed by yourself and their stack his different to yours. I personally use Quartz Scheduler when working in a single server environment. In a clustered environment such as Beanstalk or GAE, it is difficult to know which instance will be triggered and execute the task only once. The folks at Google have provided another solution with their own implementation of Cron for Java which can be used. At the time of writing, Amazon Beanstalk didn’t have a solution yet. Therefore, consider before-hand when designing your system, which approach to take in order to create scheduled tasks for your application.
  • JRE white list
I believe this related to GAE J only. Google App Engine for Java doesn’t allow the use for all available API in Java, especially if they do require access to the file system. The fact that there is a such a restriction impose by the Google has led us to look elsewhere for some of our projects. The cost of re-developing our application to please them is much higher than deploying them elsewhere. Also, another downside of GAE J is doesn’t fully support JEE servlet specification. You cannot implement custom security for your application through your web.xml therefore pushing you to use Google own security mechanism. I would recommedn using GAE J when developing a greenfield project which can be built with these restrictions here  and here in mind. If you want to be locked-in using GAE J for your application, then I recommend it as a cost efficient way to testing your application otherwise, look somewhere else.
I hope this was helpful and if there’s mistake, feel free to get back to me and I make any corrections. Also, I am sure that I am missing some other points, add them to the comments sections.P.S. here is a nice comparison from IBM

Cheers and Happy Coding.