By Slobodan Stojanović．Jul 26, 2018
When Cloud Horizon grew to 12 people, it became clear that we need a tool for managing vacations and days off. Using Google Spreadsheets was hard, and there were no notifications when someone’s vacation is about to start. We tried with a calendar, but it doesn’t give you an easy way to see how many days off someone has left for the year. Then we tried to to find a tool for managing days off, but most of the available tools were full HR solutions. For a team of 12, those tools were way too expensive and had a bunch of features that we didn’t needed.
As our long term plan was to build a product, this looked like a perfect opportunity. So we decided to bite the bullet and build Vacation Tracker.
When you start thinking about your new product, the path to your core feature seems clear and obvious. But as soon as you start the journey, the road becomes blurry and full of roadblocks. Most of the roadblocks are caused by side issues, things that your product needs, but that are not solving your core problem.
How will you manage your users? Simple signup and login aren’t enough. Users need to be able to reset their passwords, create teams, manage permissions, etc. Or, how do you manage subscriptions? Payment processors don’t always handle declined cards and retries the way you would. Also, some don’t generate and send an invoice.
Most of those things are not hard, but they need time to be researched and implemented. Often more time than your core feature needs. Development time is expensive, but all those “side features” require more than a developer. Someone needs to decide how a feature will work and to write the specs for it. Also someone needs to test it before shipping the feature to production. This makes your product development much more expensive.
One of the obvious solutions is to outsource some of the non-core features to third-party services. For example, social sign in handles user signup, login, and profiles. In our case, as Vacation Tracker is a tool for companies, Slack login was an obvious choice. Besides login, it also handles user permissions and invitations for us. We also use many other services, such as Stripe Billing and MailChimp.
This saves a lot of time for your team, but your developers still need to do many things that are not directly related to your core feature. When a new feature is ready it needs to be tested, which requires some infrastructure. If you don’t have a DevOps person on your team (and as a startup you probably don’t), the developer is the one that needs to setup the infrastructure. Then, they’ll need to do the same for production. How do you even pick the size of your production server for your new product? It needs to be big enough for the spike you’ll get after posting your product to Product Hunt, but it also needs to stay in the budget. And budgets are always limited, because marketing is expensive but also necessary for the success of your product.
The infrastructure for production is not just the server. Will your developers handle scaling, logs, and backups correctly? Remember that they were not hired to setup servers, and even a small mistake can cost you a lot. Would you ask a plumber to fix your home electricity issues?
Wouldn’t it be great to outsource the infrastructure the same way you outsourced payment processing? Wouldn’t it be great to let your developers focus on the business logic of your core features?
Well, there is a way to do that. Its name is a bit controversial: servereless. But behind the controversial name is a simple but powerful idea: you care about your business logic and the service provider handles the infrastructure, including setup and scaling. Even more important is its pricing model, because with serverless you pay only for used capacity, not for reserved capacity.
Five ways serverless helps your startup
Even through serverless is directly related to the infrastructure, your startup can benefit from it in many different ways, including:
- Managed infrastructure
- Pay per use
- Real reusability
- Easier changes and pivoting
- Faster development cycles
Let’s dive into each of them.
Managed infrastructure
First and the most obvious benefit of serverless is the managed infrastructure. Your developers can focus on your business logic, and the service provider will handle the infrastructure. How does that work?
Your system is split into functions (or micro services), and each function is triggered by a specific event. Let’s say that you have a new payment from your user. That event triggers the function that processes the payment, and then the confirmation triggers another function that generates and sends the invoice. Your developers don’t need to setup a new server, or worry about doing security updates and patches. Instead, they just write functions and deploy them to a serverless environment using some of the popular frameworks, such as Claudia.js, AWS SAM or Serverless Framework.
Your functions run only when a specific event occurs. For example, when the system receives a new payment from the user. And even more importantly, your provider is doing all the scaling and security patches for you. That means that sudden spikes in your products usage will be handled automatically by your provider.
Pay per use
One of the biggest game changers is the economy of serverless architecture. Besides managed infrastructure, with serverless you pay for used instead of reserved capacity. What does that mean? It’s simple: if no one is using your application, it costs you $0. If you have a big burst of a few hundred users for a few minutes, you’ll pay only for those few minutes.
This is a huge benefit. Before cloud computing we planned and reserved capacity for a few months in advance. Cloud computing brought that time down to a few minutes. And serverless goes a step further and charges us for 100ms of usage, without the need to reserve any capacity.
Is serverless cheaper? Serverless functions cost $0.20 for 1,000,000 requests, with the first million requests free each month. A request is 100ms of function execution. Comparing the price per 100 ms, it’s probably not cheaper than the traditional cloud server. But your server never works at full capacity, and in the best case scenario at least 50% of server capacity and cost are wasted. Because of less waste, serverless is much cheaper in practice. It is so much cheaper that you can pay only $107 to serve 400,000 monthly active users!
Real reusability
With serverless, your application is split into smaller parts. You can think of them as micro services. All these micro services communicate through events or HTTP requests. In practice, this means that you’ll have a service such as image resizing separated from upload and other image related functionalities. As many of those functionalities are used on most projects, this means that you’ll be able to fully reuse the image resizing service on your next project.
How does that work in practice? Since Vacation Tracker is a serverless application, it’s billing functionality is connected to Stripe Billing. But as it is a separate service, we simply need to deploy our billing service to our next product, and to write its bindings to the product database. By doing that we can save 95% of development time for the billing feature of our next product.
Easier changes and pivoting
As your application is split into a bunch of services, it’s much easier to refactor the code. Yes, that word sounds scary, but it shouldn’t be. The same way your car requires scheduled service, your application requires to be maintained and refactored. Refactoring is scary because often changing one part of the app can break some other services. But with isolated services, as long as you don’t break the way the service communicates with other services, your changes will not affect anything else.
Besides refactoring, those services are allowing you to make changes to your product faster. As we all know, startups are often unpredictable, and sometimes the market forces you to pivot fast. With serverless, you can do faster changes, and you can even easily do A/B tests. For example, you can deploy a new version of a service and drive 10% of traffic to that new version. If it works you can slowly increase the traffic, until it gets 100% of it. If it doesn’t you can just shut it down without affecting the rest of your user base.
Faster development cycles
The last benefit that we’ll mention in this list are faster development cycles. Does it mean that you can build your startup faster with serverless? Well, maybe. Building products is much more than software development, and serverless can help you with some parts, but not with everything. From our experience, bottlenecks are often somewhere else. For example specifications are not ready or they doesn’t exist, business logic is not well thought out, etc.
But, with serverless you can at least have faster development cycles. First, your developers need to focus only on their job, they don’t need to think about the infrastructure and deployment. But they also can reuse existing services. There’s even a Serverless Application Repository for serverless apps on AWS. You can go there and with a few clicks get system parts that someone else built. For free!
How Vacation Tracker uses serverless
At Vacation Tracker, we use serverless a lot. Our app is almost fully serverless, with the exception of a few services that will be serverless soon. We host it on AWS and, at the moment, the application infrastructure costs us $0 (excluding the cost of the tools that we are using, such as MailChimp).
Vacation Tracker has a few groups of services, and each group has a few AWS Lambda functions and a bunch of other AWS services. Four of the most important groups are:
- The Slack bot services group covers Slack webhooks, slash command, etc.
- The API services group covers RESTful API, and includes API Gateway and AWS Lambda services.
- The billing services group covers billing and invoicing. We use Stripe Billing, but this service builds a whole ecosystem around it.
- The notification services group covers different notifications we are sending, including a weekly Slack summary of who is off, etc.
Our architecture looks like the diagram below:
Conclusion
Serverless architecture improves the way we build software. But it’s much more than just development, because it can improve the way we are building our products in general.
With serverless, your developers can focus on the business logic implementation, instead spending a lot of time on setting up and maintaining infrastructure. It also decreases the cost of your application, because it converts capital to operating expenses. Besides that, having smaller services allows you to implement changes and A/B tests easier, and to pivot faster.
With all the benefits mentioned above, serverless becomes more than the architecture choice, it becomes an important strategy. For example, it can allow you to charge teams per active user, without having to be a big company, such as Slack.
Of course, everything has its downsides. We’ll cover the most important limitations of serverless architecture in some of our next articles. Make sure you don’t miss it by subscribing to our mailing list at vacationtracker.io.
The original article published on Vacation Tracker.
