S1E13 - Podio Deep Dive 2a: "Building SaaS That Businesses Can Rely On - Part 1"

Gil Roberts: 0:02

Welcome to the Podio Solutions Podcast. Season One, episode 13. I'm Gil Roberts and with me today is our lead developer here at Bridge Bridge , Alex Shull. This podcast is about the design and development on the Citrix podio platform and you can find that a Podio, p o d i o.com. We use this podcast to discuss our own experiences with podio as well as other interesting topic. It's from produce developer community. If you are a podio designer or developer working in an agency, small business enterprise, I should immediately hit that subscribe button if you haven't already. Thank you so much for your support. Lastly, before we dive into today's topic, if you have a topic issues, solution, problem or anything else you'd like for us to discuss, we want to know about it, hit us up on our Facebook, linkedin, Twitter. We're sending an email or a podio message to podcast@brickbridgeconsulting.com all right, so we'll dive into today's topic. It's a the second episode of our mini series putting your deep dive. We've got a great topic. I think it's going to be of interest to a lot of our listeners and bring a lot of value. Uh , what we want to do is actually a two part or possibly a three part series a building SAS that business can rely on. A , we're going to dive into what it means and what that is on the cloud computing concepts for our business software. So , uh, Alex is going to lead our discussion today and uh, what's it, let's just dive right into it.

Alex Shull: 1:32

All right . Thanks Gil. Um, and today I want to cover some core concepts which people may have heard the, they may already understand them. Um, they may not, but they're pretty critical to having a further discussion about building SAS that businesses can rely on. And , um, I really want to keep this from a business perspective. It is a technical consideration and I'm discussing some technical things, but I'm also going to lay out things that aren't really of concern to me in this discussion. And I want to kind of keep those separate just to make it , um, clear that discussing , um, the business perspective on SAS means that you're taking those business concerns first. You don't take the technical concerns first and , and that really is a different perspective on software. Um, so the first thing I want to talk about it for cloud computing concepts is, you know, the, the concepts that have been around for a long time are we talking about software as a service platform as a service, infrastructure as a service. You're talking about these as a service approaches and those get um, thrown out around a lot of things like those concepts that had been around for a long time and they're probably familiar to most people. Software as a service is, you know, most, most software today is software as a service when it comes down to it . But there's some assumptions behind that that I want to break down a little bit. And the , the reality of it though is that in talking about those distinctions of platform as a service, software as a service, infrastructure as a service, I honestly don't care about them. And the reason is that the, they don't have a big impact on the kind of saw business offer development that I'm talking about because in the end what's critical is that they are either services that are within the business scope or there are services that aren't within the business scope. And the only thing that really matters for this discussion when we're talking about the kind of business offer we develop is the services that are within the business scope. So as an example, you might have a database service like we do underlying the software that we write that we use in developing the software. However, if people choose to use our product Sassafras, that is not a concern to them because that's just the part of the product. So all they care about is the service that Sassafras extends to them, the platform, the other services behind the scenes. Those aren't in the scope of the business users interests.

Gil Roberts: 3:58

Its behind the curtain, its the black box we're going , and we're going to make an assumption on this as well.

Alex Shull: 4:04

When I talk about things, I'm not talking about any of the infrastructure service platform as a service. Those aren't the cloud competing concepts. That's not the level of analysis that I think is relevant for um , making this discussion valuable for , uh , podio users. So everything is really software as a service, but what does as a service mean and why? Why is it different? Well, to me, the biggest distinction for as a service is that the way that the software is delivered, it is delivered on the basis of a service, meaning that you pay for the service to be turned on. It can be metered and you pay for to turn it off and you no longer , it's a utility. You turn it off and you turn it on. Now there are , there's a lot of cloud software that doesn't actually work that way. And there, there's, there is some variations on the payment model, but the cleanest versions are the ones where you literally turn it on, they're metering you and you turn it off. The, the other versions are every time you call it, you get the cost per indication . And that's the model . Yeah, the toll model. And that's what we see with procfu and with other version , um. Yeah . Yeah. And that's a , that's a, that's a very similar model. And so the , the entire point though is that when you're developing modern cloud based business software, one of the things you want to be able to do is have a very accurate way of projecting your costs. And the, especially if you're delivering that software to others, you want to be able to project your margins, you want to project a lot of things. And if you bring everything into that common mold of pay as you go, then it becomes a much more feasible for you to develop a software that uses those services and still be able to approach the ongoing costs in a very predictable. And um, computable way. You don't want to have a lot of gray area and the services that offer the pricing in that model are more attractive from the standpoint of business offer development because you can price it out that way. There's a big benefit to having the simplicity in pricing when you're building much more complicated software scenarios.

