Serverless Architecture: how you can benefit from it and what to be aware of
Lately, there’s been a lot of buzz around serverless architecture. Some say it’s changing the way applications are built, deployed and consequently used. While others argue that serverless computing doesn’t really live up to the hype built around it. So which one is it?
In this blog post, we’ve decided to take a closer look at what is serverless architecture, how you can benefit from it and what drawbacks you can expect from it as well.
What is serverless architecture?
Serverless computing or simply serverless is the type of Cloud architecture that doesn’t involve you managing any servers, virtual machines or containers. Despite what the name might suggest, there are still servers, of course, but the task of handling them falls on your cloud infrastructure provider. This allows you to execute the code in a form of functions at automatically provisioned infrastructure and environment. As for the serverless infrastructure providers, there are various options to choose from. Any major Cloud provider offers serverless nowadays:
- AWS Lambda
- Google Cloud Functions
- Microsoft Azure Functions
- IBM/Apache’s OpenWhisk
- Oracle Cloud Fn
Leading serverless providers
So what is and what isn’t serverless, you might ask. To classify something as truly serverless AWS uses the following 4 characteristics:
- There are no servers to manage – as we’ve established, physical servers, virtual machines, and containers do exist but you neither manage nor have access to them.
- The price is based on consumption – you only pay for the resources consumed, not capacity, which means you don’t pay for the time your application is idle
- It scales automatically – as your application grows and meets new demands, it should be able to scale automatically. For example, our team proceeded with Vivino application migration to the cloud which allowed the app to meet the increasing load and grow to more than 36 million users now.
- Built-in high availability and fault tolerance – availability, recovery or fault tolerance are not your responsibility, as they should be built-in.
Quite frequently it is referenced as “Function as a service” or FaaS. But is only partly correct. Serverless architecture implies that applications either rely on third-party backend services (Backend as a Service or BaaS) or custom code that is run in managed, ephemeral containers (Function as a Service or FaaS). This way, you no longer have to worry about server components. This task falls on your provider.
What are the benefits of serverless?
Apart from the already stated, there’s no server to manage, serverless architecture has other tempting sides:
- Reduced cost – on-demand pricing model of serverless means that you pay per function execution which is much more efficient than paying for server fixed price even if it not used. This and the fact that you don’t need to maintain servers 24/7 lower the development cost sufficiently.
- Low maintenance – from the developers’ perspective, the only thing they need to focus on is application code and business logic, the rest, like server maintenance, scaling configuration, monitoring or runtime environment, fall on the shoulders of the serverless provider.
- Shorter time-to-market – by removing unnecessary efforts in provisioning required infrastructure for development teams, serverless sufficiently reduces time-to-market. It provides the opportunity to release new functionality quickly by removing roadblocks. Thus making it an ideal solution for PoC or start-ups.
- Scalability – serverless architecture is easy to scale when needed, which is especially great for an unpredicted load. In cases when a new feature becomes suddenly popular, the serverless environment provides scale-up and scale-down capabilities automatically. So there is no need to worry or prepare upfront.
- Security and regulatory compliance – serverless providers are responsible for providing a secure infrastructure that is safe, free from hacking and attacks. Additionally, a serverless environment complies with most of the regulatory requirements like GDPR, PCI DSS, HIPPA, etc. Moreover, cloud providers may alert you to out-of-compliance situations, as was the functionality implemented by our team when working on compliance gap analysis and remediation steps for HPE GreenLake, a cloud provider, which manages cloud compliance and cost control in a company’s cloud transformation journey.
- Focus on UX – serverless or not, infrastructure are not the things your customers care about. What they need are great, seamless experience and new features. So this is something you should be focusing on, thankfully serverless architecture allows exactly that.
The downside of serverless computing
But as tempting as serverless architecture might seem, there are also some drawbacks to be aware of:
- Expensive for steady high-load. Unfortunately, serverless is not a silver bullet. When the load increases, serverless offering could become quite expensive. But usually, by this time most of the assumptions are confirmed and you should be quite sure if you want to keep it or not. When you get a steady load, it is time to move to dedicated infrastructure for cost-saving purposes.
- Vendor lock-in. Once your code is implemented and depends on several managed services, it could be hard to move out from the cloud to on-premise data center because you will need to build alternatives for managed services being used. Even migration from one cloud to another could be painful because of the differences in the API or functionality provided by different vendors.
- Serverless limitations. Serverless providers set some processing limits. And if you have too many tasks running at the same time, some of them could be blocked from running properly at the requested time. On top of that, serverless is a better fit for short, real-time processes like sending an email rather than long-running processes (like uploading a video) that might be better off on servers.
- Integration testing is a challenge. Another problem you might come across is an integration testing which is made tougher by serverless abstractions and ephemeral existence. You might also meet some challenges with deployment, versioning, and packaging. Testing on the cloud plays a crucial role, for example,
Amazon serverless platforms and their use cases
The most effective way of creating serverless architecture is to pick one of the many serverless platforms that offer numerous capabilities. The main game players on the market today are Amazon Web Services, Microsoft Azure, and Google Cloud Platform. With myriad options to choose from, these platform providers offer a solid foundation for the smooth serverless journey and fully developed serverless systems. Let’s look into what Amazon, one of the leading serverless providers has to offer and full capabilities of using it to build a web application.
With the introduction of AWS Lambda in 2014, the concept of serverless computing has become widely popular. It was later quickly followed by IBM OpenWhisk/Bluemix, Google Cloud Functions, and Microsoft Cloud Functions. Serverless computing means that the task of application code execution is offloaded to a serverless computing platform for various benefits, such as: not having to worry about hosting runtime, letting the provider manage the security side, easy integration with other services and overall being a cost-effective and scalable solution. This is a winning solution for both a software vendor and business owner, as it allows to focus on code and leaves the execution part to a provider.
The first and most popular choice here is AWS Lambda. It can be used to build powerful websites and offers numerous benefits, such as faster development, scalability, lower operational cost, and easier operational management.
But when it comes to serverless time is money. And one of the biggest goals and challenges is avoiding paying for the time when Lambda is doing nothing. The best way to optimize time is to use asynchronous programming. When async is badly executed it creates controller functions that are waiting for AWS services to do something. And what would be a better use of time is to use events or Step Functions to find a better and cheaper solution. Good async can make a huge difference by executing parallelly.
For additional functions like the ability to throttle users or requests, protecting against Distributed Denial of Service attacks, or providing a caching layer to cache response from Lambda function, API Gateway can be applied as we did it for in the case with the healthcare AWS cloud-based platform.
For executing simple, time-based tasks like sending out the newsletter on a fixed time, cleaning up the database cache at the regular intervals or for websites running membership accounts with an expiration date, CRON or scheduled jobs can be applied.
When it comes to serverless computing, a serverless database is not only a prerequisite but also something that requires careful consideration. A rash decision that was not thought out well can cost you extensively either because of ongoing maintenance of the database or to migrate data to another solution.
The most database cases can either be resolved with SQL or relational databases (e.g. MySQL, PostgreSQL) or NoSQL or denormalized (e.g. Dynamo DB, MongoDB, Cassandra). The choice here depends greatly on your priorities. The normalized database offers more flexibility but at the expense of performance. For cases that require high performance and hyper-scalability, NoSQL is a better option.
For the applications running in AWS, the most popular choices of the database are: DynamoDB or AWS Aurora.
DynamoDB comes with a lot of benefits like automatic scaling in accordance with the application load, pay-per-use pricing model, low amount of maintenance and is generally considered easy to get started with. However, it should also be noted that DynamoDB makes migration to another solution very challenging with a lot of work involved. Its ideal case is an application with set access patterns that won’t change. If, however, you expect some changes in the future, you might need to look into other solutions.
Amazon Aurora is MySQL and PostgreSQL-compatible relational database. It performs up to five times faster than MySQL databases and three times faster than PostgreSQL databases. Its on-demand, autoscaling configuration means that the database starts out, scales the capacity per app’s demand and shuts down if not in use. Since it’s fully compatible with MySQL and PostgreSQL databases, you can easily migrate these databases to Aurora. There’s no need to worry about management, setup, configuration or backups as it is fully managed. AWS Aurora is an ideal, highly secure and cost-effective solution for intermittent, infrequent or unpredictable workloads.
Data processing use-cases
Another popular use case is data processing that comes in handy when there’s a need to process some incoming requests between software components and thus they need to communicate and exchange information. With AWS, there’re three ways to do it:
- Amazon Simple Queue Service (SQS) is a queueing service that enables decoupling and scaling of microservices, distributed systems, and serverless applications. SQS allows sending, storing and receiving messages at any volume without losing messages. This can be applied for sending out massive amounts of emails, transcoding video files after upload, analyzing user behavior. It works the following way:
A producer sends tasks (messages) to an SQS queue when they are read by consumers in a queued manner.
- Amazon Kinesis offers managed services for streaming data ingestion and processing. It can be used to ingest real-time data. Kinesis responds instantly, by processing and analyzing data as soon as it arrives instead of waiting until all data is collected to begin processing. It can be used to ingest real-time data such as audio, video, application logs or website clickstreams.
- To trigger multiple Lambda functions to process different functionalities, the fan-out technique can be used. A very popular choice here is Amazon Simple Notification Service (SNS). It’s a durable, secure messaging service that allows decoupling microservices, distributed systems, and serverless applications. Using SNS, publishers systems can fan out messages to a large number of subscriber endpoints for parallel processing (including SQS queues). It can also be used to fan out notifications to end users using mobile push, SMS, and email.
But building highly scalable web applications is not enough. In order to improve the product itself and get some understanding of user behavior, you need to incorporate analytics. Amazon Serverless services can help with that as well.
To analyze analytics events and turn data into valuable insights you can use, Amazon Athena can be applied. It helps you analyze unstructured, semi-structured, and structured data and can be used to generate reports or to explore data with business intelligence tools. As a serverless solution, it queries large amounts of data and gets the results in mere seconds and you only have to pay for the data scanned.
As an out-of-the-box solution, it is integrated with AWS Glue Data Catalog, which allows to create a unified metadata repository across various services, crawl data sources to discover schemas. As a part of AWS serverless solutions Glue natively supports data stored in Amazon Aurora, which means less hassle.
The range of Amazon serverless platform offering shows that you can easily build and run serverless applications and they completely have your back. And this is just one provider, you can pick any other of the five leading market players and discover their equivalent offering.
Debating whether serverless architecture is what you really need? Contact us and our technology consultant will help you to make the right decision on cloud solutions for your product whether you need it for building a cloud-native application from scratch or for your legacy app modernization.