Infrastructure for your project: why you should follow our suggestions

Summary The purpose of this document is to highlight what

Latest Post Tips for your colleagues by Estefania Muro

Summary

The purpose of this document is to highlight what can happen when you have technical
debt and choose to keep working that way despite TinkerWare’s suggestions. Specifics are
avoided to not cause any problems to the team that brought us this experience.

Project Overview

This project includes several parts: an informative blog which also serves as a forum for
getting experts advice for potential clients of the other part of the project, which is a store
to sell products. TinkerWare focused on configuring and managing the project’s
infrastructure, optimizing it so there’s only what was needed and that way, favoring cost
reduction and efficiency at the same time.

Status before collaboration

The project assignees wanted to try new things while developing the applications needed
to complement the project as a whole. And thanks to our experience on working with
containers and cloud technologies, there was a plan to use our services for outsourcing
the infrastructure required.

Identified requirements

  1. An MVC-like architecture was required.
  2. Limited budget.

How the requirements were tackled

Here is our workflow proposal, described below in more detail.
study-case-2
Infrastructure-wise, the workflow has three phases: local, stage and production:

  1. Local
    a. Work on Docker containers
    b. Manage different branches on your Git based code repo for all the work
    environments
    c. Most tests and fixes happen
  2. Stage
    a. Hosted in a variety of AWS services. Mainly ECS, ECR, EC2 and Route53.
    b. Same structure as production environment but in smaller scale.
    c. Minor tests and fixes happen.
    d. Deployed apps are taken from a Stage branch on your code repo.
  3. Production
    a. Hosted in a variety of AWS services. Mainly ECS, ECR, EC2 and Route53.
    b. Refined infrastructure from data obtained in the Stage environment. Helping cost
    optimization.
    c. NO tests and fixes happen.
    d. Deployed apps are taken from the Master branch on your code repo.

Results

We suggest a workflow and that’s what we guarantee to manage with no problem. But the
real situation is different as of today, and that way we aren’t able to assure the problems
will be kept to a minimum.

  1. The same RDS MySQL instance has been used for all work environments, production
    included.
  2. Everything code related is pushed directly to the Master branch.
  3. Stage environment doesn’t exist, so everything cloud related goes directly into
    production.
    a) This has triggered the need to update the code outside work hours, when
    bugs are detected by clients.

Evidence

As (Sabanin, 2019) and (Hillman, 2019) say, Beanstalk supports the idea of the three work
environments mentioned previously, and also branching your development so each environment
can be managed more easily.
Some recent examples are Facebook, Instagram and Whatsapp, which failed for around 15 hours on
the first week of July 2019, causing the discontent in, possibly, hundreds of millions of users.. To
which Facebook (@facebook) made a vague statement on Twitter, acknowledging the problems and telling they were taking action into restoring everything back to normal as soon as possible. But the
real problem was never discussed, that’s why the failure can’t be exempt from the possibility of
being a result of a failed update within Facebook’s servers or a bug not predicted before.

References

Hillman, A. (2019). Developing and Deploying with Branches • Beanstalk Guides. [online]
Beanstalkapp.com. Available at:
http://guides.beanstalkapp.com/version-control/branching-best-practices.html [Accessed 31
Jul. 2019].
● Sabanin, I. (2019). Deployments Best Practices • Beanstalk Guides. [online] Beanstalkapp.com.
Available at: http://guides.beanstalkapp.com/deployments/best-practices.html [Accessed 31
Jul. 2019].