Management, Technology, Strategy

The biggest challenge for “traditional” software vendors moving to a SaaS model is not technical

Image Credit:

Cloud Computing is probably the longest surviving buzzword in the IT industry for the past decade or more. From a software buyer’s point of view the important decision of going for a “Cloud Solution”  is based on economics, more specifically the CapEx vs. OpEx trade-off. The pay-as-you-go nature of cloud computing is perhaps the most important economic feature for customers.

Cloud computing has three well known service models  IaaS, Paas and SaaS. Out of these, Software as-a Service (SaaS) is perhaps the most convenient model of acquiring IT for operating a business.  The huge success of enterprise SaaS vendors such as Salesforce and more recently Workday is evidence that many enterprise customers are moving towards SaaS for software “procurement”.

These new kids on the block have prompted the “brick and mortar” software vendors that follow the old model of building software, burning it on a CD and shipping it to their customers for on-premise installation to follow suit. These vendors are now making their software more architecturally and technically cloud friendly. What this usually means is that the software is now runnable on cloud infrastructure (IaaS) like Amazon AWS or Microsoft Azure.

Now building software that is more cloud friendly is one thing, but actually moving towards a true pay-as-you-go SaaS delivery model is a whole new ballgame for the traditional vendors.

I think the biggest challenge for existing non-SaaS vendors is not technical but its rather about overhauling their business/financial model. When moving to SaaS, the customers who used to pay all the license fees upfront will now be using a subscription payment model. This means the financials (such as cash flow) of the company need to be looked at from a different angle. It may also affect how sales and marketing approach their roles since customer LTV (Life Time Value) is now a bigger concern.

Possible ways to overcome this challenge would be to partner with (or even merge/acquire) another cloud company and piggyback on their business model for SaaS delivery. But when choosing a cloud partner it would probably be a good thing to avoid another SaaS provider and instead select an IaaS or PaaS provider to avoid market share erosion due to conflicting products.

Another way to address this challenge would be to setup a separate business unit for the cloud SaaS business. This would enable all new customers to be directly part of the SaaS business unit while existing customers are gradually migrated.

Architecture, General

Architects are trade-off evaluators

Most software problems have a finite set of solutions to choose from. An important role of an architect is to understand the trade-offs of each solution and decide on the best solution for the given business case.

Image credit:

For example, one solution to a given problem could be less performant but may result in a clean and maintainable codebase. The job of the software architect in this situation would be to determine whether performance or maintainability is the most important aspect for the problem at hand. The compromise reached should always be in the best interest of the software product.

It is important to document the reason for picking a particular solution along with it’s trade-offs for future reference. Software people are notoriously forgetful of their design decisions after a few days 🙂

As the saying goes, there are are many ways to skin a cat, the architect should find the best way to do it given the resources while achieving the end goal.

General, Management

Product Passion

The most amazing thing to me about this video is not the awesome rocket technology or the brilliance of Elon Musk but the crazy passion shown by the SpaceX employees (including Musk) towards the success of the PRODUCT!

Product passion is a result of product focus. You don’t have to be Musk or SpaceX to have crazy passion for your product, you just need the culture and mindset from top to bottom.
Finally product passion fuels employee engagement and then everything else becomes secondary!
General, Subversion, Technology, Version Control Systems

Subversion Revert with Externals

Disclaimer: I know Git rocks, but people still use Subversion 🙂 !

Let’s say you have a Subversion checkout containing externals. Now you’ve made changes in many places within the folder structure and you want to get back to the original clean state.

So your typical approach would be to go to the top directory of the working copy and do a recursive revert using:

svn revert -R .

But unfortunately nothing happens! The reason is that the working copy is made up of sub folders containing externals and in order to revert them you need to go into each sub directory and then issue the svn revert command. This can be cumbersome if you have a working copy containing many subfolders corresponding to externals.

Well the solution is pretty simple if you have a bash shell (Windows users will require Cygwin or something similar)

