parallax background

How going serverless changed the way we work and develop software

Need a mobile app for your startup? Read this first
April 1, 2016
What makes startup servers crash and how to prevent it?
April 29, 2016

 

Today, I’d like to share kind of a new concept. Usually when we are about to create new a website, online service or mobile app we think about 3 parts:

  • In which language am we are going to develop it?
  • Which hosting provider we will use?
  • Which kind of server should we are going to need? With which capacity?

On the other hand, we see the word “Cloud” everywhere, which could mean almost anything today. The word “Cloud” often applies to the end user but it does also apply to the IT field. Today it’s possible to build entire scalable and complex online service without managing any servers or virtual machine. We can compare it to creating a Facebook page, you subscribe to Facebook and connect apps together without building any server or virtual machine for it.

All starts with 4 software components 

When it’s about building online software we usually think about 4 components:

– The view component. The views could be a website a mobile application. The only goal is to make information available and accessible, either on a website, a mobile app or a TV screen.

– The database. The database will contain all the numeric and text data about your service, your customer and your content.

– The storage. Depending on the type of service you are building, storage might not exist or might be the main part of your business. Depending on the amount of data that you what to store, we usually use a different service than the database to store big volume of data, images, customer files.

– Processing. This part is certainly the most important part of any software. Again, depending on the service you provide, the processing part might be done by the website itself, only if you process a small amount of data. We think about processing as soon as a process take more that 1 or 2 seconds. A website is originally created to only display information, not to perform processes. In case if you need to convert a video file, or generate a 100 pages pdf you should think about an external processing component.

What server less means? 

To make it simple, server less means that you do not care how the service is built, you only use it. For each component there are service based solutions to help you build your software. Of course, you can also use the advantage of few services or also mix classic ways and services base components.

Build view component over services

There is actually two ways of building a view component. The old school one – which is generating the page on the server end. We usually use PHP, Java, .net, Python, Ruby languages with a dedicated connection to the database server on the server side. With this way, we are still really dependent of the server configuration and managing everything. Server less is a bit more complicated. In that case, the solution is to delegate everything that is not code to a Cloud provider. To do so, we can use service like Docker containers or managed clusters like ElasticBeanStalk from Amazon Web services. Then we should only provide a git repository of our website, web application or API code and let the cloud providers do the rest. The best part is it’s scalability; depending on your traffic, the cloud providers will allocate dynamically the amount of the required power.

The second way of managing the view component is with client side language. Many big websites like LinkedIn work that way. In this case, the server configuration is pretty simple. You just upload the application, usually in JavaScript to your browser, and then your browser talks directly to the database and processing component. This configuration is pretty simple as you just need a static hosting providers, which could be as example Amazon S3, Google Cloud storage, Azure Blob storage. Files are delivered quickly to the client through a CDN configuration.

Build a database component over services

Few years ago, the startup parse.com build a new kind of service that allowed people to build mobile apps without having any server side development. They’ve provided managed database access with lots of easy to user features. Today, this kind of service became common and all cloud providers provide their own database as service and API management services. There are usually two components to these services.

The Database as Service is a simple database accessible on the web. But, guess what, we don’t want to share all our valuable information on the web. So we use an API management service, which is going to control each data access and make it accessible according to your app rules. This same principle exists on almost every cloud providers. As example, for Amazon this is DynamoDB and API gateway, for Google this Google DataStore and Google endpoint and for Azure we talk about DocumentDB and API management.

These are the components that will allow client side application to work server less (mobile app or full JavaScript website). To simplify, the application is provided as a static content and the API services provide the required information to feed the application content.

Build a storage component over services

This part is the simplest one. Storing files has never been as easy as it is today. All cloud providers provide solutions to store static files. Amazon S3 is the older one, Google cloud storage does the same thing as Azure blob storage. Even OVH has his own object storage service. The solution is quite simple, we can upload, download files with some simple API calls, the files are protected with Access lists and we can make any content public behind a http URL, if we want to.

Build a processing component over services

This is the trickiest one. Processing data is not the most common task. As soon as we start talking about services where big files transfers are involved, content conversion or report generation then we should discuss the processing queue. When processing is involved, it’s all about an event, an input, a process, and an expected output. Let’s analyse those 4 parts:

The event. An event can be almost anything. A specific time, maybe regular, or someone that drops a file on the service, or a new line appears in the database. We always need to start the processing from one event.

The input. The input is obviously the data that needs to be processed. Whether it is a file, which could be saved on a storage component, some database data or maybe another external service information like the trade market values for example.

The output is, of course, the result expected from the process, and once again, it could be saved in the database or on a storage component.

The process can be handled in thousand of ways. Whether it is a simple file generation or if you need to a computer during several hours or days to process and output your result. Without diving in details of the queue principle – it is quite common and interesting. Your app should stack the data that you need to be processed in one and single queue, then one or several computers can process them one each at a time until the queue is empty. This is exactly what Amazon Lambda service does for small and realtime tasks, or what Azure Batch does for bigger processing tasks. There are lots of possibilities out there especially when we dive into the data processing world.

Hopefully you got the point

What I wanted to share today was the infinite amount of possibilities we have to build online software without actually building any infrastructure. In my opinion, this is a real new era where, hopefully, code will remain the only part that will be required to do.

Does that speak to your problems or does it raise any questions?

Feel free to share your thoughts, questions, comments or experience! I’d love you hear from you.

Leave a Reply

Your email address will not be published. Required fields are marked *