Clojurians Log v2

What do you guys think? To restate, what challenges are involved with software as a service?

Make it robust

With respect to network effects

Build a great client, that handles retries on timeouts and other network errors. My opinion is that for critical APIs with an asynchronous notification system, the API is not enough.

Actually I'm giving the kind of advices I'd give myself. What kind of service would you propose ?

In my mind, all the problems are marketing. No matter what kind of great bread slicer as a service I make, how could I package it into something someone would pay for? There is probably someone out there with 1/2 the slicer but is a 4x better marketer.

I have trouble selling something to coworkers if they have to go one centimeter outside of their muscle memory.

It's not just about enhancing sales as well as lowering costs and avoiding catastrophic failure I think.

Thank goodness for the various clouds that are now available. If I set up my own business, I imagine most of the hard work would happen on Google's computers.

Good documentation and customer support are also important -- as well as reliability and performance (and scale).

Remote services tend to have a rather strong coupling with the business logic and data at the client's, and when something goes wrong, especially little things here and there accumalting day after day, you transform that speed to market into a greater need for support roles.

When I'm looking at any new SaaS offering, I want an easy-to-find, easy-to-follow tutorial and a free trial (or limited free plan) to evaluate whether the service will be any use to me (or, more likely, my company).

Scale can be tricky. Scaling does not equate the absence of dedicated infrastructure for each client. Have been using a payment API that (I suppose) use a queue-based architecture (e.g. Kafka) that is common to all clients. They ended up implementing a rate limiting system...

I also want a straightforward admin/management console web app so I can see my service usage and any costs at a glance. Depending on how the service is priced (per period, per usage, ...) I also want to be able to easily set up alerts/reminders for when my plan my expire or need topping up. We use service services at work that are credit-based (you buy a number of usage credits and they're valid for a certain period of time or until they run out) -- so we have monitor processes that check periodically and send us an email warning that we're low on time/usage.

> They ended up implementing a rate limiting API... ^ This is an important aspect of implementing SaaS as well, to avoid abuse (or to help your system not get overwhelmed while you're growing!).

Thanks for the helpful input guys. I just accepted a new job, but there is still a tremendous need for the application I developed and maintained at the institution I currently work at (essentially a web portal system that integrates with Dynamics CRM), and I think the plug will just be pulled as soon as I leave. I think I could take what I’ve learned about Dynamics and use previously forbidden tools (Clojure, AWS), and rapidly produce something far better than what we have now, and that would be general enough to appeal to a broader market of Dynamics CRM users; however, upon further consideration, I think I my time would best be spent learning my new job better.

But the input is helpful nonetheless, and I’ll file that away in case I get any inspiration. Thanks @seancorfield, @tristefigure, and @ericcervin.

Have a status/health check page, and automated update scripts. SLA, SLO, whatnot. Status should include any outages instead of only planned maintenance.

(And on the subject of planned maintenance, give email warning well in advance, and the a second one just before maintenance.)

And yeah, producing a piece of software is one thing; turning it into a product is quite another. If all you want to have to maintain is software, you could always open source it and offer to consult on installations/custom modifications.