What's a phrase that encompasses all the metrics and measurements that make or break your site or app? Put succinctly, it’s "customer experience." Sites that focus on delivering a great customer experience will thrive, while those that don't will fade into irrelevance. How do you deliver a great experience? An excellent place to start is ensuring that your web pages are fast, smooth, and responsive.
When you make the move to serverless, one motivating factor is cost. Serverless can reduce your overall operational expenses, but to achieve the maximum amount of savings you need good observability. A common problem companies face when moving to serverless is not understanding the downstream costs of supporting services that your cloud functions interact with.
Choosing the right database has one of the most direct effects on the cost and performance of your application. A serverless environment is no exception to this principle. By considering parameters like access patterns, schema (data model), and expected performance, it's possible to logically arrive at an optimal decision for your database type. Databases in general have two broad classifications: SQL relational or normalized databases and NoSQL or denormalized databases.
Serverless is great, it helps companies focus on product and application development without having to worry about the application’s infrastructure and scaling under various conditions. However, there are some soft and hard limits for every AWS service you should need to keep in mind when developing a serverless application. These limits are meant to protect the customer as well as the provider against any unintentional use.
The distributed nature of serverless technology is both a strength and a weakness. On-demand hardware’s natural resilience and responsiveness make it a powerful tool for rapidly driving your application’s development and growth, solving many early headaches in scaling and security.
In 2018 AWS released the Cloud Development Kit (CDK), an “infrastructure as code” (IaC) framework that simplifies work with CloudFormation (CFN). CFN uses a declarative programming model based on JSON or YAML files to define resources, like virtual machines and databases, in the cloud.
When I first wrote about Serverless Architectures back in 2016 I described one of the “implementation drawbacks” as being the lack of ability to debug AWS Lambda functions in a cloud environment. In my 2018 update of the article I was still unhappy about this. Now, in 2020, I'm glad to report progress, thanks to cloud tools company Thundra. Thundra makes a number of different tools for monitoring and introspecting code that you deploy to the cloud.
If you’d like to use serverless technology to build your products, you have many services to choose from—starting with a basic function-as a service offering and up to pre-trained machine-learning models. Saving all that development time and focusing on value delivery is a good thing, but if you glue together a bunch of distributed services, your end product will consist of many moving parts. Software is never perfect, so every service can become a risk.
Almost every company today wants and needs an online presence, even if it’s only a simple static web page. Alternatively, a company’s only product might be software. Whatever the case, cloud computing is on the rise; with this rise come issues of scale, and with a larger scale come issues of cloud infrastructure availability and cost. It is possible to reduce infrastructure cost, but how will you make sure that your online business never goes down?
