Hacker News new | past | comments | ask | show | jobs | submit login
The rise of the API-based SaaS (chartmogul.com)
112 points by awwstn on Feb 26, 2016 | hide | past | web | favorite | 38 comments

The struggle that many people have with API based providers is that they don't abstract that functionality in their application to a driver based system. For something as crucial as mail, payments, sms, etc you absolutely need to build it as if the provider could go away at any point.

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.

Is "driver" the new name for "adapter pattern"?

> Is "driver" the new name for "adapter pattern"?

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.

Adapter is probably a better word for it. Driver just tends to be common nomenclature.

I guess I still just associate "driver" with an INF file that you right-click -> install to make some hardware work in Windows.

Same principal though. You have that driver to connect your internal code (Windows) to a third party service (Some shitty HP printer that you'll want to hit with a bat in 5 minutes).

"which lets our customers send marketing emails."

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?

No. Mandrill allowed for marketing emails as well.

Mailchimp is much more expensive and our clients wouldn't be using their interface anyway.

I am moving away from mandrill for other reasons but luckily I only have to change configuration. We used nodemailer which is node lib abstracting many mail providers, smtp, aws ses, mandrill, sendgrid, etc.

Yeah, that was quite a bait and switch there from mandrill. Very disappointed in them certainly when you consider that mailchimp templates integrated into Mandrill are pretty much purpose-built for marketing emails.

can you elaborate more? show a driver in code? what do you mean by it exactly.

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.

Sure! A great example is the actual code we are using now. We are based on the Laravel framework so here is the driver code laravel uses. https://github.com/laravel/framework/tree/5.2/src/Illuminate...

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.

I think OP is making it more complicated than it really is. Just abstract the logic as much as possible, confining it into 1 place. For instance, just have a class EmailSender with the method "sendEmail", and have all your clients call this class whenever they need to send an email

Now if you moved to SES from Mandrill, you just change it in 1 place. It's not rocket science or voodoo.

Or isn't SMTP the universal driver / adapter in this case? Which all those email providers support as far as I know.

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.

SMTP is also 3-10x slower than a simple POST request though. If you're sending 10,000 emails an hour that adds up.

Why is SMTP slower? You can open a connection, authenticate and then send as many emails as you want. Doesn't seem slower than sending POST requests with their headers and such.

SMTP must maintain a transient state throughout the connection and respond to interactive requests...

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.

The technical answer is it's complicated.

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.

In theory yes, in practice that's usually not the case in my experience.

Thats true. I use abstraction a little further because we have the need for multiple email providers at once. But there is nothing wrong with doing it the way you described.

A key factor that needs to be considered in adopting these tools is how well you can manage your risk exposure to abuse.

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.

At geocodio we do a couple of things to combat this. From day one we've had the ability to create and delete credentials, so It's easy to roll them in case they got accidentally pushed to a public GitHub repository or something like that.

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're in the exact same bucket at geocod.io[1]. I definitely agree with the sentiment that there is less flexibility with pricing on an API-based SaaS.

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

As someone who has a large real estate app at work I can't recommend Geocodio enough.

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.

I see these like frameworks- you don't want to write HTTP request routing code for every single application you build so you pick a framework.

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.

Out of curiosity, how do you weigh the straightforward cost of a service like Algolia vs the full TCO of bringing it in-house?

The way I would view it would be to outsource it until you can afford to hire someone to work on that full time. Search is a bitch. Elasticsearch makes it a bit easier, but if you're a startup and search isn't your primary business it's not a bad idea to outsource it to experts.

> The way I would view it would be to outsource it until you can afford to hire someone to work on that full time.

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 think ultimately, there will be fragmentation in the 'as-a-service' industry. For every type of service will be lots of options for companies to choose from; each with their own specific pros and cons and price points. Each one will optimize for specific workloads or customers of various sizes.

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.

My co-founder and I literally just started a (mostly) API-only SaaS product. I wasn't going to launch our website until this weekend, but it would be a shame to miss this opportunity to capture some email addresses.

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.)


Do you have any comparison? Is it akin to loggly? splunk? rollbar? sumo logic? new relic? Looking forward to seeing the website this weekend, good luck!

It's complicated. Basically, every time I build a new product of any complexity, I end up spending the first week or so cobbling together some sort of logging/debugging framework that I'll use for the entire lifecycle of the project. It ends up being different for each project (I'm a govt contractor, so each of our contracts usually has a completely different tech stack), but the core usually revolves around allowing me to quickly and easily send specific variables and values to some place where I can view them all at the same time.

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. :)

Here's my pet theory. In the early 2000s and earlier, web apps used to be hard to build. No Bootstrap, WordPress, Rails, Django, Laravel, jQuery, etc. A few years later, they became much easier to build but operating them (scaling, backups, availability, etc.) was still a pain in the ass and expensive. This promoted the rise of SaaS.

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.

One one hand you have APIs that help with plumbing like mandrill and twilit. Those you can replace much easier than data APIs like clearbit, moz, etc

How would you describe a API-based SaaS company with a heavy operations factor tied into it? My co founder and I are building the API for personalized gifts and while the software part is clear, literally half of the company is figuring out the physical operations.

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.


I think Twilio separates itself from the others in that it offers a clear, understandable service and value that's easily compared to more fixed non-virtualized offerings.

The value that Twilio provides is much more clear to me, than say SalesForce, for example.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact