Random Ramblings About Making Games and Stuff from Cloud

Posts tagged ‘Monitoring’

SQL Azure monitoring with Cotega

I just started to use this SQL Azure and SQL Server Monitoring tool http://www.cotega.com/ and I must say that it is exactly what I was looking for in a easy to use monitoring tool. I don’t need to be complex, feature rich and massive monitoring tool. I only need a alert when database is not accessible, if performance seems to be below average or there is a spike in the usage. Service is stil in beta but it looks really promising.

Just click "add SQL Azure database"

Setting up the database connection was easy. After login you are presented with Dashboard view. Just click “add SQL Azure database and fill in the database address, username and password to the popup. Finally press “Add database button”.

Fill in the address and login details.

You can add notifications to you databases by going to Notifications view and pressing “Create Notification” button.

To add new notification just press "Create Notification"

Just fill the name of the notification, select monitoring rule from “select what you want to monitor”, database and the polling frequency.

Fill in the details and select monitoring target.

After you have selected monitoring target you can select when to create a notification. In this case I have selected “when connection fails”. After this you can fill in a email address and even select a stored procedure to be run. But with connection fails case that does not make sense :). Finally press “Add Notification”.

Add email address and select stored procedure if you need one

There you go. Just start waiting those notifications to kick in.
There is a nice feature in the notifications: When you start to receive lots of them for example conserning “connection fails” you can temporarily disable the notification directly from the notification.

When you get many same type of Notifications you have option to disable the Notification directly from the email.

You can check the logs for specific notification to make sure that rule works.

You can see how rules are being evaluated.

Also you can view this info in a report view for performance ananlysis purposes.

Its easier to spot performance problems from visualized reports.

Very potential neat litle monitoring tool for those who don’t need complex solution for simple problem!

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.

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.

I have my app in the Azure. Now what?

So you have your application running on Azure. Some next steps would be beneficial to have. Well maybe, but you need to first figure out answers to a couple of important things.

  • Backup
  • Monitoring
  • Autoscaling

As of now Azure does not provide any solutions of the shelf. You need to build those by yourself. I will describe one possible setup that will provide you some functionality for the points listed above. Being a Cloud Man that I am, this setup is also running entirely on the Cloud 🙂

Setup

Firstly, the setup. In order to get things up and running you will need the following tools and accounts:

  • Amazon EC2 account with Windows 2008 and Amazon monitoring service.
  • Windows 2008 server (with SQL Server 2008 R2 client utilities) for Azure backup.
  • SQL 2008 RC2 server for Azure SQL backup.
  • Azure Management Cmdlets tools for Azure Storage backup.
  • Red-Gate SQL Comparison Bundle version 9 or above for Azure SQL backup.
  • AzureWatch account for Autoscaling and monitoring Azure web and worker roles.
  • (Optionally) Dropbox with Packrat service so you will get unlimited undo history on your backups.

The overall picture of this setup will look something like in the picture below. You could replace Amazon EC2 Windows 2008 server + SQL 2008 RC2 with Azure VM role, or your own hosted server and Dropbox with Azure storage account. By replacing Amazon with Azure WM role you will gain savings on the data transfer fees and the steps should be fairly similar. If you decide to do that I would recommend having those under different Azure subscription so that one Administrator cannot delete your backups and your service!

Azure setup

High level picture of monitored Azure app with backup and autoscale.

In addition, make sure that Windows 2008 Server has at least SQL Server 2008 R2 installed especially bcp.exe version 10.50.1600.1. That is because bcp.exe utility is used to perform database backups and older versions had nasty bug that prevented backup from working.

If you have several services running on one Azure subscription it is useful to direct their logs into one shared storage account. This is because AzureWatch can monitor only one log account per subscription.

Installation instructions

I don’t go to all the details because steps those are quite obvious. If you get confused with my quick instructions, please send me an email and I will add more details into this blog post.

  1. Get Amazon account and launch Windows 2008 server with SQL 2008 RC2 server or Make VM role for Azure.
  2. Install SQL Server 2008 R2 client utilities
  3. Install Dropbox
  4. Install Azure Management Cmdlets
  5. Install Red-Gate SQL Comparison Bundle
  6. Get AzureWatch account and install the control panel to 2008 server.

Scripts

You should also automate running of these PowerShell scripts with Windows 2008 Server Scheduler:

  • Remember that you need to give full path to PowerShell script in Task arguments like this:

-noninteractive -nologo -command “&”c:\my backup scripts\backup.ps1″”

  • Modify SQL backup script from Mike Mooneys blog to suite your needs. Make sure that zip files are stored in folder that is Dropbox synchronized.
  • Modify backup sample scripts of Azure Management Cmdlets to suite your needs. Samples can be found from installation folder. You can direct backup to Azure storage account or to Dropbox folder.

That’s it!

Happy Clouding!
%d bloggers like this: