I've been wanting to swtich from web hosting to a VPS hosting but cost was always an issue. Well, these days, VPS hosting is pretty cheap and it seems it averages around $50 dollars to entry point level (typically 256MB memory with 5GB diskspace and several hundred data transfer per month).
Web hosting is so cheap (I was paying about $10/m) so I wan't sure if it is worth moving to VPS hosting. Then I found this service at VPSLAND.COM (I don't work for them) which offer the bare minimum option at $20/m. It comes with 256MB and 5GB disk with 100GB monthly transfer. Another attractive thing about this provider was their "incremental" upgrade options. Other places had coarse upgrade increments: in order to move to the next grade, you go up to $80 bucks or sometimes over $100. VPSLAND gives half-dozen steps with $5 dollar increments. My plan is to start with the bare minimum, and then gradually step up according to the actual pain I experience. That makes more economical sense.
I signed up for VSPLAND last night at 10PM, and rigth now (at 11AM next day) I received all information I needed to migrate to the their hosting environmenet. I just had a successfull initial "hello" test using index.htm (using IP, not domain name yet)
For the existing web hosting service, I just had a live chat with a sale rep and he canceled it for me. It was a good provider for web hosting. They just didn't have a VSP hosting option that I was looking for.
The new provider sent me DNS nameserver information. My registar is domainbank, so I went there and updated two NDS nameserver info.
Next, DNSLAND sent me IP and login instruction. I started RemoteDesktop and logged in successfully. Great to be able to log into my own server. Now I can do all kinds of fun stuff on this server.
RemoteDesktop experience is slow, but acceptable. Considering it only has 256MB of dedicated memory, it was not completely unusable. All IIS related services were stopped, so I created a dummy default website folder, and had IIS Default Web to point to it. Then I put a test file there. Accessing from outside worked. Good.
The next thing was to put an ASP.NET page. I then realized that it only had .NET 1.1 Framework. That wont fly. I need 2.0 environment.
I haven't migrated to Visual Studio 2008 yet, but plan to do so soon at work. I also need a Visual Studio but can't afford a developer edition, so decided to go with Express edition.
Downloading Visual Web Developer 2008 Express Edition took me a while... Why Microsoft makes simple download experience so complicated? I just need a file downloaded and start runing it. It was partly due to the additional security measures in Windows 2003 Server and IE 7. You just have to configure it right to get it passed (but without completely negating the usefulness of these security features).
I thought about installing Visual C# but I decided to wait. I will start with Web Developer, keeping all business logic in App_Code folder for now (I now it is not the best practice).
.NET framework 2.0, 3.5, Visual Web Developer, and SQL 2005 Express will take up 1.5 GB of disk space. I have only 5GB so I need to be conservative. If I want more, then I need to move to a option which is at $30/m. The one at $25 does not give me more diskspace, but doubles the memory.
By the way, VSPLAND didn't charge any setup fee, which is good thing too.
I will post any positive/negative experience with this new hosting provider, but for now, it tooks great.
12/24/07
12/18/07
Tips for buidling SaaS (Software as a Service)
After building a SaaS solution, I found out about few rules that I should follow when I am engaged with another SaaS.
This was the first mistake I made. I create a model website, I set up a framework to create a clone of the model for each customer organization, with some configuration changes applied to each clone (or instance). Actually, when I designed this, the company was going to sell the product as a premise-based software. So by nature, it had to use "cloning" model.
Then, the company changed the direction and it decided to go to "SaaS" model, but we never made architectural adjustment to the product. It remained premise-based, and deployed in SaaS way.
One problem with cloning model is lack of scalability: cloning requires resources as we add more and you will quickly run out of resources like CPU, memory, and network bandwidth. The other problem is maintainance. It is a nightmare for operation stuff to apply patches, for instance, because therea are so many instances to make modifictions to.
Cloning also prevents us from using any sort of load-balancing strategies, which hurts performance.
Another big mistake was to use "in-proc" session state. First, session state should be avoided if possible and use alternative techniques like cookies. If your system has to support session state , then use session state server or SQL database session state server from day 1.
This forces developers to make any object stored in the session state collection serializable. Making an object serializable is relatively easy step (just declared [Serializable()] attribute at type level) but it helps developer realize that session objects are serialized and deserialized and sent accross a wire to a persistent storage. It, usually, makes developers careful about exessive use of session state facility.
"in-proc" session state has serious scalability issues too. The state information is store in a process memory, so any subsequent request must be serviced by the same process, which creates process affinity. This means you won't be able to set up effective load-balancing scheme. It also hurts reliability: because session state is in memory and if process dies, all session state disappear.
It is tempting to build a separate administartion application in a form of WinForm or a separate ASP.NET application. In a way, it clearly draws a line between the product and a supporting system.
However, introducing additional application to the whole picture causes more administrative headaches: operations stuff need to learn about another application. You would also end up duplicating many logics. For example, you need a separate security scheme, need a duplicate business logic and data access layer hiting the same database. If assemblies are shared, then it is less problematic, but if you write a separte code to hit the same database, then that makes changing database more difficult because two clients need to be updated.
Instead of creating a separate application, create another set of Actors like Admin, Ops, and Support. And then build a role-based security around the system and scope the capabilities around roles. That way, wheather you are an admin or end-user, you are subject to the same security infrastructure, and you can easily move around capabilities among Actors.
One of the most complex sub-system is the security sub-system that authenticates users. Every SaaS application out there has to have one. It is the most time-consuming sub-system and it has almost zero value to your SaaS offering. So, why waste time and money on it.
You split Security into Authentication and Authorization. You use Single Sign-on (SSO) to solve the Authentication and you build your own Authorization infrastructure. Often Authorization involves business objects and there is no choice but implement it yourself. On the other hand, authentication is pure infrastructure feature. I would recommend using Windows Live ID, Yahoo! ID, OpenID, etc. You could also implement Federation protocols like WS-Federation and SAML 2.0.
The time it takes for you to figure out Windows Live ID and Yahoo! ID is much shorter than the time it takes for you to build login system (with remember password, change password, secret question/answer, and all these crap) and test it.
Build a single website for all customers
This was the first mistake I made. I create a model website, I set up a framework to create a clone of the model for each customer organization, with some configuration changes applied to each clone (or instance). Actually, when I designed this, the company was going to sell the product as a premise-based software. So by nature, it had to use "cloning" model.
Then, the company changed the direction and it decided to go to "SaaS" model, but we never made architectural adjustment to the product. It remained premise-based, and deployed in SaaS way.
One problem with cloning model is lack of scalability: cloning requires resources as we add more and you will quickly run out of resources like CPU, memory, and network bandwidth. The other problem is maintainance. It is a nightmare for operation stuff to apply patches, for instance, because therea are so many instances to make modifictions to.
Cloning also prevents us from using any sort of load-balancing strategies, which hurts performance.
Enable ASP.NET session state server from Day 1
Another big mistake was to use "in-proc" session state. First, session state should be avoided if possible and use alternative techniques like cookies. If your system has to support session state , then use session state server or SQL database session state server from day 1.
This forces developers to make any object stored in the session state collection serializable. Making an object serializable is relatively easy step (just declared [Serializable()] attribute at type level) but it helps developer realize that session objects are serialized and deserialized and sent accross a wire to a persistent storage. It, usually, makes developers careful about exessive use of session state facility.
"in-proc" session state has serious scalability issues too. The state information is store in a process memory, so any subsequent request must be serviced by the same process, which creates process affinity. This means you won't be able to set up effective load-balancing scheme. It also hurts reliability: because session state is in memory and if process dies, all session state disappear.
Don't build separate Admin application
It is tempting to build a separate administartion application in a form of WinForm or a separate ASP.NET application. In a way, it clearly draws a line between the product and a supporting system.
However, introducing additional application to the whole picture causes more administrative headaches: operations stuff need to learn about another application. You would also end up duplicating many logics. For example, you need a separate security scheme, need a duplicate business logic and data access layer hiting the same database. If assemblies are shared, then it is less problematic, but if you write a separte code to hit the same database, then that makes changing database more difficult because two clients need to be updated.
Instead of creating a separate application, create another set of Actors like Admin, Ops, and Support. And then build a role-based security around the system and scope the capabilities around roles. That way, wheather you are an admin or end-user, you are subject to the same security infrastructure, and you can easily move around capabilities among Actors.
Use Single Sign-On instead of your own Identity server
One of the most complex sub-system is the security sub-system that authenticates users. Every SaaS application out there has to have one. It is the most time-consuming sub-system and it has almost zero value to your SaaS offering. So, why waste time and money on it.
You split Security into Authentication and Authorization. You use Single Sign-on (SSO) to solve the Authentication and you build your own Authorization infrastructure. Often Authorization involves business objects and there is no choice but implement it yourself. On the other hand, authentication is pure infrastructure feature. I would recommend using Windows Live ID, Yahoo! ID, OpenID, etc. You could also implement Federation protocols like WS-Federation and SAML 2.0.
The time it takes for you to figure out Windows Live ID and Yahoo! ID is much shorter than the time it takes for you to build login system (with remember password, change password, secret question/answer, and all these crap) and test it.
Subscribe to:
Posts (Atom)
