Quintessence Anx: Welcome to Page It to the Limit, a podcast where we explore what it takes to run software and production successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host, Quintessence or Quintessence Anx on Twitter.
Quintessence Anx: Today, we’re going to be talking about SaaS architecture with Arthur Berezin the founder and CEO of JovianX platform. Before founding JovianX, Arthur previously worked in product and technology roles at Linux Foundation, Cloudify, LivePerson and Matrix. Arthur, welcome to the show.
Arthur Berezin: Hey, and thank you so much for having me.
Quintessence Anx: Hi. So just getting started, what is the main consideration that people need to be mindful of when they’re developing a SaaS product?
Arthur Berezin: They have to be mindful about the lifecycle of the control plane that they’re building. In fact, this is one of the things that when the company’s planning to build and introduce a new SaaS product, basically they’re not thinking about the various integrations and workflows that they would need to develop in order to make their product work. Usually, that part takes a lot more time than initially a thought.
Quintessence Anx: I got you. How does this tie in with the most common myth or misconception you find yourself answering about developing SaaS products?
Arthur Berezin: Right. So, one of the topics is how do I go about building my SaaS product, right? So in some cases, some companies have some legacy they need to carry around, some companies already have some kind of product and they want it SaaSified, other companies build new products from scratch. In many cases, they’re also building and relying on existing open source solutions that they are consuming as part of their product, right?
Arthur Berezin: So, the question is how do I go about building my SaaS product, making sure that I got my multitenancy correctly, right? So, one of the main concerns of online products is how do I segregate data between users? People basically need to be mindful about how to go about and do that while consuming, obviously the goods of open source solutions that are being used in order to build a SaaS product.
Arthur Berezin: So, there are multiple architectures around how to build a multitenancy product. In fact, usually when you speak to people building SaaS products, usually they’re in the thinking of, “Hey, this is the right approach to build multitenancy for my SaaS product.” Generally, they’re just not aware that there are other options they can go about which would make their life a little simpler and much easier to manage.
Quintessence Anx: I gotcha. Okay, going right into developing SaaS products. So when we were speaking earlier, you mentioned that there are really two products, the product itself and the automation that enables it. Can you talk to us about that?
Arthur Berezin: Sure. So again, to go back to the story of a new company building a SaaS product, let’s take PagerDuty as an example, right?
Quintessence Anx: Right on.
Arthur Berezin: You have this great idea of building an online tool that will help SRE teams basically manage their daily lives, right? So you have a notion of shifts or teams, and you have a person who is on-call and you need to get notifications and alerts, right? You open an instance and you probably integrate with various monitoring tools that basically trigger these alerts. There’s a lot of content going on. But on top of the core content for the product, the core of what the product does, you still would have to develop tons and tons of functionality that is not directly related to the core product.
Arthur Berezin: Think of the multitenancy issues that you need to solve while building the product, think of the authentication and user management that enables the product. That’s not a functional part, but you still need to figure that out. You need to figure out how you do billing, and obviously when you have a new trial account sign into your product, you would probably want to send a notification to your sales team saying, “Hey, you have a new opportunity here.” Basically communicate with the person and make sure that we are doing the right job of making sure that our product helps that company, right?
Arthur Berezin: So, there are many integrations points and implementations that are not directly related to the core product. In fact, that part has a lifecycle of its own, and usually you need to develop this whole control plan that’s an ocean, we call it, in order to make your product work, right? So, what’s really happening is that you have developers working on the core product, and then you either have a separate group of developers or the same group develops also the control plane that enables your SaaS product, right? You need to be mindful that this control plane has a whole life of its own, right? You have to upgrade it, push changes and continuous improvements to that part, and you need to be mindful about that part as well.
Quintessence Anx: That’s awesome. So mentioning the control plane for automation, can you tell us what’s involved in that with regards to the lifecycle and so on?
Arthur Berezin: Right. So when you’re building a SaaS product, there are multiple moving parts in place, right? So, you have the core functionality of your product and that core functionality is in fact running somewhere, right? So you need to develop automation and integration into your CI, for example, in order to push updates, upgrades to your software or push patches, for example, when you need to introduce new fixes to your software.
Arthur Berezin: On top of that, you need to do the whole automation for account activation, right? For example, when a new user signs up, you have this trial period that you have some unique workflows happening throughout the trial period. You need to send emails to the customer saying, “Hey, welcome to our new service. We hope you enjoy our product.” You need to also send him reminders saying, “Hey, you’re still in trial. If you’re enjoying the product, just activate your account,” right?
Arthur Berezin: Once the end user activates or enters his credit card details, there’s this whole workflow automation going on in order to activate the product and create a new billing plan and charge the customer, integrate, send that data back to the CRM. So again, the sales team is also involved and aware of what’s going on. There are multiple integration and automation around the various common workflows that you see in SaaS, and each of them has its own merits, right? They need to maintain and manage all of them.
Arthur Berezin: So for example, integration with basically any company, right, needs to do some sort of integration with their HubSpot, with our CRM, with their PagerDuty account, send email automations, et cetera. So, all of those parts are fundamental to building a SaaS product and crucial in order to make it actually work.
Quintessence Anx: That makes sense. We’re talking about all the resources that go into this automation, but what are some that people tend to neglect in the architecture?
Arthur Berezin: Look at the SaaS product from a high level perspective, you basically could imagine an architecture of the product. So, usually you have somewhere where the workload runs, right, that’s some kind of cloud account that you probably use from one of the larger cloud providers, AWS, Azure, GCP and so on. So, this is where usually you run your workloads. Then you have the data plane, and you could use either databases that run within that cloud, or you can use database as a service, right, in order to build your cloud product.
Arthur Berezin: You can consume that either, again, from the cloud providers, or you can consume these databases from other companies. Any major database company, for example, today offers their product as a service as well, right? So for example, you can create a database as a service for MongoDB, you can get an on demand database from Elasticsearch. In fact, any major database and popular database companies offering their product as an on demand service as well.
Arthur Berezin: So you have the workloads, you have the database, and then you have the tier that integrates and consumes external cloud services, right? So PagerDuty is one of them, but you have many, many services that enables us and help a company to build a SaaS product, so you need to be mindful of that part as well. Each of those cloud resources need to be fully managed, right? So it’s not that you’ve created something, and hey, I have an account with, I don’t know, with an emailing service and I could forget all about it, rather, I need to make sure that I’m aligned with that product’s lifecycle as well.
Arthur Berezin: Because again, cloud products tend to also change and evolve with time and update their APIs, update their resources management. I need to make sure that all of my automations around all these products are also maintained and managed, right? So I cannot neglect those parts and forget all about them once they’re done, rather, again, once they are becoming part of my control plane, I’m responsible for maintaining these integrations. These tend to become complex over time.
Quintessence Anx: Are there common bits of those, the automation pieces, the integrations that people tend to not keep updated even if they’re trying to be mindful, just like gotchas that slipped through the cracks somehow?
Arthur Berezin: Yeah, actually, there are quite a lot of them. So for example, when you use, for example, Kubernetes is becoming the standard way to run workloads in the cloud, so there are many, many gotchas in pushing updates to Kubernetes services, right? So, usually you have a DevOps dedicated team who’s doing a lot of work and effort into making sure that all of these gotchas are being taken care of, right? But basically, if you have some corner cases that you haven’t thought of, you basically fail to provision a new workload.
Arthur Berezin: Usually these places where the workload runs usually get caught quite earlier on through the push of an update, but the various peripheral integrations are the more harder to plan for. For example, I’m using an emailing service or an SMS service, for example, that changed their API. So, these kinds of changes it’s really hard to keep up with and basically make sure that I’m aligned with all the changes that are happening through the dependencies that I’m using as part of my product.
Quintessence Anx: Okay, that makes sense. Going from that to the multitenancy model you started to talk about before, what are the different or a few of the different models that people should be aware of?
Arthur Berezin: When you go off the bat and start planning a cloud product and a SaaS product, usually what happens is that you reflect on your own history and you say, “Hey, I would build a SaaS product by having a database record saying this is account A, other record saying this is account B,” and would create a relational, for example, database, right? So, this is a model to create a multitenancy.
Arthur Berezin: But in fact, there are multiple architectures and multiple ways to develop multitenancy, and there are multiple resolutions where you can provision and consume resources in order to build a multitenant cloud product. So the model that I just mentioned, it’s usually called the application tier multitenancy, and that tend to scale quite well to a certain amount. Then once you hit the limit of your database, you would be required to change an architecture. That’s the application multitenancy model.
Arthur Berezin: Then you have the model of a multidatabase multitenancy model where you could have a database, for example, per type of customer or per region, for example. Facebook is weirdly enough a great example of that. So if you were following Facebook in their early days, what they used to do was that they used to create a full instance for their whole application and including separate database per college. So when they started, when they expanded from Harvard to other colleges, what, in fact, they were doing, they were deploying sets of MySQL databases per college. That’s the way they used to scale their product. That scaled quite nicely and allowed them to scale very quickly, and become this huge servicing a lot, a lot, a lot, lots of users.
Arthur Berezin: So, that’s the multidatabase model. But again, you can go also, as I mentioned earlier to the multiinstance model where you would have a full deployment, for example, per customer for your application or per region, for example. You would have a full deployment per region of your application, right? But you don’t have to deploy a full blown database per account, you can also, for example, go for the multischema model where you would have a single set of a single installation of a database and have multiple schemas within that. So that wouldn’t require you to have a full blown deployment for a database per customer or per region, rather you would have multiple schemas separating data and segregating the data between your customers or accounts or regions, depending on what you decide to do.
Arthur Berezin: Now, what’s the important part here is that when you’re planning for multitenancy, it’s really important to first decide what you’re optimizing for, right? For example, you could say, “Hey, I’m building a low touch SaaS product that’s aiming to serve millions of users.” Obviously all of us would say, “Hey, my product will be serving millions of users,” but the hard, cold reality of that is that usually B2B products tend to not being used by millions of millions of users. Rather, you will have probably some nice portion of hundreds or thousands of accounts, and probably each account will have several users within that account.
Arthur Berezin: So having that in mind, would you prefer optimizing for scale and density or optimize for cloud costs, right? Because again, if I’m provision a whole database or a whole application to your per customer, that could become quite costly, right? But if I get them from a cyber company, for example, I would prefer to optimize towards security rather than cost optimization and density, right?
Arthur Berezin: Again, cyber for me, it’s super critical to make sure that a data for customer A would never ever be served to customer B. One way to do that is to have a completely separate deployment of the application per customer. Again, the critical part here is to mindful about what we are planning to optimize for, and only then start to think about the actual solution implementation of how we go about implementing our multitenancy.
Quintessence Anx: Got you. Are there any questions that people can ask themselves, I know you’re talking about optimization, but to help people navigate these different models? So that instead of just saying, “Oh, it looks like this one’s the most popular, so we’ll try and make it work.” What helps them actually know what works for them?
Arthur Berezin: Right. So first off, there’s a short blanket and it cannot cover the whole bed, right? So you have to figure out if you take costs, density, data isolation into account, and put them on this matrix and have this arrow optimizing towards some direction, right? You have to understand first what’s the requirement for the product, right? Am I a B2C company?
Arthur Berezin: Say it’s a low touch product, I cannot afford a full blown installation of the product per customer, because that would cost me hundreds of dollars per customer, where each customer would probably pay me in the tens of dollars. So that wouldn’t make financial sense, so I need to take all the considerations into account. Once I have them, it becomes a little bit easier to figure out what makes more sense from an architectural perspective and how to go about architecture and building the cloud solution.
Quintessence Anx: Got you. All right, well, thank you so much, Arthur, for all of that. For everyone listening to this part, because this is the good part where you get to go and do a thing, they have an excellent blog post on building a fully managed service on Kubernetes that can help you learn some more about everything we’ve been talking about today. We’re going to be linking that on the show page.
Quintessence Anx: But before I let you go, Arthur, there are two questions that we like to ask everyone. Are you ready?
Arthur Berezin: Sure.
Quintessence Anx: Okay, what is one thing you wish you had known sooner when it comes to running software and production?
Arthur Berezin: Production is hard, full stop, so make sure you have the right tooling in place. Tooling is important to figure out what’s going on. Usually a strong team usually optimizes towards having the right tool set. So, having a great team is super critical here and a strong operation team in order to make sure that the product meets a certain good SLA or SLO. Because again, there’s no such thing as 100% uptime forever, right? You need to have a team that’s minded towards the right things in order to make sure that the SaaS is reaching good levels of SLA and making sure that the right tool sets are in place.
Quintessence Anx: All right, awesome. Then on the opposite side of that, what is one thing that you’re glad we did not ask you about?
Arthur Berezin: Eh, so not really sure about that one.
Quintessence Anx: So you’re great with everything, that’s awesome.
Arthur Berezin: One thing that I would like to briefly mention is that I’m super passionate about open source. I think without open source, many of the awesome companies we know today wouldn’t be able to exist. What’s super interesting to me is that open source benefited this huge momentum over the past couple of decades, and what’s weird to me is that you don’t see any open source SaaS solutions, right?
Quintessence Anx: Okay, okay.
Arthur Berezin: Yeah, there are quite a few solutions that you would consider as open source product, they’re available also as an open source solution. I think one of the main reasons for that is that because today with the tooling today, it’s really hard to separate between the product and the controlled plane for the product. If it’s really hard to separate the two, you would tend to not allow access to your control plane, because that part is usually very sensitive and holds basically very sensitive information, right?
Arthur Berezin: You have billing, you have plans, you have many security roles. You would tend to not want to expose them, but what you would like to expose is the functionality of the product. Because today, many of the, in fact, 99% of the products, I think, that they are not building a mindset of there’s the control plane, there’s the core product, it’s really hard to offer products as open source solutions.
Arthur Berezin: I think once you make that distinction between the core functionality and the control plane of the product, then it becomes a little bit simpler for you to release the source code for your core functionality, and in fact, allow your users to contribute the things that are bothering them, right? Which is the core fundamental idea of open source. So I’m really passionate about that notion and that idea, and I think in the future we’ll definitely see a lot of innovation happening in this place.
Quintessence Anx: Okay, awesome. Thank you so much for expanding on that, Arthur, and thank you for joining us today.
Arthur Berezin: Sure. Thank you so much for having me.
Quintessence Anx: This is Quintessence wishing you an uneventful day.
Quintessence Anx: That does it for another installment of Page It to the Limit. We’d like to thank our sponsor PagerDuty for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes at pageittothelimit.com, and you can reach us on Twitter @PageIt2TheLimit using the number two. That’s pageit2thelimit with the number two. Let us know what you think of the show. Thank you so much for joining us. Remember, uneventful days are beautiful days.
Arthur is the Founder and CEO of JovianX Platform for SaaS, a control plane for SaaS products, radically simplifying building and operating SaaS and cloud services.. Previously, he held products and technology management roles with RedHat, the Linux Foundation, Cloudify, Liveperson, and Matrix.
Quintessence is a DevOps Advocate at PagerDuty. Prior to working at PagerDuty she was a Developer Advocate / Technical Evangelist at Logzio and then AppDynamics (part of Cisco). Her main area of focus is DevOps - tooling, cultural shifts, best practices, etc. At PagerDuty her main role will be to facilitate strong relationships between the developer / IT / Ops communities and PagerDuty.
Quintessence has been working in the IT industry for over a decade. Prior to Developer advocacy, she started out in Technical Support (now referred to as Customer Success), then dabbled as a Database Administrator, before becoming a “Cloud Engineer” / “DevOps Engineer” (or whatever the cool titles are these days) specializing in AWS.
Outside of work, Quintessence ran Inclusive Tech Buffalo (formerly the Buffalo chapter of Girl Develop It) for 5 years and is staying on as a local mentor. The goal of the group is to help underrepresented groups start sustainable careers in technology via mentorship, networking, and in a pre-pandemic world workshops and/or classes. She has a cat named Luna, also referred to as Bear, and an aquarium with a green mantis shrimp (Cora) and two maroon clownfish (Clove and Cinnamon). If you are curious about what the mantis shrimp is, I recommend The Oatmeal comic on the topic or the True Facts About the Mantis Shrimp YouTube video (disclosure: the latter has some light NSFW humor).