If you play with fire, you’ll get burned. Exactly same happened to me in the post Cloud Perspectives, in which I had wandered off my usual comfort zones and with proper amount of clumsiness stumbled upon the topic I haven’t been able to describe properly. As it was too late to delete it, so I am bound to explain myself properly.

We we all agree the technology is driven by the innovation and the value added to its users. At the beginning of every progression there’s an innovation that demonstrates potential economic value assigned to something previously not recognized or possible. In most areas the innovation (IP) and it’s strategic value plays important part in the establishing or changing market place. Once the strategic value drops significantly, either by increased competition or by mass adoption, commodization is taking progress. From technology perspective it usually happens by:

• standardization
• adoption growth not manageable by a single or limited number of entities
• transfer of IP to 3rd parties
• containment of innovation itself in the mainstream know-how

In the process of commodification the competitive rivalry of the market will sooner or later face the loss of added value and therefore diminishing strategic value of particular innovation and diversity of competitors – finishing the process of commodification by the containment of original idea in the general know-how. Which will created environment best described as a pure competition (see Porter’s Five Force Analysis).

Now let’s take the Open Source into the equation. The movement itself is already recognized by doing all of this – removing technological barriers for adoption, providing a platform for innovation, reducing the cost of ownership compared to the proprietary technologies and establishing new environment for de-facto standardization of selected projects. Which, on its own, should give us perfect strategic way of achieving technology commodization.

The question remains though. Right now Open Source has been reduced to handful of products in order to simplify it and come up with the new business model. But reality is much more complex. Open source has been one of the major enablers of what we’re calling cloud computing, changing technological landscape as we knew it. As noted by Roman in his original post, the cloud environment comes with a different layer of interaction. The technological challenges we’ve faced before are already recognized and therefore commodified. Now it’s a question what new projects (or frameworks) we’ll have to solve the new challenges? Or better – as service nature of cloud computing changed the impact of open source, is there any way how to project an open source ideas into the service provisioning as well?

In his latest blog post, Roman Stanek contemplated about the disruptive effect of cloud computing. We already experienced its power in relation to the boom of social networking and as he notes it is undoubtedly going to disrupt the business model behind commercial software. Now, Roman asks how it will affect the open source movement?

For me the answer to this question lies in the position of the cloud computing itself. As a technology it’s nothing more than an evolutionary step. To understand my view let’s make a step back and have a look into the history and see what preceded our latest source of buzz.

First here was a network connectivity. Back in 1995 I tried to build my very first ISP. Daring I hear you saying? It certainly was. Some tried to fight it, some opposed it, most of us were amazed by the possibilities (however limited at the time) and the others were just oblivious. Connectivity was scarce, expensive and limited. As adoption progressed all these problems started to disappear. By the end of the 90s connectivity wasn’t any longer a privilege but a commodity. Bought, resold, aggregated, and extended. Would you even considering building own ISP today? I doubt so [1].

Next on the line was hosting. Everybody who missed the ISP game, and even ISPs themselves, entered a big chase for the ultimate hosting package. Story is the same as with connectivity. Originally it was scarce, expensive and limited. And its fate is similar as well. Hosting as a service has been commodified. You know the story.

As our needs increased, the next step was to focus on data centres. Transit connectivity and mass demand for hosting services increased pressure to provide huge data centres. Server provisioning become important. Numbers changed, from dozens to hundreds, from hundreds to thousands. You can probably guess what I’m going to say: it was scarce, expensive and limited. Physical kit just wasn’t enough. Virtualization matured and brought as where we are know. Into the cloud age.

Open source played major role in these transformations. As the need for commodification increased pressure to lower the price, existing software business models couldn’t cope with the increasing competition from the free software. Model started to changing into *aaS. Not much longer after that the open source technologies stopped being perceived as a disruption but rather as a competitive advantage.

Now it’s a good time to go back to Roman’s post. Where I agree with him is the fact the utility computing provides excellent environment for OSS to flourish. And increasingly complex world needs to be build on stable and open APIs, protocols and standards. Where my view differs is possible solution to the ‘problem’ open source is facing.

First I don’t really see a problem in the bazaar style development in the cloud perspective. Cloud computing, as it stands right now, is still in its infancy. And although we started calling our servers instances, talking about OS-level abstraction/virtualization and focusing on the streamlining provisioning, we are pretty much repeating what we’ve done before. Just changed the business model and created new horizons. Despite my reluctance, from perspective of innovation the future of the cloud computing is better characterized by platforms (like Google App Engine) – not IaaS as we perceive it today. For me underlying technology does not longer matter. I’m happy to leave so-called Cloud OS to existing providers. Because if I use the analogy of the internet connectivity and hosting, they are going to be cannibalized by their own approach. Bought, resoled and aggregated.

Second, I would like to use Roman’s terminology and change the outcome from two colliding solutions into their natural progression.

• For me Benevolent dictators are just a logical mark of the evolution itself. Leading providers will keep their stack closed for a certain (very limited) time, no matter if it’s build on open or closed source technologies. But with the growing demand to facilitate the interoperability and facing increasing competition at the same time it’s predictable they will open-source their complete stacks in order to utilize their momentum. In order to stay on top of the race, existing players will be ultimately forced to initiate commodification of the cloud services itself and expand their offering. For this to happen there are still some prerequisites we’re missing – at least standardisation of APIs/models behind IaaS and unified measurement of the cloud mass/computing power/matter. The signs of this development are already visible.

• The new model will eventually follow. The rational behind it is very simple. Industry wouldn’t be any longer able to build solutions on top of the increasingly complex architectures and face lack of the skilled professionals like you and me. As Roman pointed out, change itself will bring rise of conflicting opinions. In past, we managed to get over the virtual memory allocation, running our code within the virtual machines and cloud computing itself (as it’s just happening). But all these concepts addressed only existing problems. Now we’re facing new challenges. Building stones are already here – take *aaS, SOA, REST, hypermedia, microformats, orchestration and who knows what else, put it together and whoever will get the simple result will deliver it as a winner. Open source will definitely play important role not just as a facilitator for competitive advantage, but also as a instrument for companies to off-load their products when they become commoditized.

To summarize my rather long post, I believe the question is not how cloud computing will affect the movement itself. In my mind, open source complements cloud computing, exactly as mass production allowed commodification of physical goods. The question is whatever the cloud is going to provide future platform for open source concept adoption even outside the IT industry? Social networking is certainly showing us the way. But to find the answer is outside the scope of this post…

[1] This analogy perfectly reflects my view on the private clouds.

Yesterday afternoon, while relaxing in the garden I’ve suddenly realized why – in my mind – there was always a bit of hesitation to brand some of the emerging offerings as a true Cloud Computing. Amazon EC2 has always ticked the box. Why not the other providers? I knew the answer is going to be simple, but it took me quite a long time to figure it out.

Watching the sky where the strong winds were playing with the masses of condensed water vapor I’ve suddenly realized it’s not just a name these two phenomenas share together. It’s also volatility. Faithfully to their atmospheric cousins, compute clouds are definitely not representing static set of resources controlled by its users. Due to its nature where ‘perishable and intangible’ computing power is shared among multiple tenants to improve utilization rates, and therefore significantly reduce the cost, compute clouds are not just elastic but also indistinct, measured only by the mass of the resources currently allocated.

Having said that, I am obviously not suggesting Amazon EC2 resources are less resilient. Quite opposite. It’s simple a matter of the architecture where systems are designed for failure which at the end of the day will result in less failures affecting day-to-day business operations. Our personal experience might prove it, but nevertheless it’s always win-win situation if such a pattern is contained within the service itself. In this perspective I can see clear difference between Amazon EC2 and the other offerings. So until we’ll get more of the cloud nature, and less of re-branded VPS provisioning system, it’s going to be tough call.

Let’s try not to scale-in the IaaS resources or make them ever-so-resilient, approach more applicable within traditional infrastructure provisioning, but rather design our systems around this characteristic. And if you can’t get on with the indistinctive nature, try to have a look into a growing range of Platform as a service solutions. It’s a thin dividing line, I know, but the important one.

Following the rocket like boom of the cloud computing by the end of 2007, countless questions have been asked about security aspect of such a solutions. For many businesses this concern may overshadow other benefits – like agility, cost effectivity or scalability. This post is my reflection on true considerations one should take into account when moving into the cloud; all in perspective of the small to medium size businesses.

Many articles and studies casted a dark shadows on the general idea of on-demand provisioning of infrastructure. And they are right in one perspective: if you are not able to provide adequate security measures to your local hosted data or solution, you won’t be any better in the cloud (well, almost). Added remote access will only exponentially increase number of the potential intruders. But where this shadows do not reveal complete truth is the fact the lack of security is very often given by inability or negligence in businesses itself to establish adequate security. Which is not only the problem of small business, as we learned last year (2008) by series of blunders going all the way up to the British government.

Going back to the security of the cloud offering, where increased number of the security threats is anticipated, providers are (hopefully) taking preventive measures in place which we, regular users, wouldn’t be able to afford locally, especially in situations where the expectation is to bear the upfront cost of such a protection – no matter if it’s a physical equipment or operations staff (it’s up to you to pick the one more expensive for your business). As there’s no vendor able to address all the possible aspects and requirements, many of them choose openness to allow partners to provider added services. Perfect example of such a cooperation is the community surrounding Amazon AWS. Service aggregators will and have already started filling in the missing picture.

