Kubernetes vs SVN (Subversion)

Our whole DevOps stack consists of the following tools:

• @{GitHub}|tool:27| (incl. @{GitHub Pages}|tool:683|/@{Markdown}|tool:1147| for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
• Respectively @{Git}|tool:1046| as revision control system
• @{SourceTree}|tool:1599| as @{Git}|tool:1046| GUI
• @{Visual Studio Code}|tool:4202| as IDE
• @{CircleCI}|tool:190| for continuous integration (automatize development process)
• @{Prettier}|tool:7035| / @{TSLint}|tool:5561| / @{ESLint}|tool:3337| as code linter
• @{SonarQube}|tool:2638| as quality gate
• @{Docker}|tool:586| as container management (incl. @{Docker Compose}|tool:3136| for multi-container application management)
• @{VirtualBox}|tool:774| for operating system simulation tests
• @{Kubernetes}|tool:1885| as cluster management for docker containers
• @{Heroku}|tool:133| for deploying in test environments
• @{nginx}|tool:1052| as web server (preferably used as facade server in production environment)
• @{SSLMate}|tool:2752| (using @{OpenSSL}|tool:3091|) for certificate management
• @{Amazon EC2}|tool:18| (incl. @{Amazon S3}|tool:25|) for deploying in stage (production-like) and production environments
• @{PostgreSQL}|tool:1028| as preferred database system
• @{Redis}|tool:1031| as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

• Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
• Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
• Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
• Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
• Scalability: All-in-one framework for distributed systems.
• Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.

SVN is much simpler than git for the simple stuff (checking in files and updating them when everyone's online), and much more complex than git for the complicated stuff (branching and merging). Or put another way, git's learning curve is steep up front, and then increases moderately as you do weird things; SVN's learning curve is very shallow up front and then increases rapidly.

If you're storing large files, if you're not branching, if you're not storing source code, and if your team is happy with SVN and the workflow you have, I'd say you should stay on SVN.

If you're writing source code with a relatively modern development practice (developers doing local builds and tests, pre-commit code reviews, preferably automated testing, preferably some amount of open-source code), you should move to git for two reasons: first, this style of working inherently requires frequent branching and merging, and second, your ability to interact with outside projects is easier if you're all comfortable with git instead of snapshotting the outside project into SVN.

I recommend this : -Spring reactive for back end : the fact it's reactive (async) it consumes half of the resources that a sync platform needs (so less CPU -> less money). -Angular : Web Front end ; it's gives you the possibility to use PWA which is a cheap replacement for a mobile app (but more less popular). -Docker images. -Kubernetes to orchestrate all the containers. -I Use Jenkins / blueocean, ansible for my CI/CD (with Github of course) -AWS of course : u can run a K8S cluster there, make it multi AZ (availability zones) to be highly available, use a load balancer and an auto scaler and ur good to go. -You can store data by taking any managed DB or u can deploy ur own (cheap but risky).

You pay less money, but u need some technical 2 - 3 guys to make that done.

Good luck