At Nubes Opus, With our Application migration stratergies 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
- Codebase: One codebase tracked in revision control, many deploys
- Dependencies: Explicitly declare and isolate dependencies
- Config: Store config in the environment
- Backing services: Treat backing services as attached resources
- Build, release, run: Strictly separate build and run stages
- Processes: Execute the app as one or more stateless processes
- Port binding: Export services via port binding
- Concurrency: Scale out via the process model
- Disposability: Maximize robustness with fast startup and graceful shutdown
- Dev/prod parity: Keep development, staging, and production as similar as possible
- 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 Application migration stratergies is 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”