monolith vs microservices per l'idea di app

1

Ho deciso di iniziare a creare un'app SAAS . Desidero mantenere bassi i costi di hosting inizialmente, fornendo comunque una buona esperienza utente. Ecco i componenti che compongono la mia app:

  • Front-end
  • Reverse Proxy (Nginx)
  • Servizio di autenticazione
  • API Web
  • Servizio di lavoro A (importa le importazioni di dati)
  • Worker Service B (effettua batch di chiamate API esterne)

Tutte le richieste passeranno attraverso il proxy e l'autenticazione verrà gestita tramite JWT .

Inizialmente pensavo che avrei avuto tutti questi componenti su server separati, ma guardando i provider di hosting e i prezzi, sembra una opzione costosa che inizia (specialmente con 0 clienti paganti).

Quindi sembra un modo economico per farlo sarebbe quello di utilizzare un singolo server. Essenzialmente ogni componente sarebbe solo un pezzo separato di codice isolato. Utilizzando questo approccio, utilizzerei comunque il proxy inverso e utilizzo ancora JWT per auth - mi sembra che in questo modo tutto possa essere spostato su server separati più facilmente in futuro.

Quali sono gli svantaggi di un approccio a server singolo come questo (a parte gli ovvi negativi monolitici)?

Supponendo che questo approccio sia accettabile, sta utilizzando un servizio come Elastic Beanstalk abbastanza in termini di gestione dell'alta disponibilità?

    
posta user3574076 09.10.2016 - 06:08
fonte

2 risposte

9

Mai sopra l'architetto fin dall'inizio. Trascorrerai la maggior parte del tuo tempo sull'architettura e non sul business case che stai implementando. (Questo è particolarmente vero se stai provando un nuovo approccio di architettura, come i micro servizi)

Quando inizio con qualcosa di nuovo e soprattutto qualcosa che non ho idea se qualcuno userà mai, vado sempre semplice e veloce. Questo non significa che devi scrivere codice spaghetti scadente. Come hai detto, vuoi ancora modularizzare il tuo codice e separare le tue preoccupazioni all'interno del tuo monolite, in modo che sia più facile calcolarlo in un secondo momento, se necessario.

    
risposta data 09.10.2016 - 11:02
fonte
0

Certamente ha senso modularizzare come meglio si adatta alle future esigenze di espansione e gestione, indipendentemente dal fatto che si finisca col distribuire su un unico server, come dice c_maker, trovare un equilibrio utile ed economico per quanto riguarda il proprio tempo.

Detto questo avrei almeno 2 server lì dentro. Hai bisogno di un pubblico di fronte al front end e qualsiasi altra cosa direttamente aperta ai clienti. Tutto il resto dovrebbe essere su un server separato preferibilmente non nella DMZ, protetto in un modo diverso (cioè più appropriato) e accessibile dal front-end tramite account di servizio. Riduci al minimo il codice che va sui server accessibili al mondo esterno.

    
risposta data 10.10.2016 - 07:11
fonte