Random Ramblings About Making Games and Stuff from Cloud

Posts tagged ‘cloud services’

A Lot of Talk About Vendor Lock-in

Still free or did you lock yourself already?

I wrote this post originally to my company blog.

In the press and in many online forums there’s a lively discussion about so-called vendor lock-in, a discussion about customers facing a situation where it is very difficult to replace the existing product with a new one, or the replacement costs are prohibitively high.

Indeed, vendor lock-in deserves your attention, it is good to stop and think before making software purchasing decisions. Let me list some common questions that may come into your mind:

  • What if it is very difficult or impossible to get my own data out of the system?
  • What should I do in case where my software provider drastically raises the license fees?
  • What if my present provider stops supporting the product I’ve bought when a new version of it is coming to the market?
  • What if I’ll find that another provider offers much nicer and suitable solution for me, and I wish to export all my data into a new one instead?
  • What if I am forced to take the new version of the present solution into use, will it support our good old way of doing things – or must the entire organization AGAIN learn to use a new system?
  • Must I once again survive a long and laborious implementation project?
  • Do I make myself a ‘hostage’ by taking this software in use?
  • What if the terms of use of a software component become indefensible and must we migrate from one software to another?

All these above-mentioned points lead to somewhat unpleasant situation. And no one seems to have solution to it. Googling (or binging) the notion ‘vendor lock-in’ does not bring up any solutions; only fears, threats, and horror stories. Vendor lock-in questions and fears have recently been rising into discussions thanks to the strong presence of various SaaS solutions and cloud computing technologies.

However the fact is that vendor-lock in can’t be entirely avoided, it always occurs – to some extent.I mean always. Both with Cloud/SaaS and with in-house software. But there’s a difference between these deployment methods.

The data of the on-premise and in-house software exists on your own servers and databases. In a way, it can feel safe, but the truth is that very often this data is unusable without the (internal) consulting project in which IT professionals are transferring, converting, and creating data for the next system. As you might guess, after that kind of approach it is common that a rather heavy implementation project starts; installations, testing teams, training sessions, and eventual renewal of business processes.

All this resulting in a situation where the end result can be admired after 8 months project…and having an effect on the company results after a year! Way too slow.  And oops, did the business environment change during that time?

I dare also to claim that on-premise software is most often chosen without 100% knowledge of the data portability. In case that is checked out, is it often done by asking the vendor sales person “And the data can be easily imported?” Of course the answer is ‘yes’ accompanied with lots of reassuring in form of head nodding, and no one really checks that up in practice – before it’s too late to react on that.

SaaS services and most of the cloud providers do not require any technical installations; hence the implementation project is much slimmer. The ‘worst’ workload might occur with the training part.  However the best SaaS solutions are so simple to use that a massive training program is often not needed.

I’d say it is quite rude to frighten up customers by speaking ill of the vendor lock-in with SaaS and cloud computing providers, if one offers on-premise software as a solution. There is a risk that you have locked in much more, as part of your IT infrastructure, process development, versions of your desktop clients and even operating systems become dependent to the on-premise software. The license prices of a ‘normal’ software could easily bounce up, as of any vendors.  Just ask one ERP client 🙂

The vendor lock-in of the SaaS vendors is at its highest only as deep as with a ‘normal’ software. But most often less deeper and less risky, I claim.

If you want to minimize your vendor lock-in, it is not about whether you take an in-house, on-premise or SaaS product, but about which SaaS product you choose.

Before headlong SaaS decision you should at least browse through the below-mentioned articles. These might help you to better understand your options.

When you’re in the cloud, you’re ordering a cup of coffee, not the coffee maker.

In English:


In Finnish:




Why SLA does not make sense in the Cloud?

What do you really want to accomplish with Service Level Agreement (SLA)? To punish or to get the best support available, as soon as possible? With the traditional on premise software if there is a problem you are pretty much all alone with it.The time and the money between binary hitting the fan and fan being fixed is solely coming from your pocket. In the traditional on-premise or dedicated server software environment SLA makes sense. You need to have some leverage and certainty that your software provider is at least mildly interested in fixing your problem.

When “Cloud Computing” is hit with speed bumps the whole Internet is holding its breath. Latest example being Amazon incident on April 21 2011. If SaaS service is not up and running SaaS firm is losing lot of money and very fast. Most of the SaaS firms have monthly recurring revenue model and customers can cancel subscription within one month notice. This means that customers can vote with their wallet. So you can be sure that a SaaS firm gives its fullest attention in order to get their SaaS service up and running as soon as possible. If your provider has fully Clouded its technology (so-called multitenancy), your application instance will be fixed as soon as service is fixed. No one is getting special treatment. Not good or bad. So there is no need to be fearful about your account is not running while others are.

Storm, calm or no cloud? You have no idea.

You should be able to see if your Cloud is in a storm or calm.

With a proper SLA the damages and indemnification are somehow fixed to the amount of money you pay for the software, services included. With SaaS firms your monthly – and even yearly fees – are quite small amount of money and so are the potential liquidated damages. This means that, for example, 10% indemnification of the subscription value is merely a nominal sum. For example, if a SaaS service would cost you 59$ yearly subscription it would entitle you 50 cent compensation for one month downtime. And before you try to negotiate higher indemnification, talk to you own lawyer and ask if you should sign a contract that has liquidated damages clause over 100% of contract value. Next imagine you are asking for it from SaaS firm? And guess the response. My point is that there is no realistic way to imagine a SLA between you and SaaS provider that would have real monetary indemnification. The real penalty for a SaaS provider is in the form of loss of income, increased churn, and negative publicity. Any serious SaaS procvider will do everything to avoid this.

All is well in the cloud

Seek for transparency instead of indemnification.

What I am trying to say is that instead of asking what SLA levels you receive and what kind of compensation is possible, ask what your SaaS provider is doing to minimize the downtime. It does not make sense to try to get SLA agreement as tight as possible. It makes more sense to make sure that provider is “all in” with the cloud. If service you are using truly has significant monetary value for you provider it will make sure that it will run as smoothly as humanly possible.

Make them prove that they know what they are doing, but not with a SLA. Ask about security, availability, recovery and how you can monitor uptime. For example Azure (Service Dashboard) , AzureWatch and Sopima Oy provide RSS feeds to its customers to give transparency of its service levels.

Focus on finding the signs of preemption, transparency and security – instead of indemnification in the SLA.

PS. If you want to know that 10 questions you should ask from your SaaS vendor and what are the correct answers go here.

Why Cloud Services are bought behind IT’s back?

A cloud worker in his thoughts, yes, that's me thinking about the shadow IT.

I wrote this post originally to my company blog.

A common situation today is that the business units are purchasing SaaS services, secretly without knowledge and/or acceptance of the IT department. The reasons for are many, but at least that they:

  1. do not believe that IT will give them a permission to order the service,
  2. are afraid of that IT will offer some custom-tweaked Intranet setup,
  3. will get “similar” but inferior service, eventually when IT gets time to do it.

How did we reach this point?

I would say that lack of understanding and the illusion of total control are to blame. Similar findings can be found on a recent publication of University of Turku, SaaS Handbook, consultant company Sulava’s Marco Mäkinen’n video about the shadow IT, and in an article in Tietoviikko (the leading Finnish IT professional paper). I’m sorry that previous references are all in Finnish so you just have to take my word for it or use Google translator 🙂

I’ve been thinking this issue a while and my opinion is that the biggest problems are following:

Firstly, IT says “No” because it does not understand the business problem at hands or the benefits that the chosen SaaS solution would offer. As IT professional myself, I too used to start with listing problems and risks whenever a new service was presented to me. I did not believe that the solution would solve the issue because I just simply did not understood how much this would actually help the business units. Ok, I did some soul-searching and found a reason for My Inner Problem Troll. I have had such a bad experience with implementation of new software services: sales cycle is long, price is high, laborious server procurement and installation, mandatory customization and integration projects, bad end-user training experience, and poor usability. And very often after the software implementation project nobody wants to actually use the product – and everybody is feeling sick and tired of it. These experiences lead further to the problem number two.

With an engineer style, we often tend to overdo things and aim for perfection and making everything ready at once. Very typical at least in Finland, Nokialand. The new service must be fully integrated to other systems, the information must not be in silos in the different systems, the service must perfectly adapt to our processes (how outdated they ever are…), and on top of that it must adapt to changing business needs, and finally, the implementation must happen to all personnel at once. Phew. Everything has to be one complete solution.

When the chosen service is finally in production, the business need may have changed and therefore nobody wants to use the service. Summarized; all the integrations, customizations and implementation took too much time and way too much money.

The price of the traditional software product will easily lead to the problem number three.

