#🎯practice We've learned to appreciate a sequential approach to DevOps over focus on a particular set of technologies. What this means in practice: - Start from a platform as a service like [Heroku](https://www.heroku.com/) or [Vercel](https://vercel.com/) (or whatever fits the project goal, the legal considerations, etc.) - If the project requires scaling and comprises several micro-services, move to a managed container solution like AWS and [ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html). - Eject to [Kubernetes](https://kubernetes.io) if we really need complex deployment strategies with features like canary release or blue-green deployment. A Docker-first approach to supports the ability to switch between these stages. > [!hint] Docker has many benefits > We believe it is a good practice to containerize the application from day one, even if the target deployment does not support Docker (which is rare, but possible). The benefits of dockerization include simplified continuous integration, a consistent developer experience, and enhanced onboarding speed. --- ## Rationale This approach is related to the fact that infrastructure requirements depend not only on sheer product complexity, but also on the [[product specification#Non-Functional Requirements|non-functional requirements]] and customer base. No matter how feature-rich the product may be, a [[microservice architecture]] makes no sense given few customers with a reasonable tolerance for downtime. On the other hand, even a relatively simple product built for the Internet of Things may require splitting into independent, separately deployed pods on the [Kubernetes](https://kubernetes.io/) cluster. --- <font style="color: #F86759">Contributors:</font> *[[Mykhailo]]* <font style="color: #F86759">Last edited:</font> *2024-04-16*