Aespo's Journey to the Cloud: A Story of Innovation and Cost-Efficiency

Our quest for faster delivery, enhanced customer features, and prompt support led us to transition Aespo to a 'Software as a Service' (SaaS) model on the cloud. This narrative chronicles the architectural changes and strategic decisions made during this transformative journey.

Early Steps: Engaging Customers with a Cloud-Based Trial

Initially, our goal was to swiftly create a customer-facing solution. We launched a cloud-based web trial of Aespo, offering customers a dedicated cloud instance immediately upon signing up. This step involved incremental architectural modifications for effective evaluation and adjustments.

Cost-Effectiveness in the Cloud

Being mindful of the cumulative costs on the cloud, we focused on economizing on key services like compute, database, and network traffic. By exploring Unix systems' 'jailed environments' through chroot and Linux’s lxc, we implemented our first significant architectural change, aiming to optimize resource usage and control expansion based on customer usage metrics.

Leveraging lxcs for Control and Isolation

Using lxcs proved beneficial due to their guaranteed isolation in Linux environments and the flexibility they offered in multiplying or discarding instances. This approach allowed us to test on the cloud without fully implementing multi-tenancy and to utilize EC2 compute resources more efficiently.

Scaling Challenges with lxc Architecture

As our customer base grew, managing this growth with the lxc architecture became increasingly challenging. The architecture’s base cost and the complexities in updating and restarting containers for each Aespo update were major concerns, impacting both our costs and customer satisfaction.

Adapting to Cloud Constraints

We adapted to these challenges by integrating additional elements into our cloud architecture:

• A reverse-proxy for routing customer-specific requests.
• An apt-repo service for updating instances with necessary packages.
• Custom adapters for AWS services.

Transition to Multi-Tenancy

Our analysis indicated that a multi-tenancy approach would be more cost-effective and scalable, allowing us to handle increased loads without proportionally increasing costs. We reconfigured Aespo’s architecture for multi-tenancy, enabling efficient resource utilization while maintaining data isolation at the persistence level.

The Shift to Amazon Cloud Formation (CF)

The introduction of CF transformed our deployment process. CF's ability to define resources and dependencies streamlined our provisioning, incorporating features like autoscaling, high availability, and zero downtime updates.

Utilizing Amazon Machine Images (AMIs)

AMIs, integral to CF, facilitated continuous deployment and traceability. Our deployment process evolved to a system where CF manages application version transitions seamlessly, ensuring high availability and minimal downtime.

Overcoming Provisioning Errors

While provisioning errors do occur, their impact is minimized as they remain hidden from end-users, with the original stack continuing to function seamlessly.

Looking Ahead: Continuous Improvement

Our ongoing efforts to enhance our codebase and deployment process now involve ElasticBeanstalk, a tool better aligned with continuous delivery on AWS. Future updates will delve deeper into ElasticBeanstalk and our continuous delivery tools on AWS.