In this article I will describe how serverless cloud architecture for a modern digital application provides Contactpoint clients with the opportunity for quicker time to market, less dependence of a particular technology and lower hosting costs.
When we say that a software application is running in the cloud, we mean that all the resources and services that the application utilises are hosted on the Internet. The internet is a mass combination of connected computing servers processing some 98,038Gb worth of traffic per second (at the time of writing!).
Accessing an application, and data it creates, which is hosted in the cloud simply requires a device (PC, tablet, mobile phone …) that a browser runs on, and a connection to the internet. As an example, all of the business software that Contactpoint use is running in the cloud, so that we no longer need to have those applications stored on physical servers in our office. This has meant that moving to everyone working from home during the COVID-19 pandemic has been relatively easy. We simply took our devices home, and continued to have access to all the resources we need, including our telephone system.
So what’s the big deal about serverless cloud?
The term ‘serverless’ cloud refers to technology architecture where the developers of a software application do not need to concern themselves with the underlying servers upon which the technology is operating. It is yet a further level of abstraction, compared to provisioning private servers in the cloud, or virtual private servers that are then allocated to particular applications and maintained with regard to software versions, security updates, disk space, performance and physical hardware that needs to be replaced over time.
Our most recent serverless technology implementation for a client’s SaaS product (soon to be launched) comprises a back-end using AWS Amplify, AWS Appsync, AWS DynamoDB and AWS Lambda – more about these components in a moment. As stated by AWS (Amazon Web Services; one of the most popular and comprehensive cloud computing platforms) using a serverless architecture allows you to “build and run applications and services without thinking about servers. It eliminates infrastructure management tasks such as server or cluster provisioning, patching, operating system maintenance, and capacity provisioning … everything required to run and scale your application with high availability is handled for you.”
It is still vital that as developers we plan, architect and provision resources appropriate for the application being developed, but the serverless architecture reduces much of the issues and workload (both upfront and long-term) associated with managing servers in the cloud. Even more importantly for our clients, serverless architecture allows you to only pay for those services that are used by your application and only when those services are actually used. Depending on the payment option selected by you, payment can be down to the millisecond of processing power used by your application.
The competition between the main cloud providers – AWS, Microsoft Azure and Google Cloud – is fierce as they are vying for share of market, and our clients are often able to secure generous incentives to build on a particular platform such as free services for a year.
It is important to note that a serverless application has a very different architecture compared to a traditional application, in order to take advantage of the benefits of serverless. As developers we need to give much more weight to considering how often each function within an application will be invoked, how long the process will run for, and how much data will be transferred, as these will all have an effect on the costs of running the serverless application as it scales, as well as the performance of the application. Serverless application development also requires the use of components provided by the cloud provider in order to achieve the ability for the application to scale – underneath the covers these components take care of provisioning more physical servers and computing power to meet the demand of the application.
For our client’s SaaS product, choosing serverless architecture is the right choice as their app is destined for use by millions of people across the globe, but will start small. Using serverless means that they will only pay for the small amount of usage upfront, but the application will automatically scale as demand grows.
A brief summary of the main components used for the backend of our client’s application are as follows:
AWS Amplify is a framework and toolset within which mobile apps and web apps can be built. It facilitates the development of UI-driven, highly scalable applications and provides access to a large number of AWS cloud services.
AWS Appsync allows us to write GraphQL APIs in the cloud. GraphQL is a trending, flexible and a fast API query language. The choice between a REST API and GraphQL API, their respective advantages and trade-offs, is a topic for another blog! With directives such as @auth and @model, Appsync generates queries, mutations and resolvers for us, which we can then customise to the application requirements. It also provisions tables in the DynamoDB automatically, and both these put together, provides significant time saving in the app development. It helps developers focus more on core functionality of the app, business logic and front end.
AWS DynamoDB is a NOSQL database which continuously backs up the data, and automatically scales as required. Being a NOSQL database provides great performance for fast return of data.
AWS Lambda provides us with a platform to write microservices that will compute as required and only incur costs per computation. With the right usage, Lambda is very effective due to its nature of continuous scalability and zero administration required.
When should I choose serverless architecture for my application?
The general factors to consider when choosing serverless architecture are:
- Quick and continuous scalability – auto-scaling is an important attribute of serverless architecture. If your app is targeting a large user base e.g. the general public, then the number of your users, and their demands for resources, can grow very quickly. For example, a new online health magazine could grow to a million readers, but might start very small. If you were to allocate resources and services to cater for a million users right at the beginning, you would have lots of idle resources and need to maintain those as well as cover the cost until the readership grew. Using architecture that isn’t auto-scaling would involve much effort by the hardware, software and security teams to keep us as you grow. Auto-scaling solves these problems.
- Effective Cost Management – as mentioned above, building and provisioning resources with a million readers in mind right from the beginning could incur huge costs until the app makes it to a million readers. Instead, by developing serverless we will use resources and services as needed by the n number of users currently, and will scale up as the number of readers grow to a million (or more). Thereby, we will incur costs for the infrastructure only as it is used and presumably paid for by the users.
- High Availability – AWS components like Amplify and Appsync provide offline data access and conflict resolved synchronisation when back online. The databases and storage also tout high availability of data since distribution of servers in the cloud has facilitated almost zero downtime and 24/7 availability. This is why many organisations are migrating legacy applications to the cloud, and converting them to serverless applications.
- Low Maintenance – AWS databases such as DynamoDB and storage systems such as AWS S3 are so low in maintenance that we can almost term them as zero maintenance. AWS claims that DynamoDB requires absolutely no maintenance at all. Once setup properly, it can keep operating continually, scaling as required, and performing as designed and intended. Even the relational databases provided by AWS, such AWS Aurora, require very less maintenance (updates and patching) when compared to other non-serverless databases.
- Performance – last but not least, one of the most important factors for all applications is performance. We can have an online health magazine app that has the content and potential to become the most popular app ever, but if it cannot deliver content quickly for a million or more readers, it is bound to fail. By performance, we are referring to the speed of data retrieval, data submission, loading of the user interface (where that is part of the server-side application) and the speed of functions that process the data and business rules / programming logic of the application.
What languages does serverless architecture support?
When building an app within a serverless infrastructure such as the AWS platform described above, you still need to choose the programming language within which you will write the application that lives on the device of your end user, or is accessed via the cloud by the end user. This programming language then needs to be able to interact with the components above. AWS provides many options in this regard including NodeJS, Java, Go, PowerShell, JavaScript, C# and .Net framework, C++, Ruby and Python.
For our most recent application we chose NodeJS for the backend code, and ReactNative combined with NativeBase for the mobile apps. This choice allows for similar languages to be used across the frontend and backend of the SaaS product, providing for a simpler implementation, and easier application maintenance over time. However, some components of the AWS environment support Javascript, and Javascript libraries and frameworks better than others – like all cloud platforms, they are ever expanding and improving the functionality that they make available to developers to speed up development. We needed to switch choices of libraries several times to resolve unexpected issues with parts of our app due to less support for ReactNative compared to native mobile application languages (Java for Android and Swift for Apple).
Depending on the way your application is constructed, the serverless architecture also makes it easier for you to mix code implemented in different languages, allowing you to use best of breed for each function within your application.
Should I move my legacy or web application to serverless?
As I mentioned above, many organisations are moving their applications which were built and deployed on a dedicated server (either on-premise or in the cloud) to serverless architecture to gain one or more of the benefits. Before deciding to move an application to the cloud, you will need to consider the effort involved – you will only achieve some of the available benefits if you simply “lift and shift” your existing application. To fully benefit from the move, your application will need to be re-built in the new architecture. For this reason, organisations often put off a transition until their application is sufficiently in need of a re-build before making the move.
As a developer, I look forward to working on applications which help our clients grow, through the amazing scale possible via serverless cloud architecture.