The rise of the API-based SaaS
blog.chartmogul.com
blog.chartmogul.com
Case in point: Mandrill announced two days ago that they were going to merge their product with MailChimp which included a terms of service change that banned marketing emails from Mandrill after their forced migration date in April. At work we have a commercial real estate app which lets our customers send marketing emails. We had built this functionality on top of mandrill but using a driver based system. Last night I launched a Mailgun driver and we have already started to migrate customers with their own Mandrill accounts to MG. If we hadn't used a driver based system we would be screwed for the next few weeks.
Build your api integrations via drivers. Even if you only have one driver. You will be happy you did later.
Both "driver" and "adapter" as terms for instances of what has gotten labeled the "adapter pattern" were around before the architectural idea of design patterns was applied to software, so its not a new name for it.
Shouldn't you have been using MailChimp all along? Mandrill is for transactional email messages (e.g. password resets, order receipts, etc). Did they ever allow bulk marketing messages through Mandrill?
Mailchimp is much more expensive and our clients wouldn't be using their interface anyway.
I was not happy with Mandrill's decision but can't complain since it was free. I'm moving to amazon email services.
I think case in point, free is not forever in SaaS business.
You'll notice there is an abstract class "Transport.php" which declares certain methods (via the Swift_Transport interface class) that the "MandrillTransport", "MailgunTransport" and the "SesTransport" must all implement.
> I think case in point, free is not forever in SaaS business.
Our account & our customers' accounts were all paid. Some of them send up to 500,000 emails each per month. I would have been fine with them getting rid of the free tier, its the TOS change for marketing emails that killed our use with them.
Now if you moved to SES from Mandrill, you just change it in 1 place. It's not rocket science or voodoo.
Then you don't even change the code, but just configuration.
APIs are great, but I'd say protocols (or at least the well adopted ones) are better.
HTTP-POST can handle the request chain inline, and deliver a single response, the decision tree is much lighter.
For that matter, HTTP-POST can partially to completely defer all processing decision trees, always returning 200 OK, offloading to a queue system that will process the request out of band, and issue the real response errors via a dashboard. Making it lighter still.
SMTP is chatty. Even when you use PIPELINING. It tends to send way more packets than HTTP. And while you can open one connection and send multiple mails through it, the likelihood of your client library doing that is pretty low, sadly.
https://en.wikipedia.org/wiki/Dependency_inversion_principle
If you are paying fees based on "usage", what prevents a bad actor (competitor, hacker, a bug in your own code) from causing you to rack up huge fees?
And if these features are providing critical functionality for your own app or service, it might not be feasible for you to simply "turn it off".
Another key question is whether or not the third-party you are relying on is an actual reliable business partner. Will they get acquired and/or go out of business unexpectedly (a la Parse)? Will they get hacked and create a risk exposure for you that way (PII, PCI, etc.)? What kind of internal controls do they have?
And lastly... how do they integrate with devops? A lot of these tools have web-based administrative consoles that require you to log in and make changes. That sort of thing flies in the face of using tools like chef/puppet/salt/ansible--instead you've got to write detailed release notes that typically a product manager will execute, not an operations person.
I agree that this is a new reality for a lot of companies/developers. But it comes with a lot of risks and issues.
The other thing is just having a common-sense approach. Humans are prone to mistakes, and we are humans too. If you accidentally geocoded 20 million wrong addresses overnight that you didn't mean to, we're just going to waive the usage. Of course this only scales to a certain point, but in most cases it's clear when something like this happens by mistake.
We've also decided to go with the usage-based model, on the contrary it however also makes it easy to make a simple a transparent pricing model.
We still have a UI-based piece with a spreadsheet upload tool, but under the hood it's more or less just a GUI on top of our API.
When building out a new SaaS, I think it should be clear from the beginning whether it lends itself to an API-first approach, especially as a part of target audience research. In our case our primary target audience is developers, and the secondary is data analysts that prefer the GUI-based approach for one-off batches.
[1] http://geocod.io
We run geocodio queries alongside ones to google maps and geocodio results tend to be just as good for 90% of the properties we lookup at a fraction of the cost.
At some point in the past, there was no framework or library, then people distrusted them because REAL engineers knew the ins and outs of their language and knew best how to write the code for performance, then people began to embrace them in general, now there are so many variations picking the 'right' one can lead to paralysis.
The difference with these services as an extension of your codebase is that they cost a not insignificant amount of money. Typically, the frameworks and libraries we are used to cost nothing or a relatively small amount and then you're done writing checks.
Algolia, though a really neat product, would become very expensive very fast if you aren't careful, and I think you're going to find a lifecycle around these that involves using something like Algolia for something relatively hard to do well (search), then you will reach a point where you have to bring it in house or find something else due to cost.
Hopefully the team will have the resources to bring it in house in some fashion, but at some point, these services will not perform well enough for you or be so incredibly expensive that you have to move to something else.
That being said, these services are fantastic for people like me that love to build cool stuff and focus on the hard problem that WE want to solve, instead of all the hard problems in the world that must be solved to solve ours. Raising the chickens and grinding the flour vs. going to the store when baking a cake, etc.
I bring up Algolia because of my positive experience with them, they are a very nice service, quite easy to use, and just a generally pleasant piece of a tough project I had recently.
Exactly. I would outsource whatever the problem is that can be outsourced, in this case search to Algolia until we are far enough along that we can tackle it ourselves.
I don't think there's a real equation for it until you get to the point you can no longer afford it, but at that point you probably waited too long (excepting the cases where you've run into stratospheric growth).
I think as a team you should be looking ahead at growth estimates and making the judgement call to begin working on bringing it in house. Ideally you want the opportunity to run both side by side for a while.
And, honestly, what if you architect it or don't grow enough to make the cost a pain point? As long as the service provider is doing a good job, you could use the opportunity to extend your product into various other directions. Why build search if your focus is on something else and your provider is affordable?
I don't think there will be any major monopolies in the space; I bet smaller aaS companies will start creating wrapper libraries and tools to make their products compatible with the offerings of larger competitors. Customers will be able to switch between services really easily.
It would pose a huge security risk if all companies in the world used the same service to manage all their data. You don't want to put all your eggs in one basket... Especially if you don't have much control over that basket.
I think what will happen over time is that each service will become increasingly specialized. The services which are the most 'composable' with other services will be the most popular.
Being 'standardized/composable' will the one of the most valued attributes of a service; especially since as companies grow, their requirements might change and they might outgrow a specific service.
We're building a product that provides application logging as a service. We have a dead-simple API and library for most major languages that you can drop into any product and start gaining valuable insights into your customers and their data and usage patterns. Our service can also alert you via SMS, Email, HipChat/Slack whenever a log event crosses a user-defined threshold.
We're super proud of what we're building and I'd love to get some people to sign up to our mailing list[0] and give me some early feedback. (Ignore the website, though. It's on my todo list for this weekend.)
In a nodejs project, think of it like having a bunch of calls to console.log() littered all over the place. Then when it's time to go live, I usually run around ripping all those calls out, or your code ends up with a bunch of calls to the logger commented out.
What this system does, and what I've been using it for, is flexibly let you put in calls using a really simple API to the logger and pass whatever kind of data you want. Then, since all the logging is occurring through the API to my service, you can leave all of those calls in your code when you launch or go to production.
The part (to me) that is really sweet is that you can have your app deployed to production and have logging basically turned off. Then, from our web console, select a specific session that you're trying to debug and flip a toggle that turns on more granular logging.
We also have customizable alerts, like I mentioned, so that if you have a critical error, you can have our system send you a text message. This could be super critical for a small business or startup, I think. It's easy to add Twilio and toss that sort of stuff into a new project if you so desire, but honestly I've gotten kind of tired of writing the same thing over and over again. What I'm trying to do is build a system that is flexible enough for power users, but simple enough to quickly drop it into a new project and be up and running.
Then our design allows for multiple projects within an organization, so you can have logging on your website track people through a conversion funnel or something and then have a separate app that tracks usage on your mobile iOS app.
To me, the best part is the simple libraries I've built for a bunch of different languages.
Javascript would be as simple as:
var LogDebug = require('logdebug'); var ld = new LogDebug('API_KEY'); ld.log('Simple log message'); ld.critical('Super important alert!'); ld.log('Simple message with complex data', { something: true });
Then if your next project is C#, you can use the same framework in C#: using LogDebug; LogDebug ld = new LogDebug('API_KEY'); ld.log('Simple log message'); ld.critical('Super important alert!'); ld.log('Simple message with complex data', SomeDictionary_or_List);
It seems really useful to me, so I convinced one of my engineering friends to join me as my CTO and let me try and learn about marketing and sales.
We have a lot of ideas for where we want to go in the future, but for now we're racing to get our MVP out the door with the useful stuff we already have working. Thanks for asking. :)
Now that we have a rising new generation of tools that aim to solve the operations side of things (Docker, Kubernetes, Deis, OpenShift, Mesos, etc.), it'll be interesting to see where things move up in the value chain. I could see a come back to "self hosting" big time if those new tools make it dead easy to "install and forget" your own Mandrill/Clearbit/Contentful/Twilio/etc.
Does anyone have any examples of API-based SaaS companies with a similar challenge?
And shameless plug if anyone wants to check us out. Accepting beta users for our beta launch in early March.
The value that Twilio provides is much more clear to me, than say SalesForce, for example.