Notice that each service we use in the cloud does one thing, and does it extremely well? Some of the services we use are 3rd party (like Auth0, S3, Firebase and Stripe) and some is custom code that we’ve written.

Our custom code footprint in the cloud is absolutely minimal — limited to just a few node.js functions running inside AWS Lambda. These functions perform protected actions that we can’t trust a user’s browser to orchestrate, such as:

finalizing card payments and granting users access to the courses they have paid for

triggering emails to a segment of our users (we can’t trust code in our user’s front-end to do this, because it would expose the email addresses of other users and allow any authenticated user to trigger emails to any other users)

What’s driving the serverless trend?

This is now possible, because:

we have rich browser MVC frameworks like AngularJS that enable us to write large and complex web applications, with full build systems and test runners.

almost every service you can imagine is now HTTP enabled and supports common authentication token exchange protocols like JWT. This means that your user’s browsers can send credentials to interact directly with the different cloud services you use.

there are 3rd party cloud services for a huge range of functions — all of whom are focused on doing one thing and doing it extremely well. You can now outsource a huge range of rich functionality to cloud services such as:

- User Authentication

- Protected File Download / Upload

- Credit Card Payments

- Notifications (email, SMS, push)

- Real Time Streaming Database Access with offline sync capability

And then there’s user preference. Mobile hardware these days is powerful and people prefer a richer, faster user experience. Unfortunately — a ubiquitous, always-reliable internet hasn’t yet arrived. It is still common for users of the internet to suffer degraded connections and loss of connection regularly. So, our general preference is for richer, more powerful applications on our mobile devices that can deal with offline scenarios and sync data when returning online.

Is this secure?

Absolutely, as long as you make it so.

It’s all in the design. When introducing a new cloud-service, you need to design with security in mind — understanding that users will interact with that service directly using their credentials. You need to understand how to lock down what they can/can’t read and write.

If you are using a 3rd party service then you have to understand how you can lock down access to that service. For example, with Firebase (a real-time streaming database), you write custom security rules that are executed by the database engine to determine which users can read or write from different parts of the database.

If you are writing your own micro-services, then you need to ensure that your services check the authenticity of the security token passed and verify the rights of the user.

So what defines serverless architecture?

There’s no exact definition, but I think there are some basic characteristics that define a system as serverless:

Operators do not need to run and maintain back-end servers themselves

The vast majority (~ 95% +) of the code-base resides in the front-end

The code that resides in the cloud is only the code that absolutely must — as an example, for security purposes some work must be done with access to secrets that the user’s browser cannot be trusted with

The front end acts as the orchestrator calling a rich array of cloud-based services to perform specific functions — such as taking a credit card payment, giving access to protected resources, shooting off emails or push notifications in response to events

It’s important to note that this doesn’t mean there aren’t any servers. Of course there are, but someone else is managing, securing, maintaining and patching them, taking the load and responsibility off your shoulders and freeing you up to focus on building your unique product.

Has It Been Worth It?

Absolutely! Using a serverless approach for A Cloud Guru, we were able to get a fully interactive online social learning platform to market in a fraction of the time that it would have taken us in the past. We can now innovate quickly, and add new features to the user interface continuously — without having to touch so many layers of code for each new feature.

It’s not without it’s drawbacks of course, this wild departure from traditional architectures has introduced it’s own set of challenges.

We’re learning a lot, and we’ll follow up with future blog posts going into more depth about the technologies we’ve used and the challenges we’ve had to overcome.

Keep up with the latest from A Cloud Guru on Twitter @acloudguru.