Software as a Service is probably what you all want to be. Most of you are deploying a system that is going to be on the internet, are building a web application that you’re going to manage the business capabilities of and the interaction with users, and they’re not going to have to install anything on their machine to do it. This even counts for mobile apps that have a backend server necessary to support them. So a lot of you are probably creating a Software as a Service. Almost all of Proteus’ customers are Software as a Service companies.
To do this, you’re probably going to be dependent on some companies that provide some of these other something as a service. You’re probably on AWS, you’re on Heroku, something like that. You’re probably not going to be doing it all yourself. You can, we’ll get to that later on. So how do you decide what you’re doing, which way to go, what’s required. First thing that’s required is systems thinking versus application thinking. I gave a talk a couple of months ago on building web apps and why tightly coupling the web aspect with you app was a really bad idea. Because that was app thinking. You really need be thinking about systems thinking. You need to have loosely coupled, highly cohesive, microservices that communicate to each other, that are horizontally scalable, that by themselves individually have very little complexity, because the system as a whole has a lot of natural complexity. And you have to architect your software to be able to be easy to deploy, easy to test, easy to isolate. When you’re thinking about building an application, like build a Windows GUI map that’s going to be on somebody’s machine, your non-functional requirements are pretty much infinitesimal. It’s like you’ve got enough memory and CPU to do it, if so you’re fine, you don’t have to think about non-functional requirements. For Software as a Service, your non-functional requirements are as complex or more complex than the actual user facing functionality and this is the challenge of what Software as a Service is inherently about. So you have to have, I’m glossing over this, we can go as deep as you want on this. You have to have a mature repeatable environment. It has to be really easy to repeat the deployment for testing purposes, pre-production purposes, and production purposes. Your entire environment, with any possible version that you might need to support. That requires thinking about it when you wrote the code that you’re going to be doing this. It’s not something that comes by accident. I’ve given talks on Agile development. Who here does unit testing of their code, on their running code. So you guys have a good start. The rest of you are so screwed. When it comes to building Software as a Service and making your infrastructure easy to do. Because by making it very easy to run automated unit test, you are also naturally building your software to be easier to isolate, which means it’s easier to deploy and test. That’s not a guarantee rule but it’s a very strong heuristic, and we consistently see that for systems we’re asked to support. People who follow agile practices and actually have really strong code coverage on their unit test, they’re the ones that are the easiest to deploy and we’re able to charge them a lot less money than the ones that have no unit testing on their system, that are using monolithic code base system. Those ones have difficulties. It’s very hard to repeat their environment, very brittle and not mature.
Other thing is scalability. Nobody thinks about scalability, until their system is knocked over. Couple of years ago, one of the big ticket agencies, there’s a Thai comedian, you all probably remember the story, who was selling tickets and their website went baam and the comedian was embarrassed. It’s a big big big news. They didn’t think about scalability. If Proteus had been their operations people that would not have happened to them.
At time 2:37 and 3:42 speaker means “Software as a Service” instead of “Systems as a Service”