Hey everyone! I'm making some changes at work and want to create an architecture diagram to help clarify our current setup and impress the team. Here's what I'm working with:
1. Windows server running App 1 with both production frontend and backend.
2. Database server for App 1 in production.
3. Another Windows server for App 1 staging (frontend and backend).
4. Staging database server for App 1.
5. A Windows server for App 2 which includes production frontend, backend, and database.
6. Another Windows server for App 2 in staging (frontend, backend, and database).
7. A Linux server running Plesk.
This structure has worked for us, but we're changing our server provider and I think it's a good time to rethink our architecture. We're considering using two machines for virtual machines (VMs) and I'd like to explore mirroring everything from machine One to machine Two for redundancy.
I want to have an easier deployment process for App 2, ideally being able to switch between staging and production without downtime, and also spin up new servers for branches, either manually or automatically. For this setup, I plan to maintain App 1 on four VMs as it is now, while App 2, which is still in development, could potentially transition from IIS to Docker or k3s. The Microsoft SQL database should still reside in a VM.
I'm a bit lost on where to go next and would love some feedback on how to improve this architecture. Here's a diagram I've been working on, mainly focusing on App 2: [https://imgur.com/a/0xyABEi](https://imgur.com/a/0xyABEi). I think I might be missing some elements. Should everything be housed within the same k3s environment, or would it be better to have separate environments—one for production and staging and another for development? All of these software decisions have been influenced by research and discussions with ChatGPT since I'm not familiar with these tools yet. Any tips would be greatly appreciated!
2 Answers
I totally relate to feeling overwhelmed when redesigning a tech stack! I built a few AI tools to help me navigate the options like k3s vs Docker and high availability (HA) solutions. These tools helped me turn my notes into a solid proposal for management. It's super handy if you want to streamline your process!
When you're deploying App 2 to Kubernetes, consider how you’ll manage rollouts. The blue/green deployment strategy could work well, but how you'll implement it—whether on clusters or namespaces—is crucial. My advice would be to lean towards rolling deployments where your application team focuses on backward compatibility like database schema changes and API versioning. This should simplify your process!
K8s can be overkill for a single app. You might want to check out some simpler container solutions like Kamal Deploy—I think they offer a lot with less complexity!
That makes sense! The idea for blue/green came from a past discussion about DNS rollout, but I see how rolling deployments could be smoother. Appreciate the insight! And yeah, I initially thought k3s was just a different name for Kubernetes, so I'm glad I have that clarified now.