I was recently presented with a proposal to build a new website project and while discussing the project scope and requirements I told the project owner the website would be cloud-based. He agreed and we finalised terms, timelines, deliverables and costs.
In a post-cloud era where many businesses are still running their software applications on legacy technologies the decision to go cloud is not a light one for both business managers and technology professionals. For me, this project would be the first client project that I would deploy using serverless technologies, a skill I had recently acquired. In this writeup I will highlight some typical challenges faced on the technical side when you plan, design, test and deploy a dynamic website to the cloud.
Plan
I decided that I would largely use serverless technologies for this project. The static files of the website would be hosted using Simple Storage Service (S3), an object store, and the dynamic aspects of the website would be processed using API Gateway, Lambda functions, Simple Notification Service (SNS) and Simple Email Service (SES). The completed website would be distributed with CloudFront for global distribution and high availability.
Design
In this phase contents (writeups, images, artworks and other static assets) were developed to meet the communication, graphic design and branding requirements of the business the website was being developed for. Research was done for reusable code that could be adapted for dynamic parts of the website.
Build
This involved putting up all the different parts of the website, linking them together, writing needed code, testing and retesting the project in a local development environment.
Deploy
This involved setting up and configuring the cloud environment and then moving the code and files that make up the project to the cloud. I created an S3 bucket to hold the static assets (or frontend) of the website. For the backend, I configured API Gateway, Lambda functions, SNS and SES to process the dynamic features of the website. I created a CloudFront distribution and configured it to use a custom domain name to globally distribute the website in a manner that is scalable and highly available.
Challenges
After deploying the website some of the dynamic features did not work. For example, one feature which was supposed to collect data inputted by a website user, process it, transmit it over a secure connection to a datastore where it can be retrieved by the business did not work. Technically, a form on the website should take data inputted by the user, process it and send it via a POST request to API Gateway which would forward the data to a Lambda function which would process the data and forward it to SES to deliver to a store. This feature was enabled by several different serverless technologies which had to work together.
Troubleshooting this failing feature took several days during which I discovered and fixed configuration errors in SES and API Gateway till I narrowed the remaining errors to the Lambda function. At this point the project owner communicated to ask for a progress report on his website and I replied that it would be ready in a few days. But back at my workstation I was staring at my development environment and wondering why the codes of a Lambda function which appeared to work fine separately would not work when integrated into the larger website feature.
There was brief temptation to revert to legacy technology that was tested and trusted.
I reviewed official technical documentation, course materials, and tutorials written by developers who had deployed a similar feature successfully. Eventually the feature was fixed after I updated my Lambda function code and passed parameters appropriately. A similar approach was used to fix the other failing features of the website project.
Security Hardening
This involved reviewing the working website code and making relevant changes to ensure they met best practices for usability and security.
Monitoring
A project is not done after it has been successfully delivered to the satisfaction of the customer. In fact, the real life of the project has only begun because it has to be monitored and observed to know if and how it satisfies the users and serves business objectives. Insight is gathered continuously to help improve the website.
Conclusion
From an engineering perspective, the performance of this cloud-native website is impressive. Furthermore, because it is running on serverless technologies, its operating costs can drop to zero when not in use. Personally, there is this satisfaction I have that I have used very recent technologies to build and deploy a working application.
Leave a Reply