What needs to be done?
If you want to build an app, you probably want it to be highly scalable, fast and efficient. According to what I learned when overseeing building over 50 cloud projects at Neoteric, there will be quite a few aspects you need to take care of to make it happen:
To see how it works, let’s take an example of “My Better Netflix” app.
First of all, you will need a “place” where: users will register and set up an account, and where they will log into your product (possibly into many apps that your app consists of). Then, you need to define subscription plans including distinctive features like “HD movies”, usage constraints like “max number of connected devices”, pricing and trial. Once you have subscription plans in place, you need to be able to sell something to your users and usually make it a recurring payment. You will also need some kind of notifications (along with templates) that you will send to your users when they’re running out of quota when their payment fails etc. Finally, you need a metrics engine that will allow you to track what your users are doing (including their usage vs. purchased usage quota).
Having that done, you’re $60000 short, 3-6 months into the development and you don’t even have a product. As much as 80% of all the code is wasted on the common stuff. Keep in mind that when you integrate all of it, necessary work increases exponentially.
How-to?
Once we know what you need to do to make your “My Better Netflix” app, let’s talk about tech and see how to do it. We will have 7 basic “as-a-service” components:
- Authorization and tokens
A common way to handle auth & SSO is via tokens (cool kids use JSON Web Token mixed with OAuth). You need endpoints that take in grants and dish out tokens. JWT allows you to encode info about a user within that token and extract it without reaching back to the out service. - User management
You need an API that stores info about users & permissions, their profiles and credentials (remember about encryption). Don’t forget about password reset (see: Notifications) later on. - Tenants
When you think about users, some of them will be grouped together and billing will be taken care of by “admins”/power users. - Notifications
You need something to send out emails and/or SMS. Setting an email server on your own is an expensive thing to do, so it’s probably better to try integrating with Amazon SES or SendGrid. Don’t forget about templating! - Subscriptions
What you need in here is an integration with a payment gateway (like Braintree). Make sure that it handles recurring billing – you usually need to match your subscription plans with what the payment gateway is able to handle. - Metrics
Other components should be able to send info about what is happening in your app into metrics engine. You should expect a large amount of data (read-only) to be processed into actionable insight. Think of this component as a black box that you put events in and get back answers to questions like “what is my churn?”, “how many devices has user X connected to my service”, “what is the account balance of user Y”. A popular buzzword in here is event sourcing (think Apache Kafka or Apache Spark). - Payments
You have to handle payments & credit cards of your users securely (based on what you have defined within subscriptions). What you need on your side is a “callback” of successful/failed and cancelled payments, that gives your users time-limited access to your system. Note: remember about chargebacks.
Where the magic happens
Speaking of tools and architecture stuff, there is a bunch of handy technologies that will help you make your app work:
- Code repository
You need a secure and reliable place to put your source code: the Git repo. Github is a nice place for pet projects but it quickly gets expensive with bigger teams; consider getting yourself a Gitlab instance. - Build tools
Once you have your code in your repository, you need to be able to build it – preferably in an automated way. Once it is tested and built, you need to package it into an artifact – I strongly recommend Docker as a way of deploying your apps (again automate it). The combination of Gitlab + Docker builds + Ansible does the trick. - Artifact registry
When you build your app, you need to put a packaged version of your app “somewhere”. Make sure you have plenty of space and you secure access to your registry, keeping in mind that automation tools should be able to use it. - (Micro)services
Microservice architecture is a way of building apps from very “condensed” services. Think of them as about building blocks from which you assemble your product that you can replace and scale individually. Why scale the whole app when you only have a bottleneck with authorization? - API
All of your microservices need a way to communicate with each other and the outside world; the common way is to arm each of them with a RESTful API. Some popular frameworks are: Spring Boot (Java), Loopback, Sails.js(node.js), or Flask (Python). I also recommend you take a look at the Java stack we created at Neoteric: neoteric-eu/neo-starters – it’s a mix of SpringBoot & Netflix stuff with a few of our own enhancements. - Messaging
Your services need to notify each other about “events” such as: new user, purchase or expiration of subscription etc. You basically need to implement “listen everyone, user X did ABC” and RESTful API is not necessarily the best way to handle such communication. Take a look at RabbitMQ or ZeroMQ. It’s important that you don’t forget about scaling – you will end up with a case where only one of X instances of your service should process an event. No matter which MQ you select, I strongly recommend reading ZMQ guide – it’s a great overall guide to building distributed systems. - Databases
What really works for me is using one database (or more) per service. Using database as an integration point is A Bad Thing. Keep in mind that we now have specialized: relational, document, key-value & graph and we use the one that best fits your scenario. I’d recommend taking a look at database-as-a-service offers. While they might seem expensive at first, they save you a whole bunch of trouble and are simpler and more cost efficient in the long run (take a look at my presentation for the Mongo User Group for the details). - Logging & monitoring
Once you have multiple services up and running, you need a place where all the logs & metrics will go – with all the moving parts you will go nuts if you don’t automate and have no insight to what is going on inside your system. To make sure you have it, try out ELK (elastic search, logstash & kibana). - All of that
If you want to get it all faster and reduce your app’s time-to-market, SaaS Manager will take care of the majority of the stuff above – including auth, subscription plans & Gitlab (hosted by us).
And here we are. That’s approximately 80% of your app. The last 20% is the core of your app – movies (in the case of this “Better Netflix”) or anything else that makes your app special and unique. Putting it all together:
- You need auth, subscriptions, and users + tools to make it happen.
- You will communicate with users via UI and with others systems via RESTful API.
- Internal communication is best handled by message queue.
- It’s good to split your system into self-contained services.
- Automate the crap out of everything.
The article was originally published at Quora as an answer to I have an idea of SaaS and want to build high-performance system, what are the technical things I need to know before starting implementation?