Does this sound familiar? Because the purchased product was expensive and the implementation was painful, you desperately want to use the licenses and servers for almost any problem you encounter – even if there are better (and less expensive) solutions available. In other works, it is easy to end up trying to save money by using one single product to solve the various needs.

I dare to argue that by doing this way you will end up saving money from the wrong end. As an example: how many of you organize events by email and Excel sheets? Did you know that there are alternatives? If you count the hours you use for excel work and emails and compare this to services like Lyyti (this is a Finnish service) we don’t need to be a Nobel awarded mathematician to understand a) the cost savings and b) increased value to the event participants.

How did we end up here?

The need to control everything, futile (and expensive) perfectionism, fanatic avoidance of data silos and emphasis on the potential risks instead of the benefits have led to a situation, where SaaS services are purchased without the acceptance of the IT management.

So what can we do about it? A lot! The solution is not to add more technology or interfaces.

Software production companies have already accepted that agile development and early trials are the way to get a product that is good enough for the actual business needs and the schedule. So why would IT department want to act in a way that is suspiciously similar to the waterfall method? I would highly recommend added agility and demo mentality are also tested in the IT departments – SaaS services are very easy to test and experiment!

If a SaaS product does not meet your needs, it is really easy to skip it and test another one. The testing of new services costs way less than you think and it gives you possibilities to react to actual business problems – and not only to the problems that you can afford, have time to solve or know how to fix!

Researcher Antero Järvi from University of Turku said this to me when I asked about how to integrate SaaS services to the rest of the applications: “Don’t integrate anything before you use the service for a while and evaluate if you even want to continue to use the service.”

Clouding IKEA Style! Design the Price Tag First.

We developers, and an industry, should start to rethink how we start designing our Cloud Services. The customer centric design is old news. SaaS entrepreneur Rainer Stropek, whom I met in Berlin, said wisely: “Do pricing like IKEA! First design the price tag.”

The decision to purchase your service should be almost subconscious for the customer.

While working in my startup Sopima I have learned that there are three reasons for this. I will discuss these findings in TechDays 2011 so please come and listen – you can also ask me questions, for example via Twitter: tweet your questions and comments to me in advance @anttimakkonen and I’ll try to answer you. But now let’s go back to business. Read on how to make the price tag your first priority.

Reason number 1

You will not win your battle for customers by being the nicest and prettiest service of its kind in the minds of the Internet dwellers. Because of Cloud Services like Amazon (IaaS) and Windows Azure (PaaS) there’s more competition on your way and with a speed you are not accustomed to. It is really easy to put up a service once you bypass the initial learning curve of any Cloud provider. Most of the problems you will face when building your service are not technical. Customers are not interested in what technical solutions you have mastered. They want a polished service experience that does the basic stuff extremely well.

Reason number 2

The decision to purchase your service should be almost subconscious for the customer. Customers that are lured into the web page of your service need to understand what the service is and what the cost is, in a short time before they leave the page. Otherwise you just paid for a lead that is not going to transform to a customer.

In software design this means that you need to design the billing of your product in a way that the customer understands what he or she is getting. For example, do not make him pay for upload/download bandwidth but instead the total size of stored files per month. Keep rates simple not complex. You need to work a little extra to calculate what a customer normally needs. Do not force customers do that calculation. In addition, customers do not like surprises in their bills. Lots of SaaS entrepreneurs prefer to sell prepaid credits or similar to get commitment, and some money fast. In my experience it is easier to purchase “packets”, but don’t overdo the number of options. Calculating costs and prices takes us further to the next reason.

Reason number 3

Computing resources and scalability are no longer major investment decisions. You just order what computing resources you need and you can easily cancel that order when you are done with it. Basically you can run as bad code in the cloud as you wallet can stand and your service will still scale. 🙂

In the age of Cloud Computing you need to direct your attention to what cloud service provider is charging you and minimize that cost. After you have made your service stateless, the cost is the only limitation to scale your service up. You need to optimize and monitor your cost structure – and sometimes even make ‘strange’ design decisions, if that helps you to pull your Cloud costs down. This is even more important if your service revenue streams are dispersed and the profit margins are lean.

As a final thought I’d like to say

Consider billing as an integral part of your service. Do not make customer reconsider his purchase on every obscure bill you send. Especially if you are making a subscription service, do not implement your own billing! Trust the professionals and consider using some of the readymade services like these:

PS. I found these tools that will help you on estimating, monitoring and minimizing Azure costs.

%d bloggers like this: