No more monolithic apps - how Yesware uses microservices to help salespeople succeed
- Summary:
- Microservices over monolothic apps! Perhaps - but the reality is never that simple. Here's how Yesware uses MongoDB as a service from mLab to give salespeople tools they need.
In a recent chat, Pescatore told me about how MongoDB as a service from mLab has changed IT - and how their sales enablement customers benefit. He also addressed my burning question: do microservices reintroduce complexity to IT?
What motivates salespeople?
Pescatore made a bold claim that got my attention: they've figured out what motivates salespeople. But, he joked, that's been obvious all along:
They want to make money.
When you give a salesperson a new tech tool, they may or may not use it. But when you show them that tool will make them more money, you better believe they'll use it. And that, Pescatore says, is what Yesware does well. They do it via email automation and prescriptive analytics.
I took the cheese: how exactly do salespeople close more deals with Yesware? Pescatore:
Across their team, we analyze all the activities that they're doing. We figure out the things they're doing that are working really well, so that they can then iterate on their sales process, and do more of the things that are working.
Yesware also shows salespeople where they're not doing as well:
On the flipside to that, we can also help them determine when they're not being effective. When it's time to cut their losses, selling to a group of people that's clearly not interested.
Rather than target the right people, salespeople fall back on a spammy email approach:
I think there can be a tendency sometimes in sales to just blindly spam as many people as you can, and just hope some small part of them cash in for you. We're trying to preach that there's a better way, that you could be a little more targeted, and put a little more data and a little more thought behind your process and spend less time and energy with those communications that are really not good for anyone.
Why MongoDB as a service?
Amen. So how does Yesware's approach to data work on the back end? When Pescatore joined Yesware in the summer of 2012, the decision had already been made to go with MongoDB via mLab's database as a service (DaaS) offering. First question: why DaaS?
We knew that we needed some flexible, NoSQL-style, document stores in addition to some relational database models that we have. We also knew that we didn't have the resources to hire a dedicated DBA, and we didn't have the expertise to go without one. So database-as-a-service seemed like a natural fit. Plus, the rest of our platform is largely hosted through third-party providers. We've got very little self-hosting in our system.
So has the deployment grown in the last five years? Yes, and then some. When Yesware started off, they had one Mongo database, one Postgres database, and one Redis. Yesware has grown from 20,000 total users to over a million users. They are now close to twenty MongoDB clusters on mLab.
The biggest critique I hear about MongoDB - especially from competitors - is about performance and scale. Has that been a problem?
In the early days, we did hit some of those performance issues. Inevitably, it was because we were using the database in a way that it's really not designed for. We were not very good at indexing. We've gotten much, much better at that. We should not discount the help that we got from mLab on that, too. They've been invaluable in helping us figure out the right way to index our data over the years.
Yesware has upskilled their own team:
Because of all the help from mLab, we have a lot more in-house knowledge of the right and wrong way to do things like. With good indexing, I feel like the performance you can get on MongoDB can be pretty spectacular, for the right kinds of data.
MongoDB is a bit of a security headline grabber, though all the sensational stories I've read involve MongoDB deployments where the security features were not enabled properly. Pescatore's take:
Pretty much any service software or any database out there has the potential to be set up in an insecure way, and MongoDB is no different. We are constantly trying to get better around that. mLab does a good job at making their default set of configurations a pretty sensible, secure state, and also letting us know when things need to be patched, or when maybe they detected an attempt or an attack or something like that. They'll let us know that it happened, even though it's pretty much a nonevent.
From a "monolithic app" to microservices
One problem with Yesware's growth: it led a monster app with a monster resource drain. That's why Pescatore and team turned to microservices:
We pulled that monolithic app apart into a microservices architecture. Ideally, each service that has a need for a database gets its own cluster, so that there's no shared resources there. That's why we've got so many MongoDB clusters.
Before microservices, when they encountered an issue, it was hard to determine why their app was performing poorly. A big stress on one service could slow down the whole app:
Pulling apart those features into separate applications that we could monitor more closely, and scale up and down in a more controlled way, was really huge.
Now, Yesware's main app functions almost like an application router, pushing incoming requests to the right microservice:
Instead of that app doing the heavy lifting, if it gets some requests to serve up say, some templates, it can just quickly route that request over to a different microservice that handles all of the templates... In that way, the workload is spread across dozens of apps.
I've heard objections on microservices from Twitter followers who are suspicious of their potential to re-introduce complexity to IT. Pescatore acknowledged it's an issue to manage:
There's no question it adds some complexity. I think that we've done okay with that. We've made some tooling in-house that makes our development environment a little easier to manage.
Pescatore says this tool helps to show which microservices are needed, and start them in the proper order:
It takes care of all that for you, which helps with where I find that a lot of the complexity around that can frequently creep in.
The biggest microservices challenge? Getting new IT folks up to speed:
The hardest thing for us still is when new engineers come on board, because it's such a huge landscape at this point.
Pescatore says there's no magic bullet for that either, but robust documentation and training goes a long way.
The wrap - IT "comes up a level" to serve customers
There's another big benefit to the "DaaS via microservices" approach: it's allowed Pescatore's team to stay more customer-focused.
We refocus our day on figuring out the right offer to build for our customers.
"Coming up a level" unleashes ideas for customer services:
We've been able to move from where the data lives and how the data gets around, and managing the servers. We can come up a level from that and say, "Okay, we've got this platform that we know is rock solid. How can we build new, innovative features on top of that, knowing that if we need more resources, we need another database or we need more servers, we can go to our providers and get them easily?" It frees us up to do that quickly.
Frequent gut checks from their own salespeople keep Pescatore's team focused on the right problems:
We've got a really rare advantage in this market in that we're building software for sales teams, and we've got a sales team that sits 20 or 30 yards from us. They're our best customer. We definitely have a culture in engineering of valuing their opinion very much.
Now that's a mix of IT and sales teams you don't see every day - and one that any sales manager would support.