Other reactions are continually disputing physical security of the cloud computing and how such an anonymous solution can replace traditional collocation, dedicated or managed hosting services. It may sound bold, but I feel confident to say not only it can replace them but it certainly will, unless their are proactive in their offering. Based on personal experiences with even the most reputable companies on the market today we have to accept the accidents do happen, always due to the good old human factor. Especially when operation support is focused on an individual and very often not related resources, rather than anonymous blobs managed as a whole. Luckily traditional hosting market is not sleeping and we can already see different cloud based services coming from companies like Rackspace (Mosso) on one side and UK2 (vps.net) on another. To polarize the opinions a bit more I can’t wait who will knock in a final nail in the coffin of the companies refusing to change by introducing hosting platform provisioning on top of the existing clouds.

Due to the varied nature of the different cloud computing services it would be outside the scope of this post to list all the different security concerns, recovery scenarios and long-term viability options. This make selection of the provider important task, but the point is the process itself hasn’t changed so much compared to what we already know. Cloud computing is changing IT as never before, but it’s not technical rules that are changing (they’re evolving), but the business model is where the revision is being done; the rest is just a reflection of it.

With the JBoss JAX-RS implementation RESTEasy reaching version 1.0.1.GA I have finally managed to switch over from Jersey. Because my latest project has got all internal services and framework components represented as a JBossMC beans I needed a simple way how to export them directly as Restful resources without requiring any unnecessary boiler plate code.

I got inspired by Spring integration (which comes as part of the RESTEasy distribution) and wrote own resteasy-int-jbossmc which can be used under JBoss AS 5.0. Main difference is the application context scope – with Spring it has to be deployed as part of the same web application, whereas when deployed under JBossAS beans are instantiated within the microcontainer of the whole application server. To prevent scanning of unnecessary code I had to use feature called scoped kernel/controller and force restful resources to be scoped into own context, where they can be easily located.

Configuration (done in web.xml) then looks like this:

<web-app>
    <display-name>Archetype Created Web Application</display-name>

    <!-- configuration -->
    <context-param>
        <param-name>jbossmc-int.name</param-name>
        <param-value>APPLICATION</param-value>
    </context-param>

    <context-param>
        <param-name>jbossmc-int.qualifier</param-name>
        <param-value>demo-app</param-value>
    </context-param>

    <!-- RESTEasy bootstrap -->

    <listener>
        <listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>
    </listener>

    <!--
       !! Integration has to be configured after Reasteasy Bootstrap !!
    -->
    <listener>
        <listener-class>net.laststation.tools.resteasy.plugins.MicrocontainerContextListener</listener-class>
    </listener>

    <servlet>
        <servlet-name>Resteasy</servlet-name>
        <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
    </servlet>

    <!-- seems like mapping for now doesn't anything else than /* -->
    <servlet-mapping>
        <servlet-name>Resteasy</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

The integration is configured by jbossmc-int.name, specifying scoped context you want to use (APPLICATION is recommended), and the jbossmc-int.qualifier with he scope name itself (demo-app in this case). Also, please, note that ResteasyBootstrap must be configured first as it exports object required by MicrocontainerContextListener.

To export objects is then as easy as deploying them to microcontainer. Can be done using BeanMetadataBuilder, annotation or XML deployment descriptor as demostrated here:

<deployment xmlns="urn:jboss:bean-deployer:2.0">
    <bean name="library" class="net.laststation.demo.model.Library">
        <annotation>@org.jboss.metadata.plugins.scope.ApplicationScope("demo-app")</annotation>
    </bean>
</deployment>

The bean is exposed to MicrocontainerContextListener by annotation @ApplicationScope, which in this case specifies name ‘demo-app’.

Known Limitations

JBoss Microcontainer kernel scoping support at the prototype stages. Also similar to the Spring integration, Resteasy Servlet Dispatched must be mapped to the /*, otherwise it won’t work.

Download

Source code is available within my public BitBucket respository.

• resteasy-int-jbossmc

Building the services using JBoss Microcontainer isn’t complicated at all; create necessary classes and wire them together using XML descriptor or couple of annotations. But unless you’re building just a very simple components, you might want to be able to hide the implementation and expose only the special interface (public) beans to the outside world. JBossMC has handy feature to support this using scoped kernel / controller.

Let’s start with the example:

<deployment xmlns="urn:jboss:bean-deployer:2.0">
	<bean name="sample1" class="net.laststation.demo.mc.SampleBean">
    	<annotation>@org.jboss.metadata.plugins.scope.ApplicationScope("testApp")</annotation>
	</bean>

     <bean name="myService" class="net.laststation.demo.mc.MyServiceDemo">
        <property name="holder"><search bean="sample1" type="leaves"/></property>
     </bean>
</deployment>

In this deployment we’ve got a sample bean annotated by @ApplicationScope which will force sample1 to be instantiated within the application scope testApp. Publicly exposed service, represented by myService, requires this object, but instead of the regular injection it must apply the search method – using the XML element (as shown above) or annotation @Search, in both cases specifying the bean identification and required strategy.

Search strategies are implemented within the package org.jboss.dependency.plugins.graph and in general consists form the two kind of implementations, based on only the local scope or hierarchy. Current list includes:

• DEFAULT
• LOCAL
• TOP
• PARENT_ONLY
• PARENT
• DEPTH
• LEAVES
• WIDTH
• CHILD_ONLY_DEPTH
• CHILD_ONLY_LEAVES
• CHILD_ONLY_WIDTH

If you want to break the example, just change the search type to one that doesn’t take children scopes into account – for example TOP.

Below the line

Please note, the scoped kernel implementation is currently at the prototype stages. I wouldn’t expect significant changes in the functionality but configuration might be ‘adjusted’.

Personally, I would love to see support for the scope definition other than using annotations. Such an improvement would be much more coherent in the perspective of the meta data builder and XML configuration, where for example might be a place for the XML element <scope>.

Second comment goes to the requirement to use the search method instead of injection, for which the specification of the search strategy might be equally adequate.

UPDATE 28-05-2009 – Release of JBoss AS 5.1 has made this blog post obsolete and because I don’t longer feel any urgency nor think that is appropriate to comment on RedHat release or quality control process I’ve decided to retract the text.

I’ve been watching NetBeans development from its beginning as the Xelfi project, but first version I found interesting to consider using was 5.x. Now, one major and couple minor releases later, I’m glad to say things are getting better and better. Of course, it is very hard (almost impossible) to compare its Java editor with IntelliJ IDEA, and it’s refactoring and code assistance power. But as things goes, the flexibility of NetBeans is becoming more and more important for many of my personal projects. First, there was much improved Java support (since 6.0 editor rewrite), then C/C++ integration which gives me same environment on all the different platforms I’m using.

Now, to complete the full picture (at least for me), I’m happy to announce the Python support is now available as standard plugin or as a standalone platform. With the syntax highlighting, indentation, code completion support, together with debugger, platform manager, and interactive console, it’s becoming perfect replacement for any solutions available. After a first couple of hours, it’s clear winner.

Although it’s still not the best replacement for Java based projects (but definitely worth of considering), I’ve realized I’m using it more and more often for everyday development. I know how difficult is to even consider switching to different integrated development environment, but at least give it a try. It might not grab you straight away, but there is specific mix of functionality which makes NetBeans as a perfect and versatile companion for any developer. The whole product is having consistent performance, stable development cycle, very mature and open backing platform, which can be used as a kit for your UI projects as well, and all is packaged to very neat distribution.

UPDATE : and more good news coming from NetBeans Camp: some screenshots of new features for version 7.0 – code coverage support for supported languages.

Links:

• Python at NetBeans wiki

Let’s get rolling! Community version of JBoss Application server today reached it’s long awaited version 5.0.0 GA.

Download / Release Notes

Having spent some time this week resolving problems with Subversion repository due to poor network performance I’d like to intensify my efforts towards Mercurial (Hg). In this blog post not just the application itself, but rather introduce hosting capabilities and one of the projects from it’s biosphere.

No matter how decentralized version system might be, hosting is very important part of the infrastructure. Easiest way how to share Hg repository is to publish it using HTTP protocol. This can be easily achieved through CGI script called hgweb and in detail described in the document Publishing Repositories. To give you some idea how the interface look like, the list of some well known public sites follows.

• Mozilla
• Netbeans
• Xen

Success of a project is very often given by the quality of available solutions. Perfect example in Mercurial world is Bitbucket.org, the code hosting site with social aspects, which allows you to host up to 150 MB for free, with unlimited number of the public and maximum of one private repositories. These limits can be increased by choosing one of the available commercial plans, starting with 5 USD a month for 500 MB quota. The public repository concept is key to understand social aspects of this site, which gives you possibility to track changes in different projects and actively participate. I wouldn’t mention this project if it would be just for code hosting. Integral part of bitbucket is full featured wiki and bug tracking system, very similar to my personal favourite application – Trac. Everything packaged in snappy web interface, easy to use and exposing even advanced Mercurial functionality – like change queues.

I definitely recommended to try bitbucket.org, even if you just want to get more comfortable with Mercurial. As a new service there’s still a lot of functionality to be added, but that doesn’t detract from its qualities.

My only wish in regards to the Bitbucket might be provisioning of some background information about the company behind, future plans, and (fingers crossed) possibility to make it open source! That would ultimately establish this project as one of the fundamental companion products for every developer.

Links:

• Bitbucket.org