At Nubes Opus we implement the twelve-factor app methodology to make all your applications cloud ready and then use the most proven industry standard cloud framework called 6 R to perform actual cloud migration when required and ready.

Twelve-factor app

The twelve-factor app is a methodology for building software-as-a-service apps that:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility
  • And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

The Twelve Factors

  1. Codebase: One codebase tracked in revision control, many deploys
  2. Dependencies: Explicitly declare and isolate dependencies
  • Config: Store config in the environment
  1. Backing services: Treat backing services as attached resources
  2. Build, release, run: Strictly separate build and run stages
  3. Processes: Execute the app as one or more stateless processes
  • Port binding: Export services via port binding
  • Concurrency: Scale out via the process model
  1. Disposability: Maximize robustness with fast startup and graceful shutdown
  2. Dev/prod parity: Keep development, staging, and production as similar as possible
  3. Logs: Treat logs as event streams
  • Admin processes: Run admin/management tasks as one-off processes

Rehosting vs Refactor

One of the most critical aspects to determine the migration path for various applications like rehosting (lift and shift) or refactor (monolith to microservices) is a decision that is influenced by:

  • Organizational strategy, internal talent, and execution muscles
  • Technology limitations or requirements of a given application

As an example, applications that have the following attributes are not good candidates for Cloud deployment and must be replaced:

  • Applications that have hardware dependence or awareness
  • Applications that use network broadcasting or otherwise use IP addresses usually reserved by the Cloud Service Providers (e.g. 0.0.0.0 and 255.255.255.255)
  • Applications that are supported only on outdated operating systems

In addition, it is always better to design for a multi-cloud deployment to avoid vendor lock-in and “all eggs in the same basket” situation. One of the best ways to achieve this goal is through SOA/Microservices-based architecture which is well-aligned with some of the recent technology and design innovations:

  • On-demand hosting and scaling in Cloud using containerization technologies such as Docker and Kubernetes
  • DevOps practices and CICD pipeline for automated tests and deployments
  • Domain Driven Design (DDD) that aims to capture the domain model in domain terms (Ubiquitous Language), embed the model in the code, and then protect it from corruption (i.e. Anti-Corruption Layer and Strangler architecture pattern)

“It is not customer’s job to know what they want”
– Steve Jobs

“From legacy to modernization, from centralized services to open api’s, from manual to automation … nubes opus got you covered”