for d in ./*/ ; do (cd "$d" && svn revert -R .); done

This little bash script will change (cd) into all sub folders using a loop and execute an svn revert within each ‘external’ folder recursively.

The solution was inspired by this thread on StackExchange.

Cloud, DevOps, General, Technology

How To Move your large VirtualBox VM disk created by Docker

So you’ve been using Docker Tool Box (DTB) on Windows and the ‘default’ docker host created by docker-machine is growing alarmingly large on your limited C: drive.

The super large disk.vmdk file for the “default” VM created by DTB is usually located at C:\Users\[username]\.docker\machine\machines\default

Now you want to move the existing disk.vmdk file to your much larger D: drive without having to recreate a docker machine/host from scratch and pulling all images on to it again.

The important thing to note here is that the vmdisk is an implementation detail of VirtualBox (VBox) not Docker. docker-machine just uses VBox as a provider to create a Docker host.

Therefore if you need to move the VM disk file to another location you should change VBox configuration for the VM instead of changing any Docker machine configurations (or using any docker commands)

So here  are the steps you need to follow.

1. Stop the running docker machine (i.e. VBox VM) like so:

                   docker-machine stop  

Note: This will effectively power off the VBox VM, named ‘default’. You can check this by opening the VBox GUI.


2. Copy the disk.vmdk file from C:\Users\[username]\.docker\machine\machines\default to a suitable folder in your bigger D: drive. I created D:\docker-machines\default for this.

Now the interesting part 🙂 We need to tell VBox about the new location of the disk.vmdk file.

3. The default.vbox file located at C:\Users\[username]\.docker\machine\machines\default\default  specifies the path to the vmdk file. This vbox file is an XML file, so just open it up in any editor and set the Machine/MediaRegistry/HardDisks/HardDisk/location attribute to the new location on your D: drive.


Note: Don’t worry about the “DO NOT EDIT THIS FILE..” statement on top since you have already stopped the VM, the file will not be overwritten. And I found this method easier than using the GUI 🙂

4. Now power up the docker machine using:

                docker-machine start

If the ‘default’ machine start without any problem then you are good to go!

Now check if all your images are still available using:

docker images

5.  You can verify that the vmdk file on D: is being used by firing up VBox and selecting the “default” VM and clicking on Settings/Storage/disk.vmdk as shown below.


6. Now you are done! Just go ahead and delete the huge disk.vmdk from your C: drive located at  C:\Users\[username]\.docker\machine\machines\default

Design Patterns, Java, Maven, Uncategorized

Missing ServiceProviders after Shading

Shading is a technique used in Maven to create a single”Uber” jar by merging the contents of  your app jar and all of it’s dependent jars. This makes it easier when distributing your application since there is only one big jar to deal with.

The Java Service Provider pattern is a cool way of building loosely coupled extensible applications.

When building a jar containing such implementations a text file per interface should be created listing all of it’s implementations and placed in META-INF/services. This is used by the JVM when the application needs to load (using ServiceLoader class) implementations of a particular interface without explicitly knowing about them.

The problem is when shading multiple jars containing service providers Maven does not merge the contents of META-INF/services by default.

The solution is to use the transformer ServicesResourceTransformer to tell the Shading plugin to merge the contents of META-INF/services in every jar it shades.

This can be specified in the pom.xml as shown below.

<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>

Nginx newbie pitfall #1 (a.k.a. I cannot see my webapp on port 80)

I’ve been playing around with NGINX which claims to kick Apache’s rear-end when it comes to performance. So I installed Nginx on my Ubuntu 14.04 box and accessed the default “Welcome to nginx!” page from my browser. Simple it worked!

Later I wanted to configure my own webapp on port 80. So I did the following.

  1. Create my own coolapp_nginx.conf file typically in /etc/nginx/sites-available with server port 80.
  2. Create symbolic link to above file in /etc/nginx/sites-enabled. (this is the folder actually read by nginx)
  3. Restart nginx service.

Hmmm..but I’m still getting the default “Welcome to nginx!” page? bummer!.

The problem: I forgot to remove the symlink to default config file from /etc/nginx/sites-enabled. Once this link was removed (or the port defined in it was changed to something other than 80), my webapp was picked up.

So the steps if you want to configure your webapp on nginx for port 80 is

  1. Create your own coolapp_nginx.conf file.
  2. Create symbolic link to coolapp_nginx.conf file in /etc/nginx/sites-enabled.
  3. Remove symbolic link /etc/nginx/sites-enabled/default
  4. Restart nginx service.