Gil Roberts: 6:14

I think, I think it's something from a , from my business perspective that I see you're always good from, from a true as a service software is um , I'm buying into that component, that function that I'm mixing into my business model. I need that cost to be predictable. Right? Cause I need to, I've got an end calculation for the cost of myself .

Alex Shull: 6:36

Yeah. And their predictability is part of it. But then another thing is the low entry costs . You want to be able to integrate with a piece of software as a service turnkey, no big up front costs. I was looking at a software that we might be competing against for one of our clients in the future. I don't want to get into too many details about what this sector is, but they were charging thousands of dollars. We talked about this, they were charging thousands of dollars up front for the software and then what seemed like an unreal is to me unrealistic low monthly cost. And dug into the softwares. We saw that, and this is just used to run on a local windows machine and they've wrapped this cloud like layer, it's like a Citrix window, you know, session that opens up on the computer, but it's actually a progressive web app. I think the way they designed, but that's not here . That's neither here nor there. Right. The pricing is what threw me off because you can deliver the software many, many different ways and still have that true pay as you go software as a service model. But this company had not moved away from the old CD distribution model, the initial licensing set up model and then very, very, you know, I , I'd be surprised if their service cost actually covered their service at the rate they're going. But that's their business and you know, I wish them the best, but that is not what I'm talking about. And so the , the, the, one of the big components that the benefits you get of having that low entry cost is you get that ability to very quickly try things out, modify, change, adapt, enhance, iterate. And that is one of the key aspects that we benefit from and that anyone who is building business software in the cloud today needs to benefit from or you're not getting the , the, the true promise that the cloud enables is that flexibility of being in a very agile manner of trying things, putting them together, taking them apart. And then the, the beauty of having that low cost of entry is that if somebody becomes very , very important to your application, it starts costing you a lot. You can go look at replacements, you can go look at how to pull that component out and replace it with a cheaper component, a better performing component, a more secure component, whatever it is. But you're composing,

Gil Roberts: 8:57

well I was going to say event component actually say on flip side of it. Upgrade. So we take, take advantage of technology that's coming through because because you have that a part of the system you're paying in, they're using that money to upgrade and maybe give additional features and functionalities.

Alex Shull: 9:13

Yeah, absolutely .

Gil Roberts: 9:15

Sorry, I didn't mean to , no,

Alex Shull: 9:16

no was a great point. And so is that, those are the concepts that as the service really that's what I mean when I say that as a service and beyond that in today's world, this kind of goes into the, the next little section in my little notes here is that a service has implications for how integrations can be performed. So you, if you are really delivering services and you want to say that you're delivering you something as a service, you have to have some kind of an API. I really don't think you're there as a company. You're delivering something as a service. If you haven't thought about APIs. Now podio is on extreme in terms of how much of their platform they exposed by API. And there are some companies, Google's a good example, fantastic services that weren't all, you know , made available by API initially and they , they've been catching up to that and making great improvements. But um, the, the aspect of, of having , uh , an API leads to those integration possibilities. And even if people go in and , and they're wiring things up by themselves with Zapier, it relies on APIs. Those APIs need to be there to tie things together. And so those service components, not only you pay as you go, low entry costs , composability, you get the agility trying things out, but it goes together with those API . Those futures don't come just because you know you're delivering something , uh , letting someone pays you go. And so I want to break down those concepts a little bit more about API because there's a lot going on there. And at a minimum what we're talking about is when software on the Internet can talk to other software using the internet, it's really that simple. And API is a way for a cloud enabled software provider until that other computer code talk to it directly. And usually on the behalf of the user. And that's the way podio works. You're talking on the behalf of an existing user to podio and that's how you get those automations and all that. And so the API is what we talk about is the service and APIs have that. That phrase goes back a long way, all the way to code that just ran on the local machine though their APIs exists as well. But the, in today's world, when we talk about APIs, we're really talking about the way of exposing those services on the Internet, buying an http, preferably https interface, and letting people call in to those services over the public internet. And so that that's what , and typically those are rests. And I'm not going to get into rest versus soap because for the current purposes, a really doesn't matter, but rest is just one version of an API. And when you're talking about an SDK, so an API stands for application programming interface, and then SDK stands for software development kit. And so the SDKs are specific to a language. When you talking about an SDK, you're talking about , um , a way for someone using the javascript SDK to talk to an API or someone using the.net SDK to talk to the podio API or if someone's using, you know, another language. So the SDK is what enables someone using a specific programming language to talk to an API that's made available that that's a, that's an important concept as well. Um, and so at the layer of, of services, when we talk about services for my purposes and the purposes of cloud computing discussion, it's really interchangeable with API services and API APIs are basically interchangeable. I'm going to cover just a few more concepts that these, this , the most technical that I'm going to get, but I want to get the concepts out there. Um, and because I will refer to them in the future. And it's important just to understand generally what these concepts are. Um, when in the first emergence of the public cloud infrastructure with Amazon web services and Rackspace. And , um, the, the model that was really being promoted in those days , um , came about from the movement towards virtualization where instead of just having an os, you had a virtualized operating system that could run other machines on the same disc and they would actually share the resources of the computer to run multiple separate operating systems on a single piece of hardware so that the, the concept of a VM, a virtual machine, were used to, you have to run it directly on a machine , on the bare metal, so to speak. You can now run it on a virtual operating system. That means you can turn it off and turn it on and access it from the cloud and never have to touch a power switch. That's the concept. Spin them up, spin them down, only pay as you use them. Beautiful instances, instances, and this is what we talking about with infrastructure as a service. If you want to dig those terms up. Again, that's the, the core, the basic concept of , of infrastructure infrastructure as a service. So that's what, that's what a VM is. Now in today's world, vms have largely been replaced by what we call it , containers. A container is a lot like a VM, except it's much more constrained in terms of what you can actually , um , do to it and how you can do things to it. And the idea behind the container is to make, basically, it's to eliminate all the variations between running code on your local computer in a VM and then sending it to the cloud and running it on a VM in the cloud. And the containers really addressed the , um , all of the variations in the specific operating system and patching and whatever additional libraries you have loaded and concerns like that, whether you're exposing certain network ports. So it containerize all of those aspects that the, the VM , uh , need to needed to , um, deal with in order for a code to run consistently. So really when we talk about containers in a sense for the standpoint of the business user, it's almost interchangeable with VM, they're not identical. But from the concept of, of the business user thinking about cloud computing concepts, they both exist. And what's the runtime there are running your code. Either it's a VM running your code or it's a container running your code, but it doesn't really matter in the end to the typical business software. You know,

Gil Roberts: 15:55

it's just kind of magic in the ether.

Speaker 3: 15:57

And yeah, it's an important concept. It's an important concept to know that it's your run time , it's what runs your code, but it w if you're getting below that level, then , um, you're , you're getting into details that shouldn't really impact the way you think about , um, you know, putting cloud, using cloud computing to, to build a business offer today. Um, but you always hear the words docker and Coobernetti's and some other terms like that. If you get into the technical discussions about containers and those are really great technologies that have been, you know, championed by Google and other companies that are just around standardizing the open source software for creating and managing containers. All of this leads to something though, and all of these technologies and advances and the way that we develop our run times have led to this new as a service model which people call function as a service. And it's the latest and greatest. And this is AWS. Lambda has a version of function and as a service and we use it extensively and the idea is you only pay every time your function runs. So it's even less than having a container because the container, even if it's not working for you, you're paying for it. But as a function, you only pay when the container is running your function. So it's even more direct towards exactly what you need. Now there are limitations to what you can do with containers and and and functions and and lambda and all these things. But again, all of those are versions of a runtime. And the difference is how much control you have over it and how much you pay to have it around the modern function as a service. You have the least control over the environment, but you only pay for when it runs. And so you have the most flexibility, but on the VM side, you have the most control over what you create for the os, but you gotta pay for the darn thing the whole time. Whether you're always on, you gotta go turn it off. If you don't want to pay for it, the function soon as it exits your code, you're not paying for it anymore. So it's almost like it automatically turns it off. And so it's an exciting development for the purposes of in a very cost effective manner, being able to develop, deliver a new code without knowing exactly how , um, you know, useful it's going to be without having to worry about scaling up the resources. If it gets, you know, requested 10 times more than you expected it to.

Gil Roberts: 18:20

I'll move up by you hit that. You hit the kind of key word portion, which is scaling. Yeah. This is, this really allows the software to scale as needed in large from my understanding of what... like huge spikes in traffic you can handle.

Alex Shull: 18:40

Yeah . And it's, and it's getting better and better. It's really remarkable. But I'm , if they're scaling on very different time frames on the short time frame of going just to a few requests to several thousand requests or something like that, Lambda is really good at, you know, you only pay for what your , the request of your handling and they can spin up additional instances as needed up to a thousand concurrent instances handling requests for you. And so that's, that's a lot of traffic you can handle with, you know, a thousand concurrent...

Gil Roberts: 19:12

And that's, that's it your call, right? It's just whenever you need it. Yeah ,

Alex Shull: 19:17

that's right. That's just the default limit . You can get a raise if you need to. Um, basically , yeah. And, and , uh, it's also just the , uh , obviously the, the, the , the, the flexibility of having access to , to resources like that. Um, but those are run times. And um, in the end, you know, any one of those variations that we're talking about, the important part is that if you have custom code that you need , um, to , to run, you know, the integrate your business software, that those are the, basically the, the modern ways that in a cloud computing environment you can have your code be executed. Um, last few concepts here. Draw it, draw down to these last few concepts that I want to get out that I think are really critical. Um , and these are more general internet concepts. I'm going to go back to what people should know these. Um, I, I'm not to say should, I apologize. Don't feel bad if you don't know these, I'm gonna help you out right here. So the concepts are domains and DNS hosting and certificates. So when we're talking about domains in DNS, a domain is brick bridge, you know, consulting.com. That's the name of our domain. And there's dot org domains, dot mio.gov.us on and on and on. There's dot information. Way too many , but the the entire point is that there is a system of registration out there that when you get a domain you own, that you have this true license to leverage that name for the purposes of developing an email address and website and all those pieces and domains are very, very relevant for how traffic is routed on the Internet for integrating businesses together and who you trust and whether those endpoints are secure. Those kinds of things. So the , it's very, very important to understand what a domain is and what people talk about, what they're talking about when they refer to a domain and the fact that someone owns that domain. It's very important to understand that. Now DNS is the system where computers look up domains and DNS. You give it one of these name domain names like google.com brickbridgeconsulting.com there is a resolution that happens where it has to look at the host name that comes before that, like www.google.com and then it has to talk to a system of computers that are all integrated with this system called DNS, which is domain name resolution service. You those have to get resolved down to numbers cause only numbers are routable on the Internet. Routing means your request gets sent to the right place. And so that connection between DNS resolution of the names and the numbers is a very important concept to realize. Hosting is , is a pretty simple concept. It kind of goes back to the run times that I was mentioning, but when you, when you host the , the concept of host is that um, your, you're basically paying someone to run your code for you and they have it attached to your domain. So if someone is hosting your website, that means that they're running the code that shows people your website. But it also means that your domain name is pointing to the code that is running your website. Both of those things go together when you're talking about hosting, so hosting is the running part of it, but in terms of when you're dealing with business software you have to realize that it also means that the domain name is getting pointed to the right place. Those two things go in concert and the last bit of it is the last one that probably the most critical one is certificates. Certificates are critical to understand in that they are the keystone to all the security on the Internet and there are a variety of ways that certificates are used for cryptography. I'm not going to get into the details of that, but again you have to understand at a core level that when you buy a certificate on the Internet there is a system of registration. That cryptic guy graphically assigns the numbers in that certificate to the owner of the domain and that's the way that you can have https and there are those. The two systems of certificate registration and issuing certificates and domain registration issuing domains are totally separate and you bind them together when you own a domain and when you have a host, all those concepts have to come together in order you to deliver https traffic that resolves to the domain name. You own those , um, that , that's all I'm going to throw at you for now. Uh , I want to get those, those base concepts out there , um, to where we can have some other interesting discussions about building , um , SAS that businesses can rely on , um, without having to get any more technical than the concepts I covered today.

Gil Roberts: 24:10

That's amazing. I, you know, I've known some of this stuff just working in and around the IT industries for some time, but I , there was a lot of stuff that I thought I knew, especially about virtualization. You know, that's a little bit of an older technology, but I just wasn't as in tune then. So yeah, I , that helped , uh , kind of clarify some of my assumptions maybe and gave me a little new knowledge as well. Hope our listeners got a great value that we got a the next uh , continuation into the next part next week. So we're going to use some of these concepts that we learned today. We're going to carry those into the next episode. Uh , that's going to be a ,

Alex Shull: 24:51

yeah, just , just give me a little foreshadowing on that. Just A, I want to start using these concepts to build some higher order patterns that people can recognize that will help them understand how to build software and where do they know , um, where and when to expect failures and how to deal with them. It's about having a process where even when things go wrong, you know how to move your business forward.

Gil Roberts: 25:13

Yup . Otherwise, in that, I think we're going to go ahead and wrap up today's episode. We are still looking for gaps to solve in Podio, so do get those in and you can get those to us at our Facebook, linkedin, Twitter, shoot us an email or a podio message to podcast@brickbridgeconsulting.com. Please, please, please hit that subscribe button if you have not, and then feel free to give us a review. We'd really, really appreciate that. That always helps us with our rankings on the iTunes store or stitcher or wherever else you are listening to us. So thank you guys very much and we're excited to dive in to these concepts deeper next week with Alex.

Alex Shull: 25:54

All right , thanks.

Gil Roberts: 25:56

Thanks guys. Have a great rest of your week.