Building something from scratch is challenging. Balancing between costs (like time, effort or money) and between functionality, is hard work in a startup project. An early stage project, in order to succeed, needs to take different directions sometimes even on daily basis.

To support this we need to

• stay flexible
• be cost effective
• continuously create good value with minimal effort.

An application’s architecture needs to reflect these requirements. We can't go waterfall, build something big and expect it will support an early stage business for long time. The business requirements will change tomorrow. Instead, we build lots of small software units which do one thing only, but do that perfectly. The smallest software unit which can provide some functionality is a 'simple function'. We use these small building blocks to achieve the desired architecture.

Staying flexible

Functions support changing business directions quickly. A function can be updated easily depending on the new requirements, or even be thrown away when not needed anymore. It hurts less, as the effort of creation was also minimal.

If specified and implemented properly, a function is independent. It does not need to know much about its environment, can be run on any platform, implemented in any programming language. It just needs to be invoked by some action.

It also supports changes in the team. A small software unit can be easily rewritten using a different technology by a different person. As long as the input and the output (the signature) of the function does not change, everything still works.

Being cost effective

In the world of Serverless architectures, we don’t need to manage the server infrastructure, instead we pay to a FaaS (Function as a Service) provider to manage it for us. The nice perk is that we pay only for the time the function was executed, and running a function is very cheap. We can run a function millions of times and still only pay few USD per month. This supports startups perfectly.

Why? The time to create a function and make it running on a FaaS platform is an order of magnitude quicker than setting up our own machines to execute it. Also there is no operational cost like in traditional continuously running servers, just execution cost. Initially as the application is small, or the execution time is minimal, there is literally no cost of running these functions. As the application grows more functions will be executed. The FaaS will automatically scale up due to the nature of the statelessness, so the application scales with the startup!

Great value with minimal effort

What is minimal effort? Well, focusing only on the business logic which provides the business requirements. Functions let us do that.

At orangejellyfish we like to solve problems and come up with smart solutions. We like to iterate quickly and in each iteration create great value. We would not be able to do that if we would be focusing on anything else than the business logic.

Let’s see an example how serverless helped us.

Serverless monitoring

At orangejellyfish we take quality very seriously, but there are always variables which are out of our hands. This is especially true after we deploy a software to a platform not managed by us. To ensure our software is working in-live as expected, we started thinking about putting guards in place.

One of these guards is a monitoring system. We would like to monitor our webpages to see they are available and feel responsive, also we would like to get alerts in case something goes wrong.

Solution

Applying the Pareto principle, more commonly known as the 80/20 rule, we wanted to come up with something which we can quickly iterate on, but straight away brings us value. If the system would check the configured website on a reasonable frequency (e.g. every minute), and on failure we would get an alert by e-mail, that would be already a success for us.

We value Serverless solutions, so an obvious choice was using the Serverless framework with AWS. Here is how it works.

AWS CloudWatch triggers a pinger-function every minute which makes a HTTP request to the configured URL. It posts the result to an AWS SNS topic called monitoringTopic.

A notifier or a subscriber function listens to this topic and if there is a failure it sends an e-mail to a configured recipient. An e-mail is sent also if any of these functions fail to execute.

That's it. Simple.

Serverless framework makes it easy to construct and deploy this system. It abstracts away the hustle you would get by using AWS specific solutions like AWS CloudFormation.

By the way, you can try it out: https://github.com/orangejellyfish/serverless-monitoring/.

So if we think about the architecture described, we see there are 2 functions and 2 triggers/actions. A trigger executes one function (the pinger), which makes an action which triggers the other function (the consumer or e-mail notifier).

It works towards the requirements described at the start.

It is flexible

We can easily expand on our notifiers and add e.g. a notifier for Slack, our internal chat everybody sees in the team. We can bring in new tools like the lighthouse to analyse webpages and generate comprehensive reports. This can be done without interrupting the already achieved functionality.

It is cost effective

To monitor one webpage we execute our functions once every minute. The cost is almost 0 to run this system. There is no maintenance or operational cost. No need to care about running servers. No need to dedicate time to any of this, on the other hand we can focus on important functionalities.

Scalability is not even a question with AWS Lambda. We could choose to run our functions even every millisecond and the infrastructure would simply adapt. All done by AWS.

It brings value with minimal effort

We already have great value. Something will tell us in a minute if the website is down, instead of us realising it much later. The effort was clearly minimal.

Conclusion

Serverless architecture is definitely a very powerful tool and pattern to have. It nicely fits into the startup world as the costs are more controllable without sacrificing the potential of scaling up.