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.
2 comments:
They will be much less expensive than traditional services and your start-up costs will be next to nil since everything is done through a virtual environment. Second, you must always be particular to check all the charges on your statement for any hidden or unexpected charges. When you pick up, all you will hear is a machine screeching! Such a fax number mix up can give you a headache, unless you find out the owner of the fax number and clear up the matter with him.
They will be much less expensive than traditional services and your start-up costs will be next to nil since everything is done through a virtual environment. Second, you must always be particular to check all the charges on your statement for any hidden or unexpected charges. When you pick up, all you will hear is a machine screeching! Such a fax number mix up can give you a headache, unless you find out the owner of the fax number and clear up the matter with him.
Post a Comment