We got rid of our servers, can we now call ourselves serverless?
AWS serverless technology A few months ago, after long preparations and a lot of work, the time had come. The last servers were unscrewed from the rack in the data centre and loaded into the car. From this moment on, Harborn no longer has its own physical servers. We now use Amazon Web Services (AWS) to host over 200 projects.
In the early years, storing our data on physical servers in a data centre was the only option. However, the possibilities have increased enormously in the last 15 years. The introduction of EC2 on AWS in 2006, made it possible to create servers in the cloud in a matter of clicks. That’s why we were the only working Feyenoord website, after the 0-10 loss against PSV in 2010. The first release of Docker in 2013 heralded the next important step. Using containers, Docker makes it possible to run multiple virtual servers on a physical server with minimum overheads. Before containers, this was only possible using virtualisation, where the fixed costs for each virtual server were so high, it was only feasible on very powerful hardware. if you develop a website in a container, you as a developer only have to worry about the operating system dependencies that your application requires, such as a web server.
Most of Harborn's projects run in Docker containers on EC2 in the AWS cloud. However, the cloud continues to evolve, you will see the term serverless more and more in the coming years. In this blog, I'll cover what serverless means and zoom in on some AWS services that are essential for serverless applications.
Lambda and API gateway
Serverless is the next big step and makes it possible to upload your function (your programming code) to the cloud, without having to worry about servers or operating systems. Of course, behind the scenes there are still servers, but they are fully managed by AWS and you, as a developer, will not notice this. The AWS Lambda service uses this feature, uploaded to the cloud, executing it with various triggers. For example, in response to a web request that arrives at API gateway. You pay per millisecond that your code runs and AWS Lambda scales automatically. If there are suddenly thousands of requests per minute, API gateway and Lambda will deal with them, and Lambda will then scale down again, all automatically. Serverless therefore has a few major advantages.
- Developing software becomes a lot easier for developers, because they only have to think about their code and not about servers, operating systems and networks.
- Applications scale up and down completely automatically, at lightning speed, so that your application is never overloaded.
- You pay per millisecond and therefore only for what you use.
Of course, serverless not only has advantages, there are also disadvantages. Since you don't have to concern yourself with servers, you do have to keep that in mind. For example, you cannot assume that a file you save to the hard disk will still be there the next time you make a request. These are things that you should always keep in mind during development.
Amazon Aurora is a database solution that can be used to replace MySQL or PostgreSQL. Aurora has two advantages over MySQL or PostgreSQL: it’s three to five times faster and it’s possible to use Aurora “serverless”. I’ll go into a little more detail about the serverless use of Aurora. As mentioned, serverless solutions are where you as developer or customer do not have to worry about servers. You can think of a serverless database as a database that automatically starts up, shuts down and scales up and down based on usage. You pay per second for the use of the database. This makes it a very cost-effective solution for applications with unpredictable peak web traffic or long periods of little or no traffic (e.g. at night). We used Aurora Serverless for the Night of the Refugee app, where on the digital version of this event, there was a lot less walking at night than during the day.
Simple Queue Service
Simple Queue Service (SQS) was the first service offered by AWS in 2004. We use SQS to decouple different components or services and have them work together (asynchronously). You need to think carefully about how different serverless components work together, especially when you use a lot of serverless functions and components. You pay by the millisecond, so if a serverless function has to wait a few seconds for an answer from another system, the costs quickly mount up. SQS makes it easy to connect these components asynchronously, preventing one component from having to wait for another.
Are we serverless now?
Harborn no longer has any physical servers, but that doesn’t mean that we’re now serverless. We are, however, working a lot with serverless technology, because we believe that this offers great benefits for our customers. So we are becoming more and more serverless.