Shake Again moved to the AWS Cloud

Its road to digital transformation alongside DinoCloud

Shake Again is a company dedicated to digital services in marketing and technology. Shake Again is present in 4 countries and continues to grow daily. This recent growth began to generate a new need within the company: to continue offering an excellent service level while meeting the needs of a volatile and expanding market.

DinoCloud, leaders in the adoption of global innovation technologies and cloud computing, have professional teams with the technical expertise to accompany companies in adopting cloud technologies. Shake Again approached DinoCloud with a need, and after months of work, they now have a cloud infrastructure to deploy their applications.

The challenge of this project was the creation of an infrastructure for the development, staging, and production environments, covering the application, networking, and persistence layers. Implementations were executed for all CI and CD environments using GitLab pipelines. 

This was addressed using automation tools and the deployment of frontend and backend services. On the other hand, a database was created for dev and staging and another for production with database migration execution and cron jobs execution for each environment. Finally, application autoscaling and the implementation of a load balancer were implemented.

Project duration and objectives achieved

The project lasted three months and was divided into five different milestones:

  1. Knowledge of the application and understanding of its components and architecture
  2. Setting up an AWS account and registering for local billing
  3. Application architecture design and validation
  4. Infrastructure deployment
  5. Application deployment

AWS technologies and services used

The following technologies have been used in this project:

The AWS services that were part of this project were:

At the networking level

  • VPC: To logically isolate our private virtual network
  • Subnet: To logically divide our VPC and to be able to tie resources if we want to have public or private access.
  • Internet gateway: To enable communication between the VPC and the Internet.
  • Nat Gateway: To allow private subnet services to access the Internet, but external Internet services cannot connect to these resources. It only outputs to the Internet.

Persistence

  • RDS Aurora: To support the persistence layer required for storing data generated by MySQL technology applications.
  • Bucket S3: For storage of files sent from different applications.

At the application level

  • ECR: To store all the docker images for each of the services
  • IAM: It was used to manage the different services’ users, roles, and profiles required to perform specific actions on other resources.
  • SG Firewall: To allow traffic in and out to the resource that is tied up.
  • ALB: To create the access point to the ECS services used to distribute traffic and validate the status of the destination points. 
  • ECS: For the definition of the containers that provide frontend and backend services, as well as for the execution of cron jobs.
  • Fargate: Service used as a worker to allow the execution of the containers created by the ECS services.
  • EC2: To create bastions and access to private subnetworks and private RDS. They were also used to create the GitLab runners that support the execution of the pipeline. 
  • CloudWatch: For logging logs generated by the containers.
  • ACM: For the creation and management of SSL certificates.

Conclusion and results

All the objectives were achieved, including implementing the infrastructure for the different environments using the terraform tool, maintaining the management of layers (networking, application, and persistence), and implementing CI-CD to deploy services in each environment. Each branch has a specific runner assigned to it where the pipeline corresponding to the environment is executed. 

Each developed environment was tested by validating the correct deployment of frontend and backend services, as well as the execution of cronjobs and database migration in each of the environments. The HTTP to HTTPS redirection was also validated in the application load balancer implemented for each environment.

Now, Shake Again has a cloud infrastructure that can cope with the recent growth they have experienced. Being able to deploy its applications in the cloud allows Shake Again to expand into new territories and markets, predicting even more significant growth and a faster, more efficient return on investment.

Get in touch

(*) Required fields