Cloud Computing for Development Governance

Development governance is a common problem for any organization developing applications to cater their business needs.

Any service or application that is being developed has a lifecycle. From development to being in production, we have various roles involved such as developers, testers (QA), IT folks (Dev Ops / Tech Ops). As the service or application propagates through the lifecycle, the related artifacts (code, configurations, etc.) as well as know-how needs to be propagated and handed over to related parties playing various roles.

One of the challenges in the management of this life cycle in development governance is to make sure that, we have identical setups across various environments used. For example, the QA setup, need to be similar to the staging. And if developers made assumptions that are way off to that of the production system, and they have no way to verify the real aspects, there will be loads of corrective fixes left off till late. In short, development testing, QA testing, staging and production should have identical, or at least near identical setups. 

Another challenge is the propagation of artifacts. Where should the QA should pick what to be tested and where should the Dev Ops pick the artifacts to be deployed to staging and from staging to production.

To ensure that we maintain uniformity across environments, and we have means of enforcing the proper process and means of artifact migration and management we can turn to cloud computing.

The cloud environments cater for various roles, to deal with their activities in the respective lifecycle stages of the service or application. The cloud environments can be hosted with identical software. The Platform as a Service solutions such as WSO2 Stratos, can be used here.  The PaaS solutions usually come with built in repository management mechanisms to help the users belonging to various roles to pick what they want from one environment from another.

For example, when the developer completes the development and is happy with the developer testing on the development cloud, he or she can raise a notification to QA folks indicating the readiness of the application or the service for QA. Then one of the QA folks, respond to the ‘ready for QA’ notification, picks those artifacts from development cloud and promote those to the QA cloud. If the tests fail, tester can demote the artifacts back to development cloud and raise a notification to developers mentioning that it needs more work. If the tests pass, the tester can raise a notification for Dev Ops indicating the service or application has passed QA and ready for staging. The Dev Ops then can promote the QA passed service/application artifacts to staging cloud and inform QA to run and verify automated tests on staging to ensure the service/application is ready to go into production.

 

Technorati Tags: Cloud Computing,Governance,PaaS

43 Things Tags: Cloud Computing

Three years of evolution – WSO2 Carbon

It was three years ago that I blogged “Yes we did it!!!”

Yes we did it, three years ago. So WSO2 Carbon Middleware Platform is now three years old.

You can find what Paul & Sanjiva had to say about Carbon three yours ago, as I captured those links in that post.

I could also fin a blog by Isuru on this Carbon releases. That post shows the four main products we released with this Carbon 1.5 release. And yes, it was not Carbon 1.0 that we released three years ago, rather Carbon 1.5.

Even though the public got to know Carbon three years ago, WSO2 started discussing Carbon internally four years ago. It was discussed in the WSO2’s annual off-site planning meeting in 2008, under the title “product unification”. At that time, I was working with the C team, and the unification was discussed for Java based products such as WSAS & ESB. Myself and few others were also invited for this planning meeting, where this Java product unification was discusses, and to be frank, most of the discussion ideas “flew over” my head. However, the initiation to participate paid off few months later, as I ended up one of the drivers of this whole effort, towards the second half of 2008.

“Product unification” rationale was driven by simple rationale at the time, in 2008. We were building a middleware stack, but our own products did not work together. The products were in silos. The example used at the time to explain the problem was the way we secured a service. In WSAS, there was a nice UI that could be used to secure a service, but the ESB could not re-use the same as it was. Why not, why cannot we use the same technique? How can we make the cross cutting concerns available across the products rather than re-doing them over and over again?

These discussions, which started in the 2008 off-site planning meeting, evolved in the months to follow. OSGi came to the picture as a result. No one in engineering knew what OSGi meant for the platform at the time and there was none except Paul who believed that it would work.  So there was resistance first, then fighting, and then came the CEOs verdict, lets just do it and see how it goes.

So we did, we just did it. And while doing, we figured how to do it, we brought in OSGi trainers, and we figured how to adopt OSGi into the product platform. And by fourth quarter of 2008, we had figured for the most part, the advantages of OSGi and how it is going to make our middleware platform a “platform”.

I consider the move from siloes of products into a product platform a key evolutionary step in WSO2 software. But over the past three years, we have evolved at an exponential phase. In 2009 February, we released only four products. Today, we have 14 products, and 12 Stratos services.

The invention of the Carbon platform made WSO2 DNA much more agile and adoptive to change. This is evident from what we have build on top of Carbon in the past three years. The most note worthy is the introduction of cloud native elements into Carbon and the creation of WSO2 Stratos. We started the cloud effort in Q4 2009. Today, using a single Carbon code base, you can use the same app on-premise, on private or public cloud using WSO2 platform.

In addition to cloud native aspects, there are many other enhancements on the platform, done over the past three years. P2 based dynamic provisioning, advanced governance capabilities, dynamic discovery, platform wide cashing, clustering, auto-scaling, advanced deployment synchronization, and Eclipse based tooling are just few of those advancements.

It took loads of team work, loads of hard work to build this unprecedented platform ground up. But all those hard work has paid off already, as you can see from the progress WSO2 has made in the past three years. And what is lined up for 2012 by WSO2, will still prove the power of this software masterpiece.

Stay tuned…!

 

Technorati Tags: WSO2,Open Source Software

Meeting Application Development Challenges in Today’s Environment with JavaScript

Application development is a well known phenomena in computing today. Patterns, best practices, techniques and tips & tricks have been evolved over many decades. Yet, have we hit the sweet spot, yet?

Demand to deliver quality apps sooner, and keep them evolving every days is a norm today. Agile models promises to meet these demands. But the technologies for developing apps still are in question. For example, ease of development, faster to test, debug & fix are must, to deal with demands.

If you take the whole application development spectrum, including development, testing, as well as maintenance efforts, the choses available are limited, and often not ideal.

Programming language becomes a key to meet these expectations. Programing expertise and the ability to find programmers who can deal with the complexities involved is a major problem today. For example, not very many business software are being developed in C programming language. Even the available few are being migrated aggressively into languages like Java. Even though Java is simpler compared to C, is it agile enough or simple enough to develop apps at the rate the markets demand?

If you look around the Web today, vast majority of apps are Web based, and few are using Java technologies like JSP. The rise of scripting has won over and languages like PHP or Python, which are interpreted and easier to develop and test are dominating the space. These languages are used for MVC style, DB driven three tier apps and even for distributed EAI style apps. Simplicity with REST style integrations for enterprise apps have made the scripting languages the de-facto choice. So you no longer need “complex” languages like Java any more.

What is more interesting is the fact that, the use of JavaScript, as the client side language in the Web today to do magic on the browser. And people have used JavaScript, for back-end logic, in addition to use it only for client side logic. Rather than using two languages, one for server side scripting and another for client side logic, what if we use the same language? In other words, rather than using PHP + JavaScript for the application, we can use JavaScript + JavaScript, or just JavaScript.

The advantages of using just JavaScript for both front-end and back-end logic multi-fold:

• Easier to develop, test & debug
• Faster to develop & time to market
• Easier to find skills to deal with JavaScript, wider developer community compared to Java, and even compared to PHP
• Simple EAI with REST style, both consume REST & build REST style services
• If needed, SOAP & WS-* is not impossible
• Best of OO principles still can be leveraged using JavaScript
• Leverage  lightweight data-interchange formats such as JSON

Like the rise of the Web and use of HTTP + HTML influenced distributed computing technologies such as SOAP, the power of JavaScript today can lead to a whole new era of application development that are better suited to meet enterprise application development challenges.

 

Technorati Tags: JavaScript,Application Development,Jaggery