Rosen Platform serverless implementation

To produce more than 1,000 titles per year, Rosen Publishing, a leading educational publisher, generates an enormous amount of content. Before hiring Lineate, they handled it all using a fully functional content management tool that was available at all times. However, some of their websites publish only one or two times each year, so this complicated system was wasting Rosen’s resources and time. We streamlined the tool by migrating the legacy Python content management application to pure AWS lambda functions. As a result, we simplified maintenance, eliminated the need for constant security patching of servers, freed up the time of both developers and systems engineers, and significantly reduced Rosen’s hosting costs.

Previously, the application servers were running a small Python 2.x program that was used exclusively for content uploading and editing. The server resources needed for this application were not insignificant due to the nature of the editing workflow. New content was uploaded in bulk, so the servers had to have enough CPU and memory to handle these events without affecting the program’s performance.

Because Rosen rarely used the content management tool, both development and maintenance of the application became unnecessary. We knew that we could leverage a modern serverless approach to create a simple but effective program that would better fit our client’s needs. We initiated a small project that migrated the Python 2.x application into a Python 3.x application consisting of about a dozen lambda functions (AWS lambda, to be specific). Our solution followed the common serverless approach of having each function do one thing—and one thing only.

Introducing lambda functions is not without some challenges. But with so much serverless development happening in the industry, new tools are available to alleviate the complexity. For example, it can be difficult to organize lambda code and, in this case, the AWS services needed to interact with the functions. Fortunately, AWS provides the Serverless Application Model (SAM) to help build an application that clearly expresses the desired functions, defines how the functions interact with APIs and databases, and describes the infrastructure required. SAM allows developers to follow infrastructure-as-code standards by including the AWS infrastructure along with the serverless functions in a single code repository. 

There are alternatives to SAM. In our case, we were working with a relatively simple Python application, but larger projects may require a more robust solution. AWS offers several options, such as AWS Cloud Develpment Kit (CDK), which allows developers to define infrastructure using a variety of programming languages (Python, Typescript, Java, etc.). AWS describes infrastructure primarily with AWS CloudFormation templates, but they are often avoided because they can become unwieldy and contain a lot of hard-to-read boilerplate. Both SAM and CDK automatically generate the necessary Cloud Formation templates under the hood.

Another option is Terraform. Our team at Lineate has extensive experience using Terraform because many of our customers have large cloud infrastructures and often prefer a non-AWS-specific solution so they’ll have more options. Terraform is great even if you are only going to use AWS, but having Terraform provide your infrastructure allows for reusability in both hybrid and non-AWS-cloud services.

For our work with Rosen, though, we felt that SAM was perfectly suited to our needs. SAM provided a remedy to another challenge we faced in cloud development—working with code locally. SAM allows for local testing of lambda functions, so we didn’t have to do a new deployment every time we wanted to try out a function. This sped up development dramatically. Not every AWS service can be tested locally so easily, but SAM provides ways for local code to interact with parts of the infrastructure in the cloud.

This project was successful on many fronts: Lineate saved our client a considerable amount of money because they no longer have to pay for rarely used resources. The codebase of the content tool is now more manageable because we built it using just a dozen single-function lambdas. And our developers loved working with this technology. A win